> К примеру как вы их расширений будете экспортировать классы?
это куда нам их потребовалось экспортировать? если мне нужно расширить функционал класса - я от него наследую.
>А разве не вы говорили, что PEAR применяется при не возможности использования, бинарных расширений?
я говорил что эти два репозитария отличаются тем, что в одном лежат С-модули, в другом РНР. я говорил о том, что С-модуль на виртуальном хостинге нет возможности использовать. но я никогда не говорил, что PEAR может заменить PECL модуль. это вы такое уже додумали. и я даже знаю почему. потому что считаете что они выполняют одинаковые функции.
все хорошо и красиво. но только в теории. на практике в проект вмешивается огромное число рисков. а о них нет ни слова в этой статье. а значит - тот график, что вы нарисовали с вероятностью, близкой ко 100%, не будет выполнен.
>утилита вообще-то штатная
у меня оно вообще отказалось работать. если взялись админить *nix сервер, то работайте ручками :) тем более что "ручками то понятно что там и какое стоит".
>Ну на тяжелых операциях не совсем понятно зачем использовать PHP.
смотрите архитектуры больших приложений. например, в одном из топиков вам raa давал ссылку на яху (если мне память не изменяет).
>А что функций XML_DTD и XML_Parser чего делают
эсли вы почитаете наконец описание пакета, то увидите на чем он базируется. этот модуль предоставлет интерфейс.
>Спасибо, но portage намного удобнее ports
ну что, еще одна религиозная война? :D
>Рассылки мало что говорят о иделогии и того как оно там делается.
если это было бы так, я бы не советовал на них подписываться.
>Хотя опять же классы на самом языке более расширяемы.
это почему? никакой принципиальной разницы (в плане программирования) нет откуда будут использован функционал.
>Нет, я предлагаю базировать велосипеды, на базе бинарных расширений.
так PEAR именно это и делает.
например, нам надо работать с железом или с системой, или перед нами стоит ресурсоемкая задача.
Хорошо задам вопрос подругому. PDO оно дублирует или нет. Если нет то почему?
в части функционала - наверняка. но дает нам возможность использовать любой, из имеющихся в наличии драйверов + мы не зависимы от изменений интерфейса расширения. еще рекомендую просмотреть одно обсуждение.
И так же понимаем, что это может быть так же реализовано средствами DOM.
т.е. вы предлагаете каждый раз изобретать велосипед заново?
К тому что у меня не показываются установленные расширения их базового дистрибутива. А чем ставите расширения из pecl?
теперь я понимая что жаловаться то надо не на PECL, а на некоторую утилиту, которой вы ставите расширения. я предпочитаю делать ручками (если мы говорим о *nix). ссылку на то, как это рекомендовано делать, я уже давал выше.
есть код для работы с XML.
смотрим и понимаем, что модули имеют вполне конкретные цели.
Их существование допустимо только из-за модели PHP.
не только. и уже не раз говорил об этом. С-расширения имеет смысл делать если имеется тяжелая (ресурсоемкая) операция или мы приходим к системным ограничениям языка (например, нам надо работать с железом или с системой). PEAR - это (в большинстве своем) набор "велосипедов" для конкретных действий, которые нет смысла писать на компилируемых языках. на такой велосипед сел и поехал. однако, сам PEAR не лешен недостатков. например - необходимость поддерживать возможность использования классов и в 4й и 5й версии.
В таком случае не понимаю зачем было делать такое функциональный менеджер.
менеджер? мы говорили о репозитарии...
С чего вы взяли? :) Я предпочитаю модульность большим кускам.
я имел ввиду тот факт, что в дистрибутивы ОС включены различные сторонние модули и приложения ;)
Но пока на данный момент в Gentoo ...
используйте правильные системы, например FreeBSD :D
В случае если модуль дает необходимую абстракцию и является стандартным такой слой абстракции можно свести к минимуму.
вы забываете, что помимо собственно абстрагирования мы получаем свой интерфейс. и этот интерфейс дает нам гарантию того, что изменения во внешнем модуле не приведет к необходимости переписывать приложение с нуля заново.
К сожалению для PHP не видел ни того ни другого.
согласитесь, это не является проблемой языка ;) про идеалогию думаю лучше всего может рассказать подписка на рассылку, расширения - см. выше, я давал ссылку на Zend API
Есть разные *nix ОС и те что обладают пакетными менеджерами основное ядро все равно держат как пакеты. Это требуется для того чтобы была возможность простого обновления.
это к чему было сказано?
pecl list - показывает установленные расширения
а это что за инструмент? никогда его не использовал.
Выполняют они одни и те же функции.
делить только этому принципу нельзя. надеюсь, как ооп-программисту вам не надо это объяснять.
А почему тогда по аналогичным причинам не убрать две из трех реализаций mysql? В таком случае эти расширения должны быть в PECL.
не должны. потому что в PECL остаются либо малопопулярные, либо експериментальные расширения.
Ну не понимаю я такой модели когда в дистрибутив пихают сторонние модули при наличии механизма их установки.
как же вам тяжело приходится при работе с *nix дистрибутивами...
Угу она решается одним из блоков абстракции. Но это как раз один из велосипедов
это не велосипед. это грамотно спроектированное приложение. в котором зависимость от внешних модулей сводится к минимуму.
А что идеология языка и "стиль кодирования" расширений и самого языка вещи не взаимосвязанные?
связь между ними безусловно существует. но это принципиально разные документы, и у них совершенно разные цели. это все равно что пытаться сравнивать устав предприятия и его внутренние документы.
компания Zend разрабатывает движок. комунити разрабатыват расширения, делает сборки и выпускает билды. все довольны и счастливы :)
Если бы PHP было выполнено как базовое ядро + PECL + установленные через него расширения , то было бы несколько удобнее.
есть дистрибутив, который включает в себя определенный набор расширений. если вам не хватает чего-то - идете в PECL, скачиваете, ставите. это обычная практика. возмите любую *nix-подобную ОС.
а потом при дальнейшей установке PECL они не отображаются в его списке
в каком списке? вы говорите загадками.
Ни одного из расширений которые есть в дистрибутиве в списке PECL нет.
наверное мы из разных источников берем дистрибутивы...
Разницу я понимаю. Я не понимаю к чему они столько сущностей наплодили
Довод простой. Поддерживать одну реализацию проще чем три.
вы забываете о том, что существует комунити, которое поддерживает те расширения, которые нужны самому комунити.
проблема отстутствия абстрактного слоя работы с СУБД исчезнет.
в грамотно спроектированном приложении такой проблемы не существует. в принципе.
Вы разницу между официальным документом и листом рассылки понимаете? Вот к примеру к ядру Linux есть документ в котором описано какого стиля надо придерживаться если вы хотите, чтобы ваш патч вошел в ядро.
вы не понимаете разницы между "стилем кодирования" и идеалогией развития языка? о чем мы вообще говорим?
А у меня есть ощущение, что господа не смогли осилить быстрый интерпретатор поэтому породили два репозитория, тот что побыстрее и тот что помедленне
это вам только кажется. повторюсь - если вы не видите разницы между пакетом, который нужно собрать, откомпилировать, установить и пакетом, который разворачивается на _любом_ виртуальном хостинге, то помочь в преодолении этого предрасудка очень сложно :)
в который раз хочется конкретики - кто "они", и про что говорят "шаблонизатор"? :)
Просто если функции не помечать как "устаревшие" никто с них переходить не будет.
согласитесть, "устаревший" и "deprecated" различные понятия. deprecated должно помечаться то, что противоречит существующей концепции языка. поверьте (ну или сделайте поиск по слову deprecated по php.net), функции и подходы, которые действительно "мешаются" именно так и помечаются.
Если его поддерживают сами разработчики PHP и они считают, что оно должно входить в базовый пакет языка флаг им в руки. Или там все сторонние модули поддерживаются разработчиками PHP
мне кажется вы так и не понимаете принципов заложенных в расширения. расширение - это то, что нет необходимости включать в ядро языка, поскольку оно может кому-то не потребоваться. часто - расширение является враппером для какой-то библиотеки (например, теже расширения для БД). или просто реализует неких функционал (например, функции работы с фтп). и еще - что вы подразумеваете под "разработчиками РНР"? есть компания Zend, которая разрабатывает движок, есть комунити, которое разрабатывает расширения, делает сборки. вы о ком говорите?
Зачем пихать в ядро поддержку xml я не знаю. Все же логичнее было бы запихать ее в отдельный модуль.
так оно и есть в отдельном модуле.
Это компиляция расширений PECL. А я говорил, про те что входят в дистрибутив PHP. Каким образом мне собрать расширение оттуда?
а чем расширение PECL, отличается от того, что есть в дистрибутиве? (кроме того, что PECL содержит последние исходники расширений).
Но вот сейчас я проверил, на одной из машин где установлен PHP и пара пакетов из pecl. И к сожалению в списках pecl установленных расширений я не увидел.
это какие расширения? может они и в дистрибутив не входят? ;)
Pecl - менеджер используемый для установки/обновления/удаления расширений PHP написанных на C.
Ну как вам сказать. Не очень это логично.
не находите, что сами себе противоречите, либо не понимаете разницы между PECL и PEAR. смотрите сообщение
Тогда почему-бы не убрать все расширения типа mysql и mysqli в PECL
если вы считаете что идеалогия для языка - это что-то костное, никогда не меняющееся, то глубоко заблуждаетесь. другое дело, что дать прямую ссылку на страницу, где будет расписана "идеалогия разработки" я затрудняюсь. но если вам интересно, то без труда сможите определить ее читая листы рассылки. в общих чертах для 6 версии заявлена полная поддержка юникода.
Хочу как в java
так пользуйтес java, получайте тяжелые приложения, которые можно использовать только для внутрикорпортативных разработок :) и не надо утверждать, что РНР использует "не правильную" концепцию ;)
Вообще речь шла о том что он там уже есть. То что реализовать то не проблема это понятно.
еще раз - такой подход "есть" в любом языке, в котором есть возможность прочитать файл и использовать функцию замены.
Я говорил про совместимость от версии к версии. Т.е. если имеем версию 4 и версию 5, то в 5 версии все что планируется снести помечаются как deprecated, а в 6 версии удаляются. Разумный надеюсь баланс между совместимостью и новшествами?
не разумный. снести и оставить расширение в PECL - две большие разницы. есть еще достаточно много приложений, написанных еще под 3ю версию. и они вполне выполняют возложенные на них задачи. где мы будем брать расширения под старые версии? или наоборот, вот есть расширение mnoGoSearch - оно вполне себе работает у меня под 5.2, хотя оно давно вынесено в PECL.
и единая идеалогия. если интересно - подпишитесь на листы рассылок
Но иногда мне приходилось пересобирать PHP
собирайте расширения и подключайте их. если вы хотите и функционал получить и ничего не делать ручками - может стоит задуматься о смене рода деятельности ;)
Из файла.
а есть популярные языки, в которых отсутствует чтение из файла?? я таких не знаю. а если есть возможность прочитать и сделать замены в строке, то ничего не мешает реализовать такой "встроенный" шаблонизатор на любом языке.
Но если бы они вынесли DOM XML к примеру в тот же PECL или объявили его DEPRECATED
скажите, а вы смотрите те ссылки, что я даю? зачем вы просили их активно использовать, если все равно их не смотрите? DOM XML.
а удалили бы в версии 6 было было бы логичнее
а как же обратная совместимость, за которую вы так ратуете постами выше?
Если это сторонние модули, то почему они в дистрибутиве?
давйте представим, что расширение mysql для РНР отсутствует. вы решили, что такое расширение просто жизненно необходимо для языка. вы его написали, закоммитили, расширение попадает в PECL, далее все понимают, что расширение оказылось крайне полезным для большинства разработчиков. оно включается в дистрибутив. я ответил на вопрос?
Мне вот кажется, что модули все же одним способом должны подключаться
вам кажется не правильно. язык может быть использован в большом проекте, работать на сервере, на который возложена обработка сообщений пользователей. с xml такой скрипт не работает. понятно, что собирать нужно без этого модуля. смотрим другую ситуацию - у нас есть виртуальный хостинг. большинству клиентов xml также не нужен. зачем собирать ядро с поддержкой языка? мы включаем расширение для конкретного хоста, при этом большинство клиентов не ждут пересборки ядра. это вопрос гибкости в настройках.
Хорошо ткните в ссылку которая рассказывает как собрать модуль идущий в дистрибутиве PHP и при этом не пересобирая его.
Если бы все расширения соответствовали PECL и ставились из него я бы согласился, что действительно все сделано хорошо и корректно. Но на данный момент ведь это не так?
вы можете найти все расширения, в том числе те, которые включены в дистрибутив, в PECL. при этом в дистрибутив не включены расширения, которые малопопулярны, либо имеют статус "экспериментальный".
Во первых получается разброд и шатание с тем откуда и как берутся модули.
вот если разобраться что же такое PECL - все встанет на свои места. надеюсь то что написано выше в этом посте поможет этому.
и аж два репозитария PECL и PEAR.
да, в одном (PECL) расширения, написанные на С и которые необходимо собирать, в другом - написанные на самом РНР (PEAR). это очень логично и не вносит никакой путаницы.
Наличие трех различных способов подключения к MySQL это логично?
на мой взгляд - очень логично. поскольку позволяет элегантно сохранить обратную совместимость с большим количеством программ, разработанных ранее (расширение mysql). при этом мы получаем возможность работать через объектную модель ноступа (mysqli), либо через универсальный драйвер (pdo). при правильной организации архитектуры приложения вообще без разницы какой драйвер бутет использован.
Причем два их них входят в дистрибутив.
в дистрибутив входят все три.
он пишется большим количеством людей без каких либо четких соглашений
на сколько я понимаю - отсутствие соглашений это ваше личное предположение? или вы где-то это прочитали?
это куда нам их потребовалось экспортировать? если мне нужно расширить функционал класса - я от него наследую.
>А разве не вы говорили, что PEAR применяется при не возможности использования, бинарных расширений?
я говорил что эти два репозитария отличаются тем, что в одном лежат С-модули, в другом РНР. я говорил о том, что С-модуль на виртуальном хостинге нет возможности использовать. но я никогда не говорил, что PEAR может заменить PECL модуль. это вы такое уже додумали. и я даже знаю почему. потому что считаете что они выполняют одинаковые функции.
у меня оно вообще отказалось работать. если взялись админить *nix сервер, то работайте ручками :) тем более что "ручками то понятно что там и какое стоит".
>Ну на тяжелых операциях не совсем понятно зачем использовать PHP.
смотрите архитектуры больших приложений. например, в одном из топиков вам raa давал ссылку на яху (если мне память не изменяет).
>А что функций XML_DTD и XML_Parser чего делают
эсли вы почитаете наконец описание пакета, то увидите на чем он базируется. этот модуль предоставлет интерфейс.
>Спасибо, но portage намного удобнее ports
ну что, еще одна религиозная война? :D
>Рассылки мало что говорят о иделогии и того как оно там делается.
если это было бы так, я бы не советовал на них подписываться.
это почему? никакой принципиальной разницы (в плане программирования) нет откуда будут использован функционал.
>Нет, я предлагаю базировать велосипеды, на базе бинарных расширений.
так PEAR именно это и делает.
например, нам надо работать с железом или с системой, или перед нами стоит ресурсоемкая задача.
в части функционала - наверняка. но дает нам возможность использовать любой, из имеющихся в наличии драйверов + мы не зависимы от изменений интерфейса расширения. еще рекомендую просмотреть одно обсуждение.
т.е. вы предлагаете каждый раз изобретать велосипед заново?
теперь я понимая что жаловаться то надо не на PECL, а на некоторую утилиту, которой вы ставите расширения. я предпочитаю делать ручками (если мы говорим о *nix). ссылку на то, как это рекомендовано делать, я уже давал выше.
смотрим и понимаем, что модули имеют вполне конкретные цели.
не только. и уже не раз говорил об этом. С-расширения имеет смысл делать если имеется тяжелая (ресурсоемкая) операция или мы приходим к системным ограничениям языка (например, нам надо работать с железом или с системой). PEAR - это (в большинстве своем) набор "велосипедов" для конкретных действий, которые нет смысла писать на компилируемых языках. на такой велосипед сел и поехал. однако, сам PEAR не лешен недостатков. например - необходимость поддерживать возможность использования классов и в 4й и 5й версии.
менеджер? мы говорили о репозитарии...
я имел ввиду тот факт, что в дистрибутивы ОС включены различные сторонние модули и приложения ;)
используйте правильные системы, например FreeBSD :D
вы забываете, что помимо собственно абстрагирования мы получаем свой интерфейс. и этот интерфейс дает нам гарантию того, что изменения во внешнем модуле не приведет к необходимости переписывать приложение с нуля заново.
согласитесь, это не является проблемой языка ;) про идеалогию думаю лучше всего может рассказать подписка на рассылку, расширения - см. выше, я давал ссылку на Zend API
например потому, что у РНР есть вполне конкретные системные ограничения.
надеюсь не надо пояснять разницу между драйвером бд и кодом, организующим абстрактный слой?
смотрим и понимаем, что модули имеют вполне конкретные цели.
с нетерпением жду продолжения :)
это к чему было сказано?
а это что за инструмент? никогда его не использовал.
делить только этому принципу нельзя. надеюсь, как ооп-программисту вам не надо это объяснять.
не должны. потому что в PECL остаются либо малопопулярные, либо експериментальные расширения.
как же вам тяжело приходится при работе с *nix дистрибутивами...
это не велосипед. это грамотно спроектированное приложение. в котором зависимость от внешних модулей сводится к минимуму.
связь между ними безусловно существует. но это принципиально разные документы, и у них совершенно разные цели. это все равно что пытаться сравнивать устав предприятия и его внутренние документы.
самостоятельно пишем С-расширение для РНР.
компания Zend разрабатывает движок. комунити разрабатыват расширения, делает сборки и выпускает билды. все довольны и счастливы :)
есть дистрибутив, который включает в себя определенный набор расширений. если вам не хватает чего-то - идете в PECL, скачиваете, ставите. это обычная практика. возмите любую *nix-подобную ОС.
в каком списке? вы говорите загадками.
наверное мы из разных источников берем дистрибутивы...
затем, что это разные сущьности.
поэтому
вы забываете о том, что существует комунити, которое поддерживает те расширения, которые нужны самому комунити.
в грамотно спроектированном приложении такой проблемы не существует. в принципе.
вы не понимаете разницы между "стилем кодирования" и идеалогией развития языка? о чем мы вообще говорим?
это вам только кажется. повторюсь - если вы не видите разницы между пакетом, который нужно собрать, откомпилировать, установить и пакетом, который разворачивается на _любом_ виртуальном хостинге, то помочь в преодолении этого предрасудка очень сложно :)
мне кажется что проблемы вообще не существует ни для кого, кроме вас ;)
то, что PEAR - это модули, написанные на РНР, а PECL - это С-расширения. у них разные задачи.
в который раз хочется конкретики - кто "они", и про что говорят "шаблонизатор"? :)
согласитесть, "устаревший" и "deprecated" различные понятия. deprecated должно помечаться то, что противоречит существующей концепции языка. поверьте (ну или сделайте поиск по слову deprecated по php.net), функции и подходы, которые действительно "мешаются" именно так и помечаются.
мне кажется вы так и не понимаете принципов заложенных в расширения. расширение - это то, что нет необходимости включать в ядро языка, поскольку оно может кому-то не потребоваться. часто - расширение является враппером для какой-то библиотеки (например, теже расширения для БД). или просто реализует неких функционал (например, функции работы с фтп). и еще - что вы подразумеваете под "разработчиками РНР"? есть компания Zend, которая разрабатывает движок, есть комунити, которое разрабатывает расширения, делает сборки. вы о ком говорите?
так оно и есть в отдельном модуле.
а чем расширение PECL, отличается от того, что есть в дистрибутиве? (кроме того, что PECL содержит последние исходники расширений).
это какие расширения? может они и в дистрибутив не входят? ;)
не находите, что сами себе противоречите, либо не понимаете разницы между PECL и PEAR. смотрите сообщение
хотя бы по этому.
для того чтобы:
какие доводы есть против такого подхода?
я уже давал ссылки на листы рассылки. если подпишитесь то увидите обсуждения тех или иных изменений.
если вы считаете что идеалогия для языка - это что-то костное, никогда не меняющееся, то глубоко заблуждаетесь. другое дело, что дать прямую ссылку на страницу, где будет расписана "идеалогия разработки" я затрудняюсь. но если вам интересно, то без труда сможите определить ее читая листы рассылки. в общих чертах для 6 версии заявлена полная поддержка юникода.
так пользуйтес java, получайте тяжелые приложения, которые можно использовать только для внутрикорпортативных разработок :) и не надо утверждать, что РНР использует "не правильную" концепцию ;)
еще раз - такой подход "есть" в любом языке, в котором есть возможность прочитать файл и использовать функцию замены.
не разумный. снести и оставить расширение в PECL - две большие разницы. есть еще достаточно много приложений, написанных еще под 3ю версию. и они вполне выполняют возложенные на них задачи. где мы будем брать расширения под старые версии? или наоборот, вот есть расширение mnoGoSearch - оно вполне себе работает у меня под 5.2, хотя оно давно вынесено в PECL.
и единая идеалогия. если интересно - подпишитесь на листы рассылок
собирайте расширения и подключайте их. если вы хотите и функционал получить и ничего не делать ручками - может стоит задуматься о смене рода деятельности ;)
а есть популярные языки, в которых отсутствует чтение из файла?? я таких не знаю. а если есть возможность прочитать и сделать замены в строке, то ничего не мешает реализовать такой "встроенный" шаблонизатор на любом языке.
скажите, а вы смотрите те ссылки, что я даю? зачем вы просили их активно использовать, если все равно их не смотрите? DOM XML.
а как же обратная совместимость, за которую вы так ратуете постами выше?
давйте представим, что расширение mysql для РНР отсутствует. вы решили, что такое расширение просто жизненно необходимо для языка. вы его написали, закоммитили, расширение попадает в PECL, далее все понимают, что расширение оказылось крайне полезным для большинства разработчиков. оно включается в дистрибутив. я ответил на вопрос?
вам кажется не правильно. язык может быть использован в большом проекте, работать на сервере, на который возложена обработка сообщений пользователей. с xml такой скрипт не работает. понятно, что собирать нужно без этого модуля. смотрим другую ситуацию - у нас есть виртуальный хостинг. большинству клиентов xml также не нужен. зачем собирать ядро с поддержкой языка? мы включаем расширение для конкретного хоста, при этом большинство клиентов не ждут пересборки ядра. это вопрос гибкости в настройках.
легко
вы можете найти все расширения, в том числе те, которые включены в дистрибутив, в PECL. при этом в дистрибутив не включены расширения, которые малопопулярны, либо имеют статус "экспериментальный".
вот если разобраться что же такое PECL - все встанет на свои места. надеюсь то что написано выше в этом посте поможет этому.
да, в одном (PECL) расширения, написанные на С и которые необходимо собирать, в другом - написанные на самом РНР (PEAR). это очень логично и не вносит никакой путаницы.
на мой взгляд - очень логично. поскольку позволяет элегантно сохранить обратную совместимость с большим количеством программ, разработанных ранее (расширение mysql). при этом мы получаем возможность работать через объектную модель ноступа (mysqli), либо через универсальный драйвер (pdo). при правильной организации архитектуры приложения вообще без разницы какой драйвер бутет использован.
в дистрибутив входят все три.
на сколько я понимаю - отсутствие соглашений это ваше личное предположение? или вы где-то это прочитали?