однако используемые при этом другие динамические компоненты языка обеспечивающие в частности создание свойств и методов класса в процессе выполнения и первинчого обращения к ним - фактически не поддерживают ООП-концепцию со статическим и структурированным предсавлением информационных полей
Верно, но ведь изменять свойства и классы в процессе выполнения система не сама будет а программист это укажет. Если это воля программиста значит можно и так и эдак.
На C++ можно же процедурами все делать аля C
Поясните.
Почему к примеру нельзя создать класс database отвечающий за связь с базой данных и для конкретной реализации использовать его.
Можно создать классы наследники аля mySQLdatabase, MSSQLdatabase.
Почему нельзя создать класс таблица, которому отдавать класс database
Почему нельзя создать класс dataset который примет в себя много таблиц, отнаследоваться от него, к примеру урезав количество колонок ... и так далее.
вот я начал писать скрипт, в нем уже есть 1000 строк кода, будет еще тысячи 3 - большой ли это проект?
Нет не большой. Хотя что за манера мерять размер проектов строками.
Кто знает что вы пишите может вы массивы инициализируете ;)
$a[1] =1;
$a[2] =2;
...
$a[1000] =1000;
Вау, тема отдельная стала. Уж и не знаю плакать или радоваться.
По порядку. ту Вайпер.
Изначально скриптовые языки (включая ПХП) не имели ничего общего с ООП.
На момент их рождение куда как важнее было строить страницы состоящие из ХТМЛ кода и небольшой части динамики. Данное состояние подталкивало к прямому писанию кода (даже с забиванием на функции), так как большая часть проектов представляла собой странички где код прописывался персонально для страницы. С ростом скоростей инета сайты стали усложняться, но как известно привычка дело заразное. Принципы что построения приложений были те же. В это время системы разработчики "дескктопного" уровня уже не понимали как это раньше софт писали без компонент ... Но произошло следующие (происходит). Оказалось что несмотря на развитость систем десктопного базирования, сетевое софт основанный на WEB это круто. Люди принимающие решение какой софт купить заказать или разработать знают что декстопное приложение это гемор. И ОС подавай какую надо дорогую и антивирус обновляй, про обновление приложений самих и несовместимость библиотек я вообще молчу. Вообщем все с улюлюканиями и радостными возгласами ринулись в эпоху вэба, и с чувством глубокого удовлетворения встречают всякие iPad и ChromeOS.
Но тут возникла неожиданная проблема. Оказалось что те кто писал всякие десктопы, никак не могут взять в толк как это вообще работает вэб приложение. Где понимаешь мой контекст и индивидуальное адресное пространство с эксклюзивным доступом к процессору.
(Случай произошел со мной 7 лет назад. Заспорили мы как то что круче PHP+MySQL или Java+Oracle. Спор по сути глупый, но схватились не на шутку. Тут же было дано задание в отдел жаб сделать тестовое вэб приложение и аналогичное вэбщикам. Вэбщики выйграли 1000:1. Самое смешное что это произошло не потому что ПХП и мускул круче жабы с ораклом, а потому что явщики использовали методы написания кода как для десктопного приложения.)
Ну так возвращаюсь так сказать к вопросу. Хм, сказали манагеры, если низя эффективно использовать старых программеров, то надо нанять вэбщиков которые сайты делают и они то нам огого как понапишут. Бросили вакансии и пошли отклики, да не просто а сотнями и один краше другого. И у всех в резюме понаписано ООП всякое, да и денех не сильно просят. Обрадовались манагеры, и давай нанимать и проекты затеивать. Бля (извините) начинают быстро а потом вязнут. И друг с другом договориться не могут, один не понимает что другой написал.
(Опять таки личный случай из 2010 года. Нанял я программера на ПХП, на собеседовании определения полиформизма от зубов отскакивали. Посадил и грю, сделай ка мне объект чтоб ему таблицы указывать а он сам данные JSON фигачел на клиента. Че сказал он. Лано сказал я и даю ему через пару дней код DataSet с примерами. Наследуйся и делай мне форму Клиентов, Товаров ....
Не парься со страницами, сортировками и фильтрами, класс сам усе понаделает. Алилуя сказал он и почесал работать. Бодро так. Стали формы появляться и с данными и даже работали.
Через неделю сел я значит посмотреть что он там такое творить. И о мама. Вместо наследования он стал добавлять в мой класс методы, да какие getCleintsJSON, getItemsJSON ... зову я его и грю, Саша ты седня вот вещи собирай а завтра не приходи на работу.)
Ой что то разговорился я, видимо наболело. Я это все к тому, что нужно брать из всех систем хорошее и нужно и совмещать делая лучшие продукты. И с этим реально тяжело.
Ну есть среди разработчиков и исключения. Ну их мало к сожалению или как минимум недостаточно.
Извините за сумбур, тема для меня просто больная
ту Варяг
Большой проект это тот где кода много.
И инет магазин и доску объявлений можно по разному сделать.
Раз для вас это хобби то смело используйте ООП!
ту JustUserR
Все верно, однако так же верно и то что именно программист выбирает стиль написания
кода. И в его силах построить код на принципах ООП
ООП это то что дает экономию времени, читабельность и модификабельность кода.
WEB становиться платформой для разработки серьезных приложений и принципы скриптовых языков уже не приемлемы (но допустимы для малых проектов).
А уж быстрее оно или медленнее, не важно.
Даже если и медленнее на ПХП оно, то разница не значительно. Куда как большую разницу даст грамотное написание кода и оптимизация SQL.
Мое мнение такое. Пора WEB разработчикам использовать OOP.
Те кто не научиться, останутся "за бортом корабля".
P.S.
Лично обучил ООП 2х PHPников матерых. Люди офигивали от того насколько быстро и красиво можно писать код используя наследование и перегрузку методов.
в силу этой причины статический парсер принципиально не может определить необходимо ли добавлять некоторый глобальный элемент в таблицу имен или нет
Yes it is.
Но! таки если ум мы говорим что мы используем ООП то не следует писать код с включением чего попало и где попало.
PHP уже выходит и состояния языка с синтаксисмом и стилем аля Basic89
В больших проектах нужно применять методы и стили аналогично старшим братьям C++ Java, в противном случае код становиться хаотическим трудно и долго изменяемым и неконтролируемым.
Эх, беглый анализ позволил выяснить следующие
Смысл сводиться к возможности компиляции без выполнения или с выполнением но не в основном потоке и "курочиния" кода на лету. А вот что есть в файле ответа нет (Добавление)
Хочется то в сущности получить следующую вещь
Файл xxx.php
Массив внешних подключаемых модулей (include)
Массив классов
Массив переменных
Массив функций
Массив констант
Конечно переменные в внутри функции и методы класса не нужны, их всегда можно получить зная имя класса.
А вот список имен классов, функций, это проблема если в файле есть include/require (Добавление) http://www[dot]tig12[dot]net/spip/Parsing-PHP-code[dot]html
Нарыл, чел решал подобную проблему и пришел к выводу что надоть использовать парсер а не машину PHP
Как получить список классов, функций и переменных объявленных в нем
Для проведения анализа PHP-скриптов в действительности наиболее оптимальным вариатом является использованите встроенных средств оригинального интерпретатора - дело в том что PHP является динамическим языком и для получения полной информации об некоторой PHP-программе собственными средствами необходимо провести ее исполненение по всем правилам языка - тем не менее благодаря использованию пакета runkit и его набора функций sandnox вы можете произвести такую интерпретацию в управляемом режиме с применением оригинального анализатора
Вау, тема прикольная, но надо изучать. Спасибо за наводку!
eai, это понятно. Я привел наглядный пример для топикстартера. Ведь он мог и не знать этого. А так знает, что первый элемент массивы имеет соответственный ключ.
Дык, если про массив не знает, то про неявное индексирование точно не знает, просто дополнил твой правильный ответ.
У вас переменная $k постоянно меняет свое значение. Возможно узнать только, какое ее текущее значение(последнее). Если хотите сохранять все значения, объявляйте $k как массив:
Система сама будет присваивать индекс целочисленный по нарастающей.
В последствии массив можно обработать с помощью foreach или с помощью получения границ массива и прямого обращения.
Для работы с классами можно воспользоваться Reflection Api
Тема интересная, не знал о её существовании, спасибо за наводку.
Однако это немного не то.
Это API позволяет узнать все про классы функции и.т.д, но не дает знаний о том, что есть конкретном файле.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 520
нет, не массивы. ООП уже пробовал, но многое не понятно. в частности сам процесс разбивания на методы, а еще менее понятно наследование. 
вот я начал писать скрипт, в нем уже есть 1000 строк кода, будет еще тысячи 3 - большой ли это проект?
