Cześć!

Ostatnio zainteresowałem się PEAR-em (z powodu kilku ciekawych pakietów). Do tej pory miałem o projekcie dobre zdanie - ogromna baza rozbudowanych, dobrze napisanych i zorganizowanych klas. Wiedziałem, że takie coś jest po prostu niezbędne, aby "zjednoczyć" świat programistów php ;-) Dziwiłem się też, dlaczego PEAR nie jest lubiany...

No, teraz już wiem

Wg. mnie pierwszym grzechem PEAR jest wykorzystanie PHP4. Rozumiem, że projekt powstał w dobie czwórki, ale mamy czasy piątki, która przecież nasz światek ździebko zrewolucjonizowała. A już na pewno otworzyła przed autorami klas PEAR nowe, ogromne możliwości. W obecnej chwili jedynym rozwiązaniem jest przepisanie wszystkich pakietów na PHP5.

Drugi grzech - instalator. Tak, bardzo fajne narzędzie, zwłaszcza, że od niedawna można stawiać własne serwery (czy jakoś tak to się nazywa...), no, wiecie o co chodzi Nie, trudno, że instalacja jednego pakietu trwa 10 minut - to jakoś przeżyjemy. Mnie najbardziej denerwują zależności.

Nie, to nie tak, że klasy muszą być niezależne. Ale powiedzmy, że mi starczy sam pakiet Services_Technorati. Ale nie, ja jeszcze muszę pobrać XML_Serializer (i to oczywiście nie wszystko!). Wydaje mi się, że już lepiej zaadoptować tylko te potrzebne funkcje XML_Serializera (bo to przecież ogromna klasa) w Services_Technorati. Nie, nie wydaje mi się. Ja jestem pewien

I tak dalej, i tak dalej... a więc co z tym PEAR-em? Warto wykorzystywać go we własnych projektach, a może pisać od zera? Zawsze pozostaje też wykorzystanie produktów konkurencji (eZ components) bądź... Zenda (ostatnio rozpoczęła się bitwa o Zend Frameworka - ponoć ten powiela klasy PEAR-a )... Co o tym sądzicie?

Co do implementacji w php 4, to racja. Sama obsługa błędów jest tragiczna.

Zależności między pakietami muszą być, a powielanie rozwiązań nie jest najlepszym pomysłem. Sam w swoim frameworku mam zależności (czasami jeden pakiet wymaga trzech mniejszych), bo po prostu nie da się tego włączyć do jednego pakietu. Po to mamy programowanie obiektowe, żeby nie musieć kopiować kodu i powielać błędów, a potem się męczyć z ich znalezieniem. Tak czy innaczej klasy nie powinny być za duże...

Gdyby nie fakt, że php za każdym razem musi przemielić te x linii kodu to nie byłoby przejmowania się, czy implementacja klasy zajmuje tyle czy tyle. php powinien posiadać jakiś kod pośredni (bytecode), który po skompilowaniu zawierałby tylko tą część implementacji, która została użyta w programie (i tak jak napisałem, nikt nie przejmowałby się czy przypadkiem klasa nie jest zbyt duża).

Ma, ale jeszcze w stadium eksperymentalnym. bcompiler" title="Zobacz w manualu php" target="_manual
Dodatkowo masz jeszcze optymalizatory, które przetrzymują kod zenda w pamięci, więc o parsowanie nie musisz się martwić specjalnie.

PEAR raczej nie z tego powodu jest mało popularny.

Powstaje PEAR 2.0, który jest pisany pod php, ale we większości pakietów mamy "php 4 and 5" ale jest to jeden wielki znak zapytania, ponieważ teraz Zend tworzy ZF, który ma własne komponenty.. chyba, że z PEARa zostanie sam instalator?


Jeśli dobrze pamiętam instalacja trwa tak długo ponieważ PEAR ściąga paczkę, rozpakowywuje ją i przenosi pliki wg package.xml. U mnie rekordowa była instalacja php Documentatora na starym kompie - 30 minut i użycie procesora na 100%.
Co do zależności:



Z PEARa najlepszy jest instalator. Z klas, które są na necie nie korzystam - instaluje przez to symfony, agavi, propela, creole, phinga. Szybko i wygodnie, bez walonki i rzemiosła.
Na pewno części rzeczy nie warto pisać od nowa, odpowiedź na pytanie "kiedy" już zależy od konkretnej sytuacji.

splatch: nie chodzi mi o to, że nie umiem zależności pobrać Po prostu są projekty, w których liczy się każdy kilobajt kodu, a klasy PEAR-a są zwykle tak rozbudowane, że 5 czy 10 klas zajmuje... no, dużo zajmuje. Miejsca na dysku.

Dochodzę do wniosku, że warto używać Zend Frameworka, którego klasy napisane są w standardach PEAR, tylko dla PHP5, i mają dobrą dokumentację. (I są JESZCZE względnie proste.)

A jednak gdzieś w głowie rodzi mi się pomysł zebrania kilku osób i napisania takiej podstawowej namiastki PEAR-a - proste, potrzebne klasy, bez instalatora, etc...

@ActivePlayer: ale my i tak nie bylibyśmy w stanie zgromadzić ekipy dorównującej PEAR-owi, a więc "przeładowanie klas" nam nie grozi

Moge sie mylić ale pear chyba kiedys tez mial zalozenie zgromadzis proste, potrzebne klasy w jednym miejscu

Mi sie wydaje ze pear to jest chyba jak narazie najlepszy zbior klas php w internecie, a co do tego ze sa w php4, to chyba wlasnoreczne przeobienie jednej klasy na php5 nie powinno zajac ci wiecej nic 20 minut, a co do predkosci dzialania to :

nasty_psycho, no więc właśnie nie chodzi o przerobienie jednej klasy na PHP5, tylko jej wszystkich zależności... Ale to nie chodzi o przepisywanie klasy na PHP5.

PEAR pod PHP5 pójdzie, a zmiana PHP4 -> PHP5 to nie tylko zamiana wszystkich var na public. Już wolę od nowa napisać całą klasę niż przepisywać PEAR na php 5

No wiec czmu sie przejmujesz ze to php4 ?
Ja pisze wlasnie cms-a w ktorym jest sporo PEAR-a caly projekt jest w php5, i wszystko bardzo ladnie chodzi...

nasty_psycho: PHP5 oferuje ogromne możliwości jeśli chodzi o obiekty (oj, jak to czyta jakiś programista SmallTalk/Java, to mi się dostanie ), które aż proszą się o użycie w niektórych pakietach PEAR. PHP4 i obiekty to skrajna prowizorka...

OBECNIE pisanie aplikacji pod PHP4 (jeśli nie wymaga tego klient) jest głupie

BTW, najnowsze pakiety PEAR lecą już na PHP5...?

Tak, sa juz pewne pakiety przerabiane na php 5 :
LINK

Jak dla PEAR jest very Ok, a zależności to akurat wielki plus tego pakietu. Ma dobrą dokumentacje, dobre klasy "na każdy ból" i w sumie nie zaczeło mi jeszcze przeszkadzać że są napisane dla php4. ale jak kto mówi co kto woli, chociaż to własnie w php jest najgorsze, że jest tyle rozwiązań że każdy swój problem rozwiązuje na swój własny sposób kożystając z wielu różnych reporytoriów, lub tak jak ktoś wyżej napisał, piszę swoję własne repozytorium. No i na końcu się okaże że na jedno programiste przypadnie jedno repozytorium ;-)

Jesli nie chcesz powielac kodu zaleznosci sa nieuniknione. Ludziska pisza klasy z zalozenia uniwersalne. Czesto niestety powstaja zaleznosci w ktorych do poprawnego dzialania jednej z klas potrzebna jest pojedyncza metoda innej klasy, ale musisz ja dolaczyc w calosci - jest to kompromis pomiedzy specjalizacja i optymalizacja a uniwersalnoscia i wygoda. Ja osobiscie jednak nie korzystam z dobrodziejstw "gruszki".

To czy PEAR jest napisany w PHP4, czy PHP5 ma mniejsze znaczenie od jego użyteczności. Zasada użycia jest prosta - nie chcesz lub nie możesz pisac sam jakiegoś kodu? Użyj PEAR i po problemie. Jeśli chcesz natomiast się sprawdzić w programowaniu, to napisz wlasne pakiety. Proste - dla każdego coś dobrego

PEAR to znakomity zbiór klass itp mi się bardzo podoba i nie wyobrażam sobie programowania bez tego.

prawie wszyscy z tego korzystają. No i nie ma nić lepszego ni Db_DataObject a to wchodzi w sklad pakietow pear

Moim zdaniem PEAR śmietnik, dosłownie kilka klas jest napisanych w pożądku reszta to kmioty.
Kod tragiczny i bardzo stary.

Jedyne co dobre w PEAR to instalator i linia komend.

Czyli mile dla admina nie dla programisty, a że ja raczej programuje niż administruje więc z PEAR nie korzystam bo dla mnie to kocioł.

z PEAR'a korzystam jedynie z pakietu DB (teraz MDB2 bo wchłonął DB i to on jest dalej rozwijany). Od dawna z nim pracuje i nie miałem większych problemów, komatybilny z php5. Denerwującą rzeczą są jednak duże rozmiary pakietów, które jak tu już wspominają wynikają gł. z dość dużego kotła w kodzie, a więc modyfikacja jest trudna i mozolna.. Obecnie szukam zastępczych rozwiązań, ale póki co stary jary PEAR