dark-demon Знаете, если вам надо закоментить целый класс - что-то не так уже в самой логике приложения. Лично у меня это решается просто - просто вырезаю код и пихаю в отдельный фаил в специальную папку. Ну или средствми IDE выделяю весь класс и зажимаю Shortcut, который закоменчивает весь выделенный кусок кода. Все более-менее нормальные редакторы кода умеют это делать. HTML... Знаешь, я уже не помню когда последний раз мне толком приходилось ковырять исходник самой страницы целиком - шаблоны прекрасно разбивают од на блоки, которые сами по себе не большие и легко подправляются по необходимости. Это к тому, что если надо - всё учится довольно легко - было бы желание это делать. Почему многие не пользуются к примеру встроенным в ZDE менеджером баз данных? Потому что тот-же EMS SQL Manager просто лучше. Почему я не пользуюсь записью дисков прямо из винды? Потому что сторонней специальной программой удобнее и больше возможностей, заточенных именно под запись данных на диски. Каждый язык оптимизирован под свою нишу, в которой её разумно применять. Сайты можно и на C/C++ делать, есть специальные либы, заточенные под CGI - но это дольше, труднее и имеет свои определённые недостатки - на PHP просто дешевле и быстрее. (большие тяжелые приложения в расчёт не берём, есть вещи которые наоборот делают на быстрых системных языках).
> если вам надо закоментить целый класс - что-то не так уже в самой логике приложения. если мне нужно хоть что-либо отредактировать - что-то не так с логикой приложения. именно в том, чтобы привести логику в порядок, и заключается работа программиста. > Ну или средствми IDE выделяю весь класс и зажимаю Shortcut, который закоменчивает весь выделенный кусок кода. ты так и не ответил каким образом она закомменчивает код, содержащий многострочные комменты. > Знаешь, я уже не помню когда последний раз мне толком приходилось ковырять исходник самой страницы целиком а причём тут страница целиком?
PS. Почему многие пользуются к примеру 1 компьютером, а не десятком (один для ковыряния в базе, другой - для записи дисков и тд)?
dark-demon Пожайлуста, выключи тупого. Визуально блин, как ещё. Не получилось /* */, значит шлёпаешь // и всё. Обычно всегда шлёпаю // комменты в таком случае. Потом они так-же легко одной комбинацией клавишь убираются. Крч топик уже бесполезен, аля procedures vs oop, тока ещё хуже. Причины, аля "а мне нравиться так, потому что я так хочу" - не агрумент и спорить так бесполезно. Какая разница - // или #? Лично мне удобнее // ставить, т.к. не надо зажимать Shift и тянутся до цифры 3 одновременно - тупо удобнее и быстрее //.
> Пожайлуста, выключи тупого. латвия - это далеко. давай как-нибудь сам. > Визуально блин, как ещё. Не получилось /* */, значит шлёпаешь // и всё. почему бы сразу везде не использовать // и всё, не играя в игру "угадай какой тип комментирования сработает"? > Лично мне удобнее // ставить, т.к. не надо зажимать Shift мне тоже не нравятся комбинации клавиш, но клавиатурой с 256 кнопками пользоваться ещё неудобней.
кстати, продолжим... есть мысль сделать язык реализующий концепцию ооп, но с функциональной начинкой. поясню.. допустим мы определяем переменную, как хэш-таблицу: [js]magiKeys: qwerty: 1 iddqd: 2 idkfa: 3 :magiKeys[/js] когда интерпретатор доходит до этого места он не создаёт переменную, а создаёт он некий програмный код, суть которого заключается в создании значения. проще говоря, запись выше эквивалентна такому псевдокоду: [js]var magiKeys= function( ){ var obj= new Hash(); obj.qwerty= 1; obj.iddqd= 2; obj.idkfa= 3; return obj; }[/js] но при попытке получить значение переменной будет вызвана указанная функция, которая создаст объект и вернёт его. в итоге получается, что программист пишет программу в более естественном императином стиле в то время как получается у него функциональная программа, что даёт такие преимущетва как: максимально ленивые вычисления, автоматическое кэширование вычислений, простота распараллеливания и низкоуровневой оптимизации.
вот тут небольшой аналитический обзор методов реюзинга: http://ringill.livejournal.com/16796.html в кратце - все объекты делятся на собственно объекты и так называемые "штрихи". где собственно объект имеет состояние и реализует интерфейс для изменения состояния а штрихи не имеют состояния, но реализуют функционал по реализации одного интерфейса на базе другого. при этом от объекта нельзя отнаследоваться, а от штриха - можно. если добавить сюда глобальный реестр интерфейсов (как сделано, например, в мозилле) и возможность переименовывать методы, оставляя привязку их к задекларированным интерфейсам - совсем тру ооп получится
развивая идею штрихов... пусть у нас есть интерфейсы interface1 и interface2. и допустим мы реализовали штрих trait1, который преобразует эти два интерфейса в другой - interface3. теперь к каждому объекту, реализующему интерфейсы 1 и 2 можно обращаться и через интерфейс 3, без каких-либо специальных телодвижений. однако, реализация trait1 может оказаться неэффективной для определённого объекта, поэтому в нём можно реализовать и интерфейс 3. проще говоря, если к какому-либо объекту происходит обращение через неподдерживаемый им интерфейс, происходит поиск цепочки штрихов, которая бы позволила получить нужный интерфейс. если цепочка не была найдена - фиксируется ошибка. если было найдено несколько цепочек - выбирается та, что короче. если и таких несколько - отсеиваются те, которыми можно безболезненно для других объектов пожертвовать.
в качестве примера: два исходных интерфейса iStack и iQueue декларируют методы push, pop, shift, unshift, top (присутствует в обоих интерфейсах) объявим штрих tStackAndQueueToDequeue, который реализует интерфейс iDeque (двунаправленный стэк) на базе интерфейсов iStack и iQueue. его методы: pushStart, pushEnd, popStart, popEnd, start, end теперь мы можем создать, например, массив в котором заимплементить iStack и iQueue и свободно юзать методы iDeque. а можем сразу заимплементить методы iDeque, а специальные штрихи tDequeToStack и tDequeToQueue позаботятся о поддержке iStack и iQueue.
Чёрт, литра было мало... тащите бочку спирта, иначе я сломаю моск... dark-demon Знаешь в чём-бы тебе цены бы небыло? Если бы ты разобрал по человечески паттерны проэктирования с красивыми, хорошими и реальными примерами как и зачем это и как использовать. Без кучи умных слов и полётов фантазии автора. Что-нить приземлённое и ближе к народу.
назовём этот паттерн "цепочка обязанностей в контексте извращённого сферического наследования в вакууме"
в последнее время появилась куча новых языков.. каждый второй пытается убить сиплюсплюс.. это ява, питон, семейство "точки нет".. но ничего у них не получается. почему? да потому, что они интерпретируемы. а это значит, что им для работы нужен интерпретатор / виртуальная машина / фреймворк , который будет следить за выделением и освобождением памяти, обеспечивать связь с внешним миром. ядро ос или драйвер устройства в таких условиях не попишешь, ибо потребление памяти, процессора тут куда выше. в функциональных языках всё ещё печальней - там нет такого понятия как "передача значения по ссылке", которое позволяет не гонять лишние байты из функции в функцию. в противоположность функциональным, императивные языки программирования допускают одновременную работу нескольких функций с одними и теми же данными. если отвлечься от сложностей с синхронизацией при одновременном доступе, погубной является сборка мусора на основе подсчёта ссылок, в основе которой лежит простая и естественная концепция: "если из программы никаким образом нельзя добраться до этих данных, то эти данные можно смело удалять из памяти". это всё хорошо ровно до тех пор, пока граф связей представляет из себя дерево. к сожалению в реальных ситуациях деревья встречаются крайне редко, вследствие чего появляются циклические ссылки, а их обнаружение является нп-полной задачей. как следствие существующие сборщики мусора потребляют много ресурсов, не гарантируя при этом отсутствие утечек. стремление упростить программисту работу с памятью вылилось в практически полную потерю контроля за этим процессом, далеко не идеальном в существующих реализациях. создание современных приложений реального времени предполагает разделение приложения на множество потоков. это позволяет более эффективно использовать ресурсы процессора/сервера/кластера, уменьшает связность между компонентами, выполняющими различные функции. концепция "процессы имеют доступ только к своим данным и обмениваются друг с другом сообщениями", идеально ложится на функциональную парадигму и, в то же время, замечательно иллюстрирует такий основополагающий принцип ооп как "инкапсуляция". идея, что "объект - это процесс", нашла своё отражение в функциональном языке erlang. суть объекта не в том, чтобы хранить данные и ссылки на методы, а в том, чтобы обрабатывать сообщения от сторонних объектов не предоставляя им прямого доступа к данным. однако, вернёмся к проблеме толчения воды в ступе... если мы, например, реализуем очередь дсп(цифровых звуковых процессоров), то достаточно естественно выделить каждый дсп в отдельный объект-процесс. и если на вход этой очереди подать данные, то при переходе от одного дсп к другому при функциональной парадигме эти данные будут копироваться, а это внушительная нагрузка на подсистему памяти. функциональная концепция, конечно, математически красива, но она не позволяет реализовать достаточно оптимально произвольный алгоритм. а для этого нам нужно иметь возможность посылать в сообщениях не только сами данные, но и ссылки на них. при этом (!) ссылка должна именно перемещаться, а не копироваться. то есть, чтобы область памяти, выделенная для одного процесса, просто переходила к другому. теперь второй процесс может сделать с этими данными всё, что угодно, и передать аналогично дальше в виде сообщения. если процесс, по какой-либо причине, хочет сохранить у себя эти данные - он просто создаёт их копию и отсылает её. это уже не функциональное программирование, а императивное, но с одной важной особенностью - на данные ссылка либо есть, либо её нет. две ссылки на одни и те же данные существовать не могут, а значит совершенно нет проблемы циклических ссылок. убиение объекта-процесса приводит к освобождению всей памяти, которая ему принадлежит в данный момент. также нет проблем с синхронизацией процессов - она обеспечивается за счёт механизма сообщений.