Re[2]: The philosophy of ruby

[Max B. <be...@ma...>]

Hello Peter,

Thursday, October 23, 2003, 7:53:56 AM, you wrote:

PBS> Max Belugin wrote:
>> Нельзя написать функцию которая работает с любым объектом, у которого
>> есть метод add

PBS> А кому нужна такая функция?

как правило, имена отражают назначение. часто не хочется быть в
зависимости от того, поддержал ли автор класса определенный интерфейс
или нет.

PBS> Функция пишется в расчете на определенные, а
PBS> не на любые, типы объектов и перегружается сколько надо раз. Для любых
PBS> есть java.lang.reflect.*. Только типизация здесь ни при чем, это
PBS> называется late binding.

Также это называется динамической типизацией.
В случае reflect мы получаем длинный неудобный способ работы с тем, с
чем в динамических языках есть короткий и простой способ работы.

>> > обязательном порядке" - это даже хорошо, т.к., забыв определить
>> > нужный метод, в Java я получу ошибку на этапе компиляции, а в Питоне
>> > - на этапе выполнения.
>>   именно этот я и вкладывал когда писал "надежность меньше, реюз
>> больше"

PBS> Такой реюз делается через полиморфизм, при этом надежность остается.

Такой реюз через полиморфизм требует больше кода => меньше реюза.
Также в Java невозможно описать отдельно от класса каким образом
данный класс реализует данный интерфейс - навпример в Eclipse для
этого своя архитектура с инстерфейсом IAdaptable

>> > Во-первых, никто и не обещал, что она останется. Во-вторых, не вижу
>> > в этом проблемы. Реализация функции - моя. Списки, переданные в map
>> > - тоже мои. Наверное, я знаю, что мне ожидать на выходе?
>> О... если так рассуждать, статическая типизация вообще не нужна. См.
>> предыдущее предложение.

PBS> Не расскажете, как Вы пришли к такому заключению? Я не улавливаю никакой
PBS> связи, предыдущее предложение не помогает.

Ну как - все мое, я знаю, что получится на выходе, а что не мое -
посмотрю в документации - зачем мне статический контроль типов?

>> >>Кстати, тебе придтся для каждого случая вызова функции создавать
>> >>wrapper, который читебальности не прибавит.
>> я говорил про фрапперы функций. Как напримар воспользовавшись твоим
>> map зключить все строки списка в кавычки.

PBS> Function f = new Function() {
PBS>   public Object call(FunctionArguments args) {
PBS>     return "\"" + args.get(0) + "\"";
PBS>   }
PBS> };

PBS> List ql1 = BuiltIn.map(f, l1);
PBS> List ql2 = BuiltIn.map(f, l2);

PBS> Где здесь вообще враппер, не говоря уже про каждый случай вызова?

допустим у вас уде есть функция, заключающая строку в кавычки.

>> >>не надо. и тебе как - для скриптинга это удобно? (реализация 9 раз
>> >>одного и того же)
>> > Удобно, что здесь неудобного? И какое мне, как пользователю, дело до
>> > реализации?
>> то есть ты не хочешь обощать части своих скриптов и т.д.

PBS> Наверное, я напрочь тупой, но нельзя ли расшифровать, что значит
PBS> "обобщать части своих скриптов и т.д."?

вам как пользователю _чего_ дело до реализации _чего_? например, вы
обнаруживаете, что в большом количестве ваших скриптов используется
кусочек, который можно обобщить, параметризовать и назвать map.
Так как в Java есть примитивы (то есть не все является объектом) вы
должны написать 9 реализация вашего кусочка. Потом написать врапперы
на каждый класс, который может быть представлен как коллекция, и потом
каждый раз оборачивать функцию, которую бы вам хотелось вызвать.

>> >>Ничего - городить на каждый чих врапперы конечно можно, но
>> >>читаемости не прибавит.
>> > Это субъективно. Два-три враппера _я_ выдерживаю.
>> То есть, по твоему, врапперы прибавляют читаемость?

PBS> Нет. Они, до определенного количества, ее не убавляют.

а по-моему, убавляют.

>> >>String - не коллекция. Массив - не коллекция.
>> > Вы же только что согласились, что врапперы можно написать.
>> а так же писать врапперы на каждый новый тип массива.
>> напишите Wrapper для String [] теперь для Applet []

PBS> Для того, чтобы добавить элементы массива в список, не надо знать их
PBS> реальный тип, поэтому я напишу один для Object[].

потом делать приведение Object[] к String[] и т.д. в-общем, без этого
проще. И этих мелких упрощений набирается много.

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

PBS> Чем для этого не подходит интерфейс Function?

тем, что про него никто кроме нас с вам не знает. Соответственно все
существующий функции надо оборачивать, причем для операции сравнения
следить за тем, чтобы существовала ровно одна обертка для каждой
функции.

>> > Не понял. Писать за Вас это будет любая IDE. А зачем это читать?
>> как любая IDE будет за меня _читать_ этот не относящийся к делу код.

PBS> А кто за меня будет читать и писать все эти self'ы в методах класса?

это да. в ruby используют @ - так короче.

PBS> Это
PBS> к вопросу о лаконичности. А конструктор/методы предка вызывать не через
PBS> super, а по имени? Это к вопросу о реюзе. Предлагаю прекратить членами
PBS> меряться.

Почему бы не померятся. Тем более что члены не наши а ван Россума с
Гослингом. Это поможет узнать особенности их конструкции.

>> эти примеры были только иллюстрацией.

PBS> Иллюстрацией чего?

удобств питона: все есть объект, все есть коллекция, есть удобный
синтаксис для работы с этим.

>> Еще, питон обладает большей способностью консервировать щелчки с тем
>> чтобы  дальнейшем щелкать меньше.

PBS> Это как?

реюз больше - свою работу сожно сохранить, а потом использовать (см.
пример с map)

>> > решили. Я просто хотел узнать, чем Питон лучше Java в плане
>> > кроссплатформенности.
>> http://python.org/download/download_other.html

PBS> Количество - это хорошо. А что с качеством?

не знаю, я пока пользуюсь на одной платформе.

>> ;))) вот в конце вы мне предложили писать на питоне, толькопод JVM

PBS> Я такого не предлагал. Я предложил написать свои хелперы или взять
PBS> готовые, если хочется лаконичности. А уж на что эти хелперы будут похожи
PBS> - дело вкуса писателя.

я говорю о языке - а язык это и есть один большой хелпер.

-- 
Best regards,
 Max                          mailto:be...@ma...
http://belugin.newmail.ru    ICQ:9406811