Показать сообщение отдельно
  #39 (permalink)  
Старый 24.07.2012, 15:12
Аватар для x-yuri
Отправить личное сообщение для x-yuri Посмотреть профиль Найти все сообщения от x-yuri
 
Регистрация: 27.12.2008
Сообщений: 4,201

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

Сообщение от devote
А вот такой вариант я почему-то считаю сложным, не знаю возможно для любителей JS он удобен и т.д. Но его тоже нужно будет изучать и так же получится не один, не два не три варианта а много, где нужно будет знать еще какие-то тонкости. Но тем не менее я подумаю над этим, возможно что-то придумаю.
Что ж в нем сложного-то? Использование объекта (ассоц. массива) вместо перечисления параметров через запятую? В твоём варианта рассчет идет на очевидность, с целью сэкономить на "назывании параметров". Экономия очень сомнительная на мой взгляд. Чем больше параметров, тем сомнительнее. Так почему бы не расслабиться и не использовать мой вариант? А твой подход использовать, в более простых случаях? Кстати, я бы назвал его jQuery-подходом.

Сообщение от devote
При всем этом я писал из расчета скорости работы, если я напишу так как вы предлагаете во втором варианте, тоесть прямо в data это приведет к тому что при создании экземпляра нужно будет каждый раз разбирать все эти параметры, что приведет к занижению производительности. Хоть она и не заметна будет, но для большого кода/проектов это значительные потери. В моей же реализации, все манипуляции с параметрами происходят во время объявления класса, далее уже при создании экземпляров, никакие параметры не разбираются.
Во-первых, кеширование никто не отменял. Во-вторых, это ваше классовое ООП странновато смотрится в прототипно-ориентированном ЯП. Альтернатива: mixin, inherit. Разве этого не достаточно? На фоне альтернативного варианта твоя библиотека выглядит ненужным усложнением (в первую очередь интересны __get/__set и autoload, ну и imports), и тут мне в очередной раз приходит в голову мысль, что большинство проблем с производительностью связаны с неоправданно высокими требованиями (ненужными усложнениями)...
Ответить с цитированием