Здравствуйте, Буравчик, Вы писали:

Б>Это всего лишь сахар, дабы не плодить лишних скобок. Основная операция and:
По-моему, они пересластили.
Конечно, основная операция — унарный receiver and:block1.
Но тут фигня в том, что авторы накопипастили кучу сигнатур, вместо того, чтобы позволить пользователю выражать всё через одну.
Вот у чисел есть единственное x *y, а не x *y *z *t
Возможно, это была битва против правой ассоциативности, т.к.
a and: b or: c and: d разбивается на (a and: (b or: (c and: d)))
И, соответственно, без мега-сигнатур с одними and было бы
(a and: (b and: (c and: d (and: (e and: f)))))
а с мега-сигнатурами — вот тут нужно уточнить, жадный ли компилятор
(a and: b and: c and: d and: (e and: f))
или ленивый
(a and: (b and: c and: d and: e and: f))
Вроде бы жадный...

Б>К тому же, при необходимости, можно легко добавить недостающие методы (and: and: and: and: and.
Куда легко добавить? В стандартную библиотеку?!
Ну я понимаю, что смолток-среда является песочницей, и у себя в песочнице можно творить всё, что хочешь.
Например, пропатчить стандартные классы.
Можно даже на боярский язык перевести, ибо:, вотще:, еслиЧо:, еслиНичо: — но непоймут-с!

Б>Можно оставить только ifTrue: (аналог if) и ifTrue:ifFalse: (аналог if else).
Б>ifFalse и ifFalse:ifTrue — сахар.

Конечно, можно. Я, вообще, удивился, почему они сделали всё на откуп в субклассы. Может, ради производительности?

Б>В VisualWorks есть только and: . В целом, согласен. Есть у Smalltalk проблемы с переменным количеством аргументов. Но если хочется поругать этот красивый язык, то ругать его надо все же не за это. Да и наезд на ifTrue ifFalse — не понятен.

У смолтока проблемы не с переменным, а с множеством аргументов. Из-за того, что пользователь может захотеть послать сообщение, начиная с произвольного ярлыка, приходится рожать кучу сигнатур. Ну там setWidth:height: и setHeight:width: и т.п. То есть, выбрав вот такой синтаксис, обрекли себя на многословие (и вошли в диссонанс с самоназванием).
Хотя есть языки, поддерживающие именованные параметры. Даже лисп.

А с учётом того, что все методы виртуальные, придётся договариваться — что подлежит переопределению в субклассе, а что является шаблонным методом (в случае с Boolean — and:and:and: — шаблон, and: переопределяется).

К>>P.S. Возопиил в связи с тем, что "Язык Objective-C позволяет снабжать метками каждый аргумент, что заметно повышает читаемость кода и снижает вероятность передачи неправильного параметра."

Б>Вывод-то какой? По-моему, в Objective-C пришлось бы делать то же самое. Хотя, могу ошибаться.
Именно этот вывод. Тяжёлое наследие.

Я бы в С++ офигел вводить методы setWidthHeight(w,h) и setHeightWidth(h,w)