Rozwiązanie z generowaniem mapy przez skanowanie katalogów wydaje się najlepsze. Jednak sposób Vengeance'a nie jest zbyt efektywny. Wymaga wczytania zawartości każdego pliku z osobna i sprawdzania, czy zawiera on jakieś klasy. Może jest to bardziej elastyczne, gdy mamy po kilka klas w jednym pliku, ale ja to zrobiłem inaczej.

U mnie każda klasa jest w osobnym pliku. Nazwa pliku zawierającego definicję klasy lub interfejsu kończy się na .class.php lub interface.php. I tylko takie pliki są ładowany do mapy.

Wycinki kodu z mojego frameworka:

[PHP] pobierz, plaintext 
<?
  /**
   * Checks whether the specified path exists.
   * If the directory is not found, it'll try to create one.
   *
   * @param  string $dirname 
   * @return void
   */
  function ensure_directory_exists($dirname)
  {
	  $dirname = substr($dirname, strlen(APP_DIR));
 
	  $sub_dirs = explode('/', $dirname);
	  $path = '';
	  foreach ($sub_dirs as $dir)
	  {
		  $path .= $dir . '/';
		  if (!file_exists($path))
		  {
			  if (!@mkdir($path, 0777))
			  {
				  throw new DaeronException('Could not create a directory \"' . $path . '\"');
			  }   
		  }
	  }
  }  
 
  /**
   * Writes the supplied content to a file.
   *
   * @param  string $filename Name of a file to write to.
   * @param  mixed  $content  Data to write to a file.
   * @return void
   */  
  function file_write($filename, $content)
  {
	  ensure_directory_exists(dirname($filename));
	  $fp = @fopen($filename, 'w');
	  if($fp)
	  {
		  @fputs($fp, $content, strlen($content));
	  }
	  @fclose($fp);	  
  }  
 
  class Autoloader
  {
	  /**
	   * Map of class names and their localization. 
	   *
	   * @var array
	   * @static 
	   */
	  private static $map = null;
 
	  /**
	   * Loads specified class.
	   *
	   * @param  string $class_name
	   * @return void 
	   */	  
	  public static function load($class_name)
	  {
		  $cached_map = APP_DIR . '/var/cache/autoload.php';
		  if (!is_readable($cached_map))
		  {
			  self::generateMap();
		  }
 
		  if (!isset(self::$map)) require_once $cached_map;
 
		  $class_name = strtolower($class_name);
		  if (!isset(self::$map[$class_name]))
		  {
			  throw new Exception('Unknown class ' . $class_name);
		  }
 
		  require_once self::$map[$class_name];
	  }
 
	  /**
	   * 
	   * 
	   *	 
	   */
	  private static function generateMap()
	  {
		  self::$map = array();
 
		  $cached_map = APP_DIR . '/var/cache/autoload.php';
 
		  self::scan(DAERON_DIR);
		  self::scan(APP_DIR);
 
		  $compiled = &#092;"<?phpn\";
		  $compiled .= 'self::$map = ' . var_export(self::$map, true) . &#092;"n?>\";
 
		  file_write($cached_map, $compiled);		   
	  }	  
 
	  /**
	   * 
	   * 
	   *	 
	   */
	  private static function scan($dir)
	  {
		  $match = array();
		 
		  $rd = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($dir), true);
		  foreach ($rd as $file)
		  {
			  if(!is_file($file->getPathname())) continue;
 
			  if (preg_match('/([a-z0-9_]+).(class|interface).php$/i', $file->getPathName(), $match))
			  {
				  self::$map[strtolower($match[1])] = $file->getPathName();	
			  }
		  }		 
	  }
  }
   
  function __autoload($class_name)
  {
	  Autoloader::load($class_name);	
  }
?>
[PHP] pobierz, plaintext 

Porównanie szybkości (dla stosunkowo małej liczby plików):
- czytanie mapy z generowaniem: 35,67 ms
- czytanie z cache'owanej mapy: 00,57 ms

Kod Vengeance'a:
- czytanie mapy z generowaniem: 129.35 ms

A czytanie z cache wygląda identycznie

chmolu: Zauważ, że to Ty trzymasz każdą klasę w innym pliku!

A jak byś chciał dodać do frameworka np. AdoDB, Smarty czy inne rzeczy? One nie stosują twojego nazewnictwa.

Po to właśnie ten mój* skrypt przeszukuje wszystkie pliki wczytując je!

Skoro twoje nazewnictwo jest tak ustandaryzowane to w jakim celu w ogóle tworzyć mape ? przecież wystarczy zrobić

require $className . '.class.php'; hehe

* przypominam, iż nie czuje się właścicielem skryptu posklejałem kod z wielu wypowiedzi innych osób i wrzuciłem

@Vengeance: to prawda, nie każdy musi trzymać każdą klasę w innym pliku. Dla mnie takie rozwiązanie jest najwygodniejsze.


Autoloader u mnie ma służyć tylko do ładowania klas należących do jądra i aplikacji. Biblioteki typu Smarty i AdoDB zaliczam do "zewnętrznych" części aplikacji, którymi zająć musi się odpowiednia akcja/widok. Poza tym zauważ, że w przypadku tych bibliotek musimy włączyć tylko jeden główny plik, który już sam zajmuje się potrzebnymi mu plikami.
(btw: główny plik Smarty ma nazwę Smarty.class.php, więc pasuje do mojego nazewnictwa )


Ale dzięki mapie struktura katalogów jest dowolna. Mogę sobie w dowolny sposób podzielić na różne katalogi i podkatalogi, a gdy zajdzie potrzeba zmiany struktury wystarczy tylko wygenerowac mapę i nie trzeba grzebać w kodzie i poprawiać wszystkich ścieżek.

@chmolu a jak zmienisz ścieżke do smarty ?

Nie używam Smarty więc nie ma żadnego problemu

// btw: poprawiłem troszkę ten kod

@chmolu: ty nie. Ale z tego co wynika z twoich wypowiedzi to co piszesz
to framework. Pewnie kiedys ktos inny z niego bedzie korzystac i moze chciec takze korzystac ze smarty

Zapewniam cię, że nie będzie to żaden problem
Ale mam nadzieję, że zamiast Smarty ludzie będą używali systemu wbudowanego w mój framework (wzorowany na WACT/ASP/JSP).
Jak skończę, to zarzucę tu kod do oceny.

Pozwole sobie odkopać temat

Zastanawiam się czy nie użyć pliku xml ładowania klas. Coś na wzór:

[XML] pobierz, plaintext 
<Classes>
 
<dirname>
<class name='jakas tam nazwa'>file.php</class>
<class name='jakas tam nazwa2'>file2.php</class>
</dirname>
 
<dirname2>
<class name='jakas tam nazwa3'>file3.php</class>
<class name='jakas tam nazwa4'>file3.php</class>
</dirname2>
 
</Classes>
[XML] pobierz, plaintext 

Potem bardzo prosto: simplexml, loader instacji (w moim przypadku) i tyle

Iść dalej tym tropem, czy zacząć myśleć nad czymś innym ?

Tylko właściwie... po co XML do zwykłego przypisania nazwy pliku do nazwy klasy? IMO jest to lekkie komplikowanie sobie całej sprawy - no chyba, że chcemy przechowywać jakieś dodatkowe informacje.

Mnie osobiście podoba się pomysł z iteratorem, szukającym klas po wszystkich plikach o określonym wzorcu, w podanej ścieżce (ścieżkach). Można z tego zrobić ładną tablicę, zserializować ją i do pliku... Co prawda trzeba się troszkę pobawić samym pisaniem tego generatora mapy, ale za to później, przy zmianie położenia/nazw plików zaoszczędzi się duużo czasu.

Ja to widzę tak:
1. Crowler, szuka po określonych folderach w poszukiwaniu plików php zawierających klasy. Będzie miał możliwość wyszukiwania z filtrowaniem nazw plików, nazwach klas itp. Być może po dodaniu opcji filtracji czas generowania mapy się zwiększy nieco, ale na jakoże jest to czynność wykonywana rzadko, można sobie na to pozwolić.
2. Dodatkowy plik XML z klasami zewnętrznymi. W tym pliku będą zapisane w postaci XML dodatkowe klasy, które autoloader ma obsługiwać. Plik byłby parsowany i razem z wynikami crowlera zapisywany w pliku php w postaci tablicy.

O to mi chodziło

Śpieszyłem się i zapomaniałem dopisać.

IMO pliki XML w tym wypadku są niepotrzebne. Szybciej i wygodniej będzie to zrobić przy pomocy plików ini

XML to przeładowanie, a nam zależy na czasie, nie? Chociaż wszystko da się zrobić ;P

Przecież parsowanie pliku XML będzie się odbywać tylko w wypadku rekonstruowania mapy, co za często się dziać nie powinno, czyż nie? Zyskujemy natomiast na przejrzystości i strukturze pliku konfiguracyjnego.

@matid -> zauwazylem u Ciebie duze przywiazanie do technologi xml. Wiesz mnie sie zawsze wydawalo, ze ten jezyk zostal powolany do zycia po to, aby zapewnic przenosnosc danych pomiedzy roznymi platformami. Nie wiem czy w tym przypadku zapewnienie tej cechy jest pozadane. Uwazam ze próbujesz robic cos na sile utrudniajac sobie zywot.

@matid -> ale tą mapę musisz za każdym uruchomnienie skryptu załadować i to będzie się dziać często...

Przecież nie chodzi mi o trzymanie mapy w XMLu, bo jest to totalną pomyłką. Nie jestem aż tak przywiązany do XMLa żeby tracić na wydajności. Chodzi mi o trzymanie w pliku XML dodatkowych ścieżek do przeszukiwania, czyli parsowane będzie to tylko przy regenerowaniu mapy.

Czyli trzymasz tylko katalogi do parsowania? To nie ma sensu, ponieważ powinno się parsować wszystkie katalogi i uzyskać pełną mapę klas.

Przemyślałem sposób z XML i stwierdziłem, ze pomysł jest chybiony. Tak czy inaczej trzeba za każdym razem parsowac plik, traci się na tym cenny czas... A gdy tych dodatkowych ścieżek jest dużo ? wtedy czas wydłuża się do sek, a nie tysiącznych sekund.

Nie wiem jak sobie wyobrażasz wygenerowanie mapy w tysięczne sekund. W średniej wielkości projekcie (jeszcze bez czytania dodatkowych ścieżek, ok. 90 klas w różnych plikach) trwa to ok. 0,4 s. Czytanie z mapy to ok 0.0008s. Więc nie wiem jakbyś chciał kombinować, ale IMO niemożliwym jest generowanie mapy w tysięczne sekundy. Oczywiście mówię tutaj o mapie nie wymuszającej żadnego przystosowania nazwy pliku itp.

" trwa to ok. 0,4 s"

lol :] Mój kod (a ogolnie ten co podałem powyżej gdzieś), który rekurencyjnie schodzi katalogami w dół i zapisuje znalezione klasy już teraz wykonuje się czasem więcej niż 20 sekund :]
Oczywiście robione jest to tylko raz, przy pierwszym uruchomieniu.

Moja klasa autoloadera jest w znaczej części oparta na wypowiedziach i nawet fragmentach kodów z tego tematu, więc nie zdziwiłbym się, gdyby funkcja skanująca foldery (lub jej założenia) była już przez ciebie cytowana.

Prędkości w dostępie do plików mogą wynikać z różnego systemu operacyjnego (ja testuję lokalnie na linuksie, który ma świetny system buforowania dysków), procesora, pamięci, obciążenia, itp.
U mnie przeskanowanie ok 100 plików (ok. 1 MB) i stworzenie mapy zawierającej 90 klas trwa ok. 0,4s.

Oprócz tego mam napisany bardzo fajny system automatycznego regenerowania mapy, cachowania wyników, itp.

Czepiasz się szczegółów, liczba była podana dla przykładu.

To nie było czepianie. Chodziło mi o sposób w jaki @matid osiągnął tak dobry jak dla mnie wynik. U mnie już powoli php robi time out przy generowaniu :] (WinXP, 950 MHz, 256mb RAM)

Dla zainteresowanych - moja klasa Autoloader: http://matid.emmatrade.pl/files/Autoloader.class.phps

I jeszcze raz moje testy:
Sprzęt: Pentium 4 2,4 GHz, 1024 MB RAM, dysk twardy 7200 RPM (system plików: ReiserFS)
System: Ubuntu Linux 5.04 Hoary Hedgehog

Dane testowe:
Rozmiar: 913.6 KB
Liczba plików: 120
Liczba klas: 90

Czas generowania mapy po raz pierwszy po włączeniu komputera: 0.872271060944s
Czas generowania mapy po raz kolejny (część plików mogła być w buforze dysków): 0.427920103073

Skoro temat zrobił się popularny i każdy chce mieć swój autoloader oparty o mapy (co uważam za słuszne), to warto załatwić jedną prostą rzecz. Kompatybilność. Taka mapa to na tyle prosta struktura, że pewnie wszędzie wygląda tak samo:

[PHP] pobierz, plaintext 
<?php
$map=array(
  'nazwaklasy' => 'ścieżkadoklasy',
);
?>
[PHP] pobierz, plaintext 

Wtedy każdy może sobie generować mapę jak mu się podoba, szybciej lub wolniej. I każdą mapę można wrzucić do każdego autoloadera. Dobrze myślę?

Kompatybilność jest akurat bardzo ważna w przypadku autoloadera. Bo jeżeli napiszę jakąś bibliotekę, to wykorzystam swój pomysł. I ta biblioteka musi działać z biblioteką autorstwa kogoś innego, kto też oparł ją o swój autoloader. A autoloader może działać tylko jeden, więc jeżeli jeden do drugiego nie pasuje, to całość wychodzi do dupy.

@hawk -> Amen

...mam i ja.

Stworzylem swojego autoloadera:
- w konfigu podaje katalogi do rekursywnego przejrzenia
- podaje rozszerzenia plikow ktore maja byc tokenizowane

- mapa jest tworzona w std. formacie: nazwa_klasy => sciezka_do_pliku
- i zapisywana w formacie .ini (moze dorobie wybor ini | php)

I co najwazniejsze -- cachuje wyniki tokenizowania plikow (to nie to samo co 'mapa') -- tokenizowane sa tylko te co zostaly zmodyfikowane (okreslane przez filemtime()), co daje znaczna oszczednosc czasu. Zapisuje tablice:

[PHP] pobierz, plaintext 
<?php
 
array (
[ 'nazwa_pliku' ] ->
(
    [ 'classes' ] ->
    (
        [ 0 ] -> 'klasa_1';
        [ 1] - > itd...
    )
    [ 'modification_time' ] = 111123423423423; // czas modyfikacji
    { ['valid' ] = TRUE }
)
)
?>
[PHP] pobierz, plaintext 

Jak to wyglada w praktyce:
- wczytuje ww. cache
- przegladam katalogi i robie liste znajdujacych sie tam plikow
- loop po tych wszystkich plikach: porownuje czas modyfikacji pliku z czasem zapisanym w cache
- jesli plik zostal zmieniony to go tokenizuje i aktualizuje cache (+ ustawienie znacznika 'valid' w cache)
- jesli nie zostal zmodyfikowany to tylko ustawienie znacznika 'valid' w cache
- po przejrzeniu wszystkich plikow, usuwam te wpisy w cache, ktore nie maja znacznika 'valid', i usuwam znacznik 'valid' z tych, ktore go maja (tylko po to zeby go (znacznika) nie zapisac w cache)
- uzyskuje tablice z wpisami
nazwa_pliku --> klasy/interfejsy w min sie znajdujace + czas modyfikacji pliku
- zapisuje to cache
- na podstawie tego cache tworze mape

Wlasciwosci
- nowe pliki ktorych nie bylo w cache sa tokenizowane i dodawane do cache i mapy
- pliki ktore byly w cache a teraz nie istnieja (nie ma ich w podanych w configu katalogach) sa usuwane z cache i mapy
- pliki ktore byly w cache i nie zostaly zmienione nie sa tokenizowane (duuuza oszczednosc czasowa)
- pliki ktore byly w cache i zostaly zmodyfikowane sa ponowanie tokenizowane -> aktualizacja cache

Czasy wykonania:
6 klas / 5 plikow:
0.1137sec // bez cache
0.0041 sec // z cache

dodanie dodatkowych plikow i klas, w sumie
355 plikow / 138 klas
4.3358 sec // bez cache
0.1672 z cache// z cache

modyfikacja 3 z tych plikow (glowne pliki Smartyego -- 161kB) i utworznie mapy, z cache
0.7571 sec




Kodu jest sporo: > 470 linii, jak dokoncze to dam linka.
Pozostaje jeszcze fopisac __autoload()'a.

Z twojego opisu wynika mi, że za każdym uruchomieniem klasy następuje rekurencyjne przejrzenie katalogów. Jeśli tak jest, to jest to tragiczne rozwiązanie :]

Po co te wszystkie "czasy edycji plikow" itp. Na co ci oszczednosc czasowa przy generowaniu mapy, skoro zalozeniem glownym jest ze robisz to tylko raz! Ewentualnie potem gdy cos zmieniasz w strukturze ponawiasz proces generowania.

Twoje "Jak to wyglada w praktyce" wg mnie powinno ograniczac sie tylko do:
1. przejrzenie rekurencyjne wskazanych katalogów
2. tokenizacja każdego pliku celem wyłapania zawartych w nim klas
3. zapisanie wszystkich powiązań klasa=>plik do .ini czy tam .php

A sam główny skrypt powinien tylko ów .ini lub .php wczytywać, zaś gdy go nie ma powinien uruchamiać generowanie ów pliku :]

Taka moja wersja

Jesli mapa istnieje to ten skrypt nie jest uruchamiany.



Przy rozbudowie aplikacji i sprawdzaniu poprawnosci jej dzialania nie bedzie mi sie chcialo czekac tych 5 czy 20 sekund na zobaczenie rezultatow.

"W praktyce" to robi + robi to szybciej jesli moze.

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.

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

php szybsze od INI

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

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

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...

[DONE] Jest w TODO


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


[DONE] Zgadza sie. Poprawie


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

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

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.

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.

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

cagrET: link do swietnego serwisu.
, 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

@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.

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

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ć.

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

Literówka Miało być bez.

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.

@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.

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.

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

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.


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.

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.

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


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


Emm a czy klasy nie są typami danych?

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)

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.