нашёл чему радоваться

уже 2.5 на носу

А теперь на сцене руби:
class Foo
   attr_accessor :bar
end

:))) 

Что-то я не понял, а зачем этот attr_accessor?

   module Mod
     attr_accessor(:one, :two)
   end
   Mod.instance_methods.sort   #=> ["one", "one=", "two", "two="]

> Mod.instance_methods.sort #=> ["one", "one=", "two", "two="]

Это я и сам в мануале посмотрел. Но не врубаюсь, зачем создавать стандартный геттер и стандартный сеттер, если они всё равно ничего нового не делают?

>Это я и сам в мануале посмотрел. Но не врубаюсь, зачем создавать стандартный геттер и стандартный сеттер, если они всё равно ничего нового не делают?

Ну вопервых в руби нельзя просто так обращаться к членам класса извне. Для этого он нужен. А во вторых ведь специальными функциями get-ры сеттеры обрастуют часто не сразу, а очень часто бывает что геттер например с доп функциями а сеттер без или скорей наобород. Поэтому

attr_reader, attr_writer (идея понятна?) И вообще метапрограммирование в руби намного лучше выглядит чем в питоне.

свойства (options) -- гадость и маздай. видать из дурацкого ц++ пришло

свойства (properties) действительно гадость.

а properties --- фирменная фишка Object Pascal, больше 10 лет назад изобрели ;)

привет изобретателям кривых велосипедов из python.

те на pascal когда пишем

MyButton.Visible = true;

на самом деле вызывается MyButton.setVisible(true);

> а properties --- фирменная фишка Object Pascal, больше 10 лет назад изобрели ;)

Не обольщайся оно и раньше было. Как минимум в CLOS. 10 лет назад был уже в стандарте, а существовал задолго до этого.

Я и не сомневался...

поясните

поясните как скриптовый язык, в котором конкатениция строк осуществляется "+" и не имеющий автоприведения целого к дробному может называться "крутым" и "современным"?

А кто сказал, что он "крутой"? Он просто довольно удобный и подходит для определённого класса задач.
А насчёт современного... Why not? Не такой уж и древний. Не латынь

> ак скриптовый язык, в котором конкатениция строк осуществляется "+" и не имеющий автоприведения целого к дробному может называться "крутым" и "современным"?

Шутку понял. Смешно.

> Шутку понял. Смешно.

расскажи, тоже посмеюсь.

серьёзно, я считаю, если в языке есть автоприведение типов - то вышеупомянутые недостати сильно смазывают впечатление от работы.

a="10"; b=20; print a+b

и что получится? - ошибка. а нафига? если бы я хотел вручную отслеживать тип введённых данных - учил бы С

> a="10"; b=20; print a+b
> и что получится? - ошибка. а нафига?

а что бы ты хотел получить, "1020" или 30?
однозначного ответа нет, потому и ошибка

> и не имеющий автоприведения целого к дробному

from __future__ import division

> и что получится? - ошибка. а нафига?

Чтобы была стройная концепция. Стройные концепции проще запоминать. Если уж вам так нужно автоприведение типов, то зачем тогда типы вообще разделять? "10"+"20"=="30", sin("pi"/"2") == 1, "10"+"a" == ХЗ и т.п. Нафиг целые нужны? TCL, вон, и без целых справляется :)

> а что бы ты хотел получить, "1020" или 30? однозначного ответа нет, потому и ошибка

по "+" я бы хотел получить 30. а по оператору конкатенации строк - 1020

если `плюс` применяется к заведомо строковому аргументу - приводить его к int(0). правда просто и логично?

> если `плюс` применяется к заведомо строковому аргументу - приводить его к int(0). правда просто и логично?

Нет, не логично. В Python я пишу:

print "Enter integer parameter:",
s = sys.stdin.readline()
c = a*int(s)+b

И если пользователь вводит х..ю вместо числа, то будет ошибка, а не х..я на выходе. Эту ошибку можно легко поймать, и если надо, загнать запрос параметра в цикл. Язык не должен быть слишком умным там, где не надо, потому как тяжко потом искать, где он там сумничал, когда получишь неправильный результат.