Еще к вопросу нескольких классов в одном файле (2PAF)

Sikoz 05.11.2006 11:23

Не надо это убирать, хотя бы ради динамики. В js и многих других языках есть возможность динамически создавать класс прямо в коде (вместе с функциями) и все ею пользуются. Примерно так:
a = new class;
a._data = new array();
a.create = function(arg);
... и пошли заполнять. Красиво и читаемо.
Естественно, по большей части это переносится в отдельные куски кода - но не в отдельные файлы (хотя, к примеру, для js это более оправдано в плане скорости загрузки при keep-alive и распараллеливании запросов броузером) - но ведь нет, обычно работают с ОДНИМ файлом.

В парсере тоже зачастую удобны мелкие классы под конкретные задачи. Вот пример:

@CLASS
color 
@create[c_a;c_b]
$a[$c_a]$b[$c_b]$current[$a]
@print[]
$result[$current]^if($current eq $a){$current[$b]}{$current[$a]}

Динамический класс однозначно удобнее чем оператор, но смысла класть его в отдельный файл нет ввиду размера - лучше поместить в библиотеку операторов.

Я уж не говорю о наследованиях, когда они создаются только под конкретные задачи в одном логическом окружении. При отсутствии поддержки ^класс:$метод[] - это как нельзя более актуально.

Во всех перечисленных случаях, если стоит выбор между классом в файле или оператором в группе, удобство и лень выберут несколько операторов в одном файле. И объектно-ориентированный подход останется только для задач из учебника вроде ^forum:display[]. Тогда получается, что объектность Парсера нужна только для создания пространств имен - но разве это правильно?

---