Włączanie plików + autoloader, chętnie bym posłuchał ciekawych pomysłów Opcje

[hawk]

Ciekawe rozwiązanie. Faktem jest, że mi by się nie chciało . Zwłaszcza że ja raczej na początku mam rozplanowane klasy, a potem głównie edytuję zawartość nie ruszając struktury.

Co do plików ini... rezultat ten sam. Dla ciekawości, sprawdzałeś, czy są szybsze od zwykłego php? Chociaż wada jest taka, że ja bym w pliku php bardzo chętnie umieszczał mapę wykorzystując jakąś zmienną - główny katalog projektu. Po to, aby ktoś, kto tego używa, nie musiał generować dla siebie mapy tylko dlatego, że u niego pliki php są w innym miejscu na dysku.

[dr_bonzo]

W koncu. Kod przepisany od nowa, lecz jeszcze nie dopieszczony:
http://northslope.lap.pl/dev/Autoloader/0.2-dev/

a tu zrodla do pobrania:
http://northslope.lap.pl/dev/Autoloader/au...-0.2-dev.tar.gz

Kod

generowanie mapy (cache puste):
Array
(
   [files_found] => 468
   [files_parsed] => 468
   [classes_found] => 233
)
Map generation time: :: 12.85658 sec

a z cache (nic nie zmienione):
Array
(
   [files_found] => 468
   [files_parsed] => 0
   [classes_found] => 233
)
Map generation time: :: 0.23078 sec

map from php: :: 0.00076 sec
map from ini: :: 0.00412 sec

php szybsze od INI

PSy: statystki (files_parsed)w udostepninych zrodlach sa nieprawidlowe, te wyzej sa ok.
Testowane na P3 @ 560

Ten post edytował dr_bonzo 5.06.2005, 02:21:56

[Imperior]

dr_bonzo: http://wiki.php.pl/index.php/RecursiveDirectoryIterator
Czyż nie łatwiej?

[hawk]

Fajny kod. Nawet zdążyłem już użyć .

Kilka uwag:
- nie można podać extension np. "class.php", co jest bardzo przydatne, bo pozwala pominąć unit testy ("test.php"). Musiałbyś zmienić metodę isFileExtensionOnTheList tak, aby po prostu sprawdzała, czy nazwa pliku kończy się jednym z podanych wzorców
- przy pierwszym wywołaniu dostaję warning, że cache jeszcze nie istnieje. Potem jest OK.
- RecursiveDirectoryIterator uprościłby sprawę
- przydatną funkcją byłoby parsowanie tagów phpdoc (jeżeli są), aby pomijać klasy "wewnętrzne", czyli takie, które wykorzystywane są tylko w obrębie danego pliku i nie ma potrzeby wystawiać ich na zewnątrz. Ja takich mini-klas używam, i brakuje mi możliwości zrobienia prywatnej klasy wewnętrznej jak w Javie...

[dr_bonzo]

- nie można podać extension np. "class.php", co jest bardzo przydatne, bo pozwala pominąć unit testy ("test.php"). Musiałbyś zmienić metodę isFileExtensionOnTheList tak, aby po prostu sprawdzała, czy nazwa pliku kończy się jednym z podanych wzorców

[DONE] Jest w TODO

- przy pierwszym wywołaniu dostaję warning, że cache jeszcze nie istnieje. Potem jest OK.

Kod jeszcze "niedopieszczony" wersja dev -- dziala ok, pokazuje wszystkie bledy na ekranie, potem dodam malpy do funkcji

- RecursiveDirectoryIterator uprościłby sprawę

[DONE] Zgadza sie. Poprawie

- przydatną funkcją byłoby parsowanie tagów phpdoc (jeżeli są), aby pomijać klasy "wewnętrzne", czyli takie, które wykorzystywane są tylko w obrębie danego pliku i nie ma potrzeby wystawiać ich na zewnątrz.

Troche roboty bedzie. A jaki znacznik odpowiada za plikowy zasieg klasy?

PS. [files_found] to liczba znalezionych plikow z wybranymi rozszerzeniami
-------------------------------------------
EDIT

podglad kodu online
http://northslope.lap.pl/dev/Autoloader/au...-0.3.0-sources/

paczka
http://northslope.lap.pl/dev/Autoloader/au...er-0.3.0.tar.gz

Ten post edytował dr_bonzo 7.06.2005, 11:27:39

[hawk]

A co powiecie na taką implementację?

[PHP] pobierz, plaintext 
<?php
$i = new RecursiveIteratorIterator(new RecursiveDirectoryIterator(PHIEND_HANDLE_DIR));
$i = new KeyFilter($i, '.class.php$');
$w = new PhiendClassMapWriter('./handle_map.php');
$w->setTargetDir('e:/Web Files/lib/phiend2/phiend.handle', 'PHIEND_HANDLE_DIR');
 
$generator = new ClassMapGenerator();
$generator->addIterator($i);
$generator->setCreator(new BasicClassMapCreator());
$generator->addFilter(new SortClassMapFilter());
$generator->setWriter($w);
 
$generator->run();
?>
[PHP] pobierz, plaintext 

Wynik:

[PHP] pobierz, plaintext 
<?php
 
/*
 * File generated by phiend.autoload
 */
 
define('PHIEND_HANDLE_DIR', 'e:/Web Files/lib/phiend2/phiend.handle');
 
$aMap = array(
	'IHandle' => PHIEND_HANDLE_DIR . '/IHandle.class.php',
	'BasicHandle' => PHIEND_HANDLE_DIR . '/BasicHandle.class.php',
// (ciach)
	'SerializedHandle' => PHIEND_HANDLE_DIR . '/SerializedHandle.class.php',
);
 
Autoloader::addMap($aMap);
 
?>
[PHP] pobierz, plaintext 

Mogę tu zrobić praktycznie wszystko, dzięki dobremu rozbiciu na klasy i dziedziczeniu. W pełni wykorzystuje SPL - do tego stopnia, że moje php 5.0.3 jest za stare i musiałem wykomentować kilka linii .
Kod: http://cvs.sourceforge.net/viewcvs.py/phie...hiend.autoload/
Zip: http://phiend.sourceforge.net/misc/phiend-autoload.zip

[cagrET]

hawk: widzę, że używasz "notacji węgierskiej", ciekawi mnie czy może czytałeś ten artykuł: http://www.joelonsoftware.com/articles/Wrong.html > I’m Hungary . Joel pisze tam o tym, że w zły sposób używa się notacji węgierskiej, nie w taki jakim intencją autora tej notacji było.

[hawk]

Nie, nie czytałem do tej pory. Przedrostki określające typ stosuję tylko w php, bo tak jest mi wygodniej. W językach ze ścisłą typizacją są mi niepotrzebne.

[matid]

- przydatną funkcją byłoby parsowanie tagów phpdoc (jeżeli są), aby pomijać klasy "wewnętrzne", czyli takie, które wykorzystywane są tylko w obrębie danego pliku i nie ma potrzeby wystawiać ich na zewnątrz. Ja takich mini-klas używam, i brakuje mi możliwości zrobienia prywatnej klasy wewnętrznej jak w Javie...

Który znacznik phpDoc oznacza klasy wewnętrzne?
Edit: Ale ja jestem ślepy, że nie widziałem wcześniej tego pytania . Nie zmienia to faktu, że nie udzielono na nie odpowiedzi, więc dołączam się do grona pytających

BTW. Bardzo mi się twój kod podoba, szczególnie te wszechobecne interface i rozdrabnianie tego na wiele klas. Chyba trzeba przepisać mój Autoloader

Ten post edytował matid 13.06.2005, 21:10:21

[dr_bonzo]

cagrET: link do swietnego serwisu.

Z jakiegoś powodu większość ludzi zdaje się rodzić bez tej części mózgu, która jest potrzebna do rozumienia wskaźników

, LOL

hawk: do takiego OOP troche mi jeszcze brakuje

notacja wegierska: pamietam jak na poczatku '90 czytalem o tym w pc kurierze -- nawet mam wyrwane strony z tym artem

[hawk]

@dr_bonzo i matid:
Niestety, phpDocumentor nie ma, AFAIK, takiego znacznika. Szkoda. Chociaż nic nie stoi na przeszkodzie taki sobie stworzyć. Precedens jest - w Javie wiele narzędzi posiada swoje własne znaczniki javadoc. Może @no-autoload?

[matid]

@dr_bonzo i matid:
Niestety, phpDocumentor nie ma, AFAIK, takiego znacznika. Szkoda. Chociaż nic nie stoi na przeszkodzie taki sobie stworzyć. Precedens jest - w Javie wiele narzędzi posiada swoje własne znaczniki javadoc. Może @no-autoload?

Osobiście byłbym nie za wprowadzeniem znacznika mówiącego o wykluczeniu klasy z autoładowania (choć może to też by był dobry pomysł), lecz znacznika mówiącego o zasięgu klasy.
Czyli prędzej coś jak:
@range: file
@class-range: file
@classrange: file

Oprócz tego można by się pokusić o bardziej rozbudowany sysem autoloadingu, który np. pozwalałby na uwzględnienie takich czynników jak zakres folderowy (@range: directory), no i oczywiście @range: global, czyli to samo co w przypadku gdy pomijamy parametr zasięgu.

To takie moje 3 grosze.

BTW. Jak widzicie wykorzystanie takiego autoloadera w systemie? Czy korzystacie z niego dla całego kodu, czy tylko dla bibliotek? Bo dość niewygodne może być korzystanie z tego w modułach/akcjach. Bo akcja powinna być unikalna w obrębie modułu, ale może się pojawić w innych.

Ten post edytował matid 14.06.2005, 06:28:12

[hawk]

@matid: Pomysł wręcz genialny w swojej prostocie. Popieram. Jeżeli mamy wybrać najlepszą nazwę, to ja proponuję

Kod

@scope file

Scope, bo to bardziej odpowiednie słowo niż range. Bez dwukropka, bo chyba tagi phpdoc nie używają normalnie dwukropka? W każdym razie ja nigdy nie pisałem...

Co do zastosowania: generalnie używałbym na biblioteki. Albo na intensywnie wykorzystywaną część kodu - zawsze mogę wygenerować sobie mapę np. dla części Modelu. Natomiast dla akcji - nie warto, bo i tak w akcjach musi być porządek, wiadomo dobrze gdzie jaka akcja jest, i wykonujemy jedną akcję na raz. Szkoda mapę robić.

[matid]

No rzeczywiście, @scope będzie lepsze.
Spróbuję to jakoś zaimplementować, zobaczymy, co z tego wyjdzie

Bez dwukropka, bo chyba tagi phpdoc nie używają normalnie dwukropka? W każdym razie ja nigdy nie pisałem...

Literówka Miało być bez.

Ludzie rozwodzicie sie nad mapa, ktora mozna napisac nawet recznie. A wy tworzycie jakies skrypty bog wie po co i tworzycie nowa teorie do tego. Bezsensu. Zamiast napisac prosty skrypt do tworzenia mapy wy tworzycie 50 klas do wygenerowania tablicy 100 klas.

Ja osobiście wole mieć tablice generowane automatycznie. Nie dość że mogę sobie dowolnie zmieniać położenie klas to w dodatku skrypt przy następnym uruchomieniu sam uaktualnia mapę.

A co do podzielenia na 50 klas. Pierwsza wersja mojego skryptu do autoloadingu to była jedna klasa. Ale po przejrzeniu kodu @hawk widzę, ile jeszcze mojemu OOP brakuje. Dopiero podział tej klasy na kilka mniejszych pokazał mi, o ile większe możliwości w późniejszym rozszerzaniu daje OOP.

[hawk]

@serafin:

1) Nikt ci nie broni tworzyć takiej mapy ręcznie. Gratuluję odwagi. I nadmiaru wolnego czasu.

2) Bezsensu. Zamiast napisac prosty skrypt do wyświetlania stron wy tworzycie 50 klas, jakieś wzorce, MVC, biblioteki. Przecież każdy wie, że najlepiej jest wrzucić wszystko do jednego pliku, a całe to OOP to jedna wielka ściema.

Pokaż swój autoloader, a wtedy możemy porozmawiać, co jest lepsze, a co jest bez sensu.

[hawk]

Hawk: Wykorzystales 10 plikow na to co mozna zrobic w jednej klasie (i nie powiedziane ze gorzej).

No dobrze, porozmawiajmy wobec tego konkretnie. Na przykładach. Zaraz zobaczymy, czy rzeczywiście nie gorzej.

1. Chcę włączyć do mapy pliki z katalogów foo/first i foo/second, ale absolutnie nie z foo/third, bo tam są przykłady, które niepotrzebnie zaśmiecałyby mapę.

2. Chcę przeparsować tylko pliki o rozszerzeniu .class.php. Wszystko inne jest niepotrzebne.

3. Chcę, żeby w mojej mapie klasy były posortowane alfabetycznie. Dzięki temu mogę łatwo sprawdzić, jakie klasy są w moim pakiecie, a ponieważ jest to bez różnicy dla przetwarzania, nie ma żadnego powodu, żeby tego nie zrobić. No chyba że narzędzie jest gorsze...

4. Chcę wygenerować mapę dla zewnętrznego pakietu, który inaczej nazywa swoje klasy. Jak narzędzie, to uniwersalne, a nie ograniczone do mojego kodu, prawda? Pakiet jest w zupełnie innym miejscu na dysku.

5. Chcę w wersji produkcyjnej wrzucić kilka klas, które zawsze zawsze są używane, do jednego pliku, żeby przyspieszyć działanie i żeby prościej to wyglądało dla użytkownika końcowego. To częsta praktyka - weźmy np. mojavi.

6. Chcę za pomocą mojego autoloadera wygenerować mapę, która może być od razu wykorzystana w twoim systemie. Czyli plik wygląda tak samo. Chcę mieć uniwersalny autoloader, którego mogą używać inni, a nie nieprzenośne narzędzie.

7. Mam 2 mapy, do 2 różnych pakietów, i chcę obydwie naraz wbić do autoloadera.

Wierzę ci, że można to zrobić w jednej klasie. Która do tego będzie mniejsza niż suma tych plików i w ogóle lepsza. Tylko nie wiem, jak...

A co do tych 10 plików... rozmijasz się z prawdą . To są cztery pliki, plus trzy interfejsy (do niczego niepotrzebne, możesz je spokojnie wywalić, ale ja mam do interfejsów sentyment), plus trzy klasy dziedziczące z klas podstawowych (miałem kaprys zrobić coś extra, ale przecież w ogóle nie musisz ich wykorzystywać). Na podobnej zasadzie możemy zacząć liczyć unit testy i pliki readme.

---------------------------------------------

OOP ma sens owszem, ale nie w przypadku gdy tworzy sie klasy na 1-3 metod

Wiesz, co to jest Observer? Abstract Factory? Iterator? Registry? Intercepting Filter? Chain of Responsibility? Command? Strategy? Takie różne wzorce projektowe, ale niestety bez sensu, bo mają za mało metod.

Oczywiscie ze rozbijanie problemu na mniejsze czescie jest bardzo dobra technika ale sa pewne granice. Czasami mozna kilka z tych czesci polaczyc w jedna wieksza calosc bez szkody dla ostatecznego rozwiazania.

To ty zacząłeś tą dyskusję, więc odpowiedz: dlaczego rozbijanie problemu na mniejsze klasy jest szkodliwe? Bo z tego, co piszesz, wynika, że wg ciebie jest.

[matid]

Ma to sens?

A dlaczego nie? Mi osobiście bardzo się podoba sposób potraktowania typów zmiennych jako klas, a samych zmiennych jako obiektów.
Oprócz php programuję też w Javie i uważam to za świetne rozwiązanie, więc dlaczego by nie używać tego w php?

Teraz pewnie padnie pytanie, co mi da takie "utrudnianie" sobie życia. Ale zdecydowaną korzyścią płynącą z takiego rozwiązania jest możliwość programowania własnych typów danych, czego przy standardowym traktowaniu zmiennych przez php nie zrobisz.

Do notki poniżej: Skoro w php są typy podstawowe, to dlaczego miałoby nie być rozszerzonych? Nie będę nikogo nawracał rzucenia podstawowych typów w php na rzecz klas, bo dla niektórych to może być masochizm. Ja osobiście nie mam nic przeciwko
A co do pisania w php systemu operacyjnego. Wiem, że to było pytanie retoryczne, ale odpowiem - bo php się do tego kompletnie nie nadaje

A teraz wracając do autoloadera. Zaimplementowałem parsowanie tagów phpDoc, ale jeszcze borykam się z jedym problemem.
Powiedzmy, że moja mapa wygląda tak:

[PHP] pobierz, plaintext 
<?php
 
/*
* File generated by OpenForce Autoloader
*/
 
	$aMap = array(
		'GLOBAL' => array(
			'IteratorFilter' => '/var/www/matid/Current/Autoloader/lib/IteratorFilter.class.php',
			'iClassMapGenerator' => '/var/www/matid/Current/Autoloader/lib/autoloader/interfaces/ClassMapGenerator.interface.php',
			'iClassMapEntry' => '/var/www/matid/Current/Autoloader/lib/autoloader/interfaces/ClassMapEntry.interface.php',
			'iClassMapWriter' => '/var/www/matid/Current/Autoloader/lib/autoloader/interfaces/ClassMapWriter.interface.php',
			'iClassMapCreator' => '/var/www/matid/Current/Autoloader/lib/autoloader/interfaces/ClassMapCreator.interface.php',
			'ClassMapGenerator' => '/var/www/matid/Current/Autoloader/lib/autoloader/ClassMapGenerator.class.php',
			'OFClassMapWriter' => '/var/www/matid/Current/Autoloader/lib/autoloader/OFClassMapWriter.class.php',
			'ClassMapEntry' => '/var/www/matid/Current/Autoloader/lib/autoloader/ClassMapEntry.class.php',
			'ClassMapCreator' => '/var/www/matid/Current/Autoloader/lib/autoloader/ClassMapCreator.class.php',
			'ClassMapWriter' => '/var/www/matid/Current/Autoloader/lib/autoloader/ClassMapWriter.class.php',
			'ClassNotFoundException' => '/var/www/matid/Current/Autoloader/lib/exceptions/ClassNotFoundException.class.php',
			'Autoloader' => '/var/www/matid/Current/Autoloader/lib/Autoloader.class.php',
			'Test2' => '/var/www/matid/Current/Autoloader/test/1/2.php',
			'Test3' => '/var/www/matid/Current/Autoloader/test/3.php',
		),
		'/var/www/matid/Current/Autoloader/test/1' => array(
			'Test1' => '/var/www/matid/Current/Autoloader/test/1/1.php',
		),
	);
 
Autoloader::addMap( $aMap );
 
?>
[PHP] pobierz, plaintext 

Klasa Test1 ma ustawiony zasięg directory, reszta jest global. I teraz mam taką sytuację:

1. Jakaś klasa próbuje się odwołać do klasy Test1, ale nie znajduje się w tym samym folderze, autoloader rzuca ClassNotFoundException (a w zasadzie tworzy klasę Test1, której kostruktor rzuca wyjątek).
2. Jakaś inna klasa próbuje się odwołać do klasy Test1 i znajduje się w tym samym folderze, niestety, wcześniej została już utworzona klasa Test1, która domyślnie rzuca ClassNotFoundException.

Ma ktoś jakiś inny pomysł na implementację tego? Chyba jedynym wyjściem jest pozbycie się wyjątków z autoloadera, ale może ktoś wymyśli coś innego.

Ten post edytował matid 16.06.2005, 22:23:05

[bela]

Ma to sens?

A dlaczego nie? Mi osobiście bardzo się podoba sposób potraktowania typów zmiennych jako klas, a samych zmiennych jako obiektów.

To było takie pytanie retoryczne :] Nie ma to sensu. Po co opakowywać typy wbudowane jak i tak nic nie zyskasz, no może poza estetyką kodu

Oprócz php programuję też w Javie i uważam to za świetne rozwiązanie, więc dlaczego by nie używać tego w php?

W Javie też są typy podstawowe i jakoś nikt z tego powodu nie umarł :]
Btw. czemu nie piszesz w php systemu operacyjnego

Teraz pewnie padnie pytanie, co mi da takie "utrudnianie" sobie życia. Ale zdecydowaną korzyścią płynącą z takiego rozwiązania jest możliwość programowania własnych typów danych, czego przy standardowym traktowaniu zmiennych przez php nie zrobisz.

Emm a czy klasy nie są typami danych?

[Imperior]

Ma ktoś jakiś inny pomysł na implementację tego? Chyba jedynym wyjściem jest pozbycie się wyjątków z autoloadera, ale może ktoś wymyśli coś innego.

1. Olać tworzenie pustej klasy
2. Olać zasięgi
3. Każdą klasę tworzyć pośrednio

ad 3. Proxy... zamiast $obj = new Test1(); robić $obj = Class::New('Test1');
A metoda New z Class wszystkim sie zajmie (zwróci instancję, rzuci wyjątek itp)

[matid]

Chyba jednak skorzystam z opcji 1, ponieważ zasięgów nie chcę olewać, a tworzenie instancji przez proxy wyklucza takie przypadki jak dziedziczenie, implementowanie interfaców, itp.