PHP preprocessor |
Tematy na forum Pro mogą zakładać jedynie moderatorzy. W otwartych tematach może pisać każdy, kto ma coś fachowego do powiedzenia. Wszystkie posty nie wnoszące nic do tematu będą natychmiast usuwane, a ich autorzy dostaną ostrzeżenie.
Jeśli uważasz, że jakiś temat jest warty dyskusji na tym forum, zgłoś go w temacie Propozycje.
PHP preprocessor |
20.04.2004, 16:13:11
Post
#1
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) |
Chodzi mi po głowie taki "preprocesor" albo "kompilator" do php. Hmm, wyobraźcie sobie że macie jakiś obiektowy systemik - powiedzmy kilkanaście klas, w tym interfejsy (PHP5). I chciałoby się wypuszczając oficjalną wersję tego systemiku wrzucić to wszystko do jednego pliku, bo i tak te klasy się nazwajem potrzebują. A interfejsy w ogóle nie są potrzebne - tylko ułatwiają pisanie - i można je całkowicie usunąć.
I uruchamiałoby się taki preprocesor, który mergowałby pliki, usuwał (niepotrzebne już) instrukcje require_once(...) itd. Sprawa nie jest prosta, bo preprocesorowi trzeba jakoś powiedzieć, co ma do czego przerzucić, a co zostawić w spokoju. No i nie może on absolutnie pogubić się i wprowadzać do kodu nowe błędy. Czy takie coś może istnieje? Czy to jest w ogóle dobry pomysł? |
|
|
20.04.2004, 17:09:16
Post
#2
|
|
Grupa: Przyjaciele php.pl Postów: 790 Pomógł: 7 Dołączył: 6.02.2003 Skąd: Polska Ostrzeżenie: (0%) |
IMHO pomysł ciekawy, ale nieopłacalny. Załóżmy, że system składa się z kilkudziesięciu klas, ale przecież nie zawsze wszystkie są potrzebne, czasami nie musisz używać wszystkich klas, a parser to przetwarza (niestety) i tracisz potrzebne sekundy....
-------------------- Michał Płachta
Warsztat: Mac OS X Leopard, PostgreSQL, Text Mate, Retrospectiva + SVN |
|
|
20.04.2004, 18:37:26
Post
#3
|
|
Grupa: Zarejestrowani Postów: 66 Pomógł: 0 Dołączył: 22.04.2003 Skąd: Żory / K-ce Ostrzeżenie: (0%) |
Właśnie dlatego ten prekompilator musiałby być konfigurowalny tj. mieć jakiś plik wejściowy z listą klas i na podstawie tych klas załadować wybrane pliki, oczyścić z komentarzy, zbędnych instrukcji wg. gdzieś w ustawieniach wprowadzonych regexów, a następnie scalić generując docelowy plik .php biblioteki. Ale jest też druga strona medalu - w plikach, które używały dotychczas klas includując pojedyncze pliki także należałoby pozmieniać wywołania, albo w jakiś sposób powiązać nazwę klasy z nazwą biblioteki, ale to wymaga ingerowania w __autoload bądź wyprowadzenia dodatkowego obiektu do ładowania klas.
-------------------- Gadu-Gadu: 3909164
|
|
|
20.04.2004, 18:37:41
Post
#4
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) |
Hmm, ja zakładam że:
1) preprocesor odpalam sobie tylko raz, u siebie, zanim wypuszczę na zewnątrz gotową wersję (a wersja z wieloma plikami mogłaby nazywać się "debug") 2) wiem które klasy są potrzebne zawsze a które od czasu do czasu, i łączę ze sobą tylko te, które i tak będą musiały być zawsze wczytywane To powoduje, że trzeba jakoś poinformować parser, co wolno mu mergować |
|
|
20.04.2004, 20:12:31
Post
#5
|
|
Grupa: Zarejestrowani Postów: 66 Pomógł: 0 Dołączył: 22.04.2003 Skąd: Żory / K-ce Ostrzeżenie: (0%) |
No jakoś trzeba. Ja wykorzystuję swój generator kodu wbudowany we framework, który odczytuje pliczek XML-owy ze "składnikami" i robi na jego podstawie gotowy "posiłek" dla interpretera w postaci pliczku php. Zmiana przepisu pociąga za sobą rekompilację. Użytkownik dostaje samo menu - klasy w osobnych plikach, ale przy pierwszym odpaleniu zostanie zrobiony cache.
U mnie pliczek źródłowy wygląda tak:
Procesor wyciąga klasy po regexach. Bardzo proste, a spełnia swoje zadanie. -------------------- Gadu-Gadu: 3909164
|
|
|
20.04.2004, 20:17:31
Post
#6
|
|
Grupa: Zarejestrowani Postów: 66 Pomógł: 0 Dołączył: 22.04.2003 Skąd: Żory / K-ce Ostrzeżenie: (0%) |
serafin - to zarzuć może nazwą...
Argument co do czasu wykonywania jest chybiony. Operacja przecież będzie wykonywana tylko przy zmianach projektu. -------------------- Gadu-Gadu: 3909164
|
|
|
20.04.2004, 21:31:22
Post
#7
|
|
Grupa: Przyjaciele php.pl Postów: 195 Pomógł: 0 Dołączył: 7.07.2003 Skąd: Warszawa Ostrzeżenie: (0%) |
Hawk: jej! :DDDDD Wiem, ze to niewiarygodne, ale myslalem swego czasu o czyms identycznym. Dokladnie o "kompilacji"/"kompresji".
Zalety? Liczne. 1) Mieszacz kodu. Uzyskujemy efekt zblizony do kompilacji i uwierzcie - wlasciwie niemozliwy do rozkodowania (przy uzyciu rozsadnych srodkow) 2) Zmniejszenie includow - jak wszyscy wiemy include i require to wlasciwie najwezsze gardla kazdej aplikacji 3) usuniecie komentarzy w wersji "produkcyjnej", a jak wiemy, dobrze udokumentowany plik potrafi zawierac wiecej komentarzy niz kodu Ja za, ale moze po Tothu -------------------- "(...)Zrozumienie wymagaloby od Ciebie odrobiny pokory. A dzis, w dobie
obalania autorytetu i udowadniania, ze doswiadczenie jest niepotrzebnym balastem, to jest niemodne.(...)" |
|
|
20.04.2004, 21:56:53
Post
#8
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) |
Taki preprocesor może bardzo dużo zrobić minimalnym kosztem, naprawdę...
1) Wycinanie komentarzy - zero regexpów, wbudowany tokenizer, idzie jak burza 2) wycinanie białych spacji - w PHP5 jest do tego jedna funkcja itd... @Nalfein: czy twój generator kodu potrafi wyciąć niepotrzebne już require_once i inne takie? Bo generalnie to co napisałeś to mniej więcej to o co mi chodzi - podaje się w jakimś pliku, jakie pliki ma sparsować, i wypluwa jeden scalony plik. Ja bym jeszcze bardzo chciał wywalić z pliku "produkcyjnego" interfejsy, bo prawie zawsze nie są one potrzebne do poprawnej interpretacji (chyba że ktoś używa instanceof, ale ja zamiast tego zawsze class type hints w definicji metody, i tutaj można je wyciąć). @serafin: A da sie to zrobić jakimś preprocesorem C? awkiem? nie wiem... Takie coś musiałoby rozumieć chociaż trochę kod php. |
|
|
21.04.2004, 14:22:22
Post
#9
|
|
Grupa: Zarejestrowani Postów: 80 Pomógł: 0 Dołączył: -- Ostrzeżenie: (0%) |
To ja jeszcze wtrace swoje dwa grosze - nie wiem czy znacie moze taka aplikacje jak POBS http://pobs.mywalhalla.net/. Najprostsza rzecza jaka robi to wlasnie usuwanie bialych znakow, lecz zmienia ona takze nazwy zmiennych, funkcji itd na nieczytelne. Jest to dosyc skomplikowane zadanie, autorzy sami pisza ze po zastosowaniu skryptu trzeba naniesc kilka zmian czy poprawek. Napisanie takiego pre-processora byloby dosyc trudne i trzebaby przewidziec mnostwo sytuacji - jesli jednak udaloby Ci sie cos takiego napisac, mysle ze byloby to bardzo przydatne narzedzie.
|
|
|
21.04.2004, 16:24:34
Post
#10
|
|
Grupa: Przyjaciele php.pl Postów: 195 Pomógł: 0 Dołączył: 7.07.2003 Skąd: Warszawa Ostrzeżenie: (0%) |
Cytat Byc moze nie zrozumialem troche idei... Jesli ma to wygladac w ten sposob, ze wg listy plik scala je w calosc to jest to chybiony pomysl. Czemu ? Skad "preprocessor" bedzie wiedzial ze includujac plik akcji ma go pominac (bo jest przeciez zmieniany dynamicznie) czy tez tworzyc bedzie xxxx scalonych plikow dla kazdej z akcji ? Myslicie ze taki "inteligentny" parser da sie napisac ?
Tak. Zauwaz, ze o ile faktycznie czesc rzeczy musi pozostac jako "moduly" to czesc moze zostac wlaczona. W mnoim przekonaniu, dobry programista piszac obiektowa aplikacje zazwyczaj tworzy po jednym pliku na kazda klase. Jesli zatem jadro sklada sie z 10 klas (baza danych, uprawnienia, szablony, cache, costam) i kilku plikow glownych (index.php, main_lib.php) - do tego kilku klas prymitywnych, abstrakcyjnych i kilku interfejsow to w wersji produkcyjnej mozna by to zlaczyc w jeden plik, oszczedzajac kilkunasty include/require (i na dodatek wywalajac interfejsy/klasy abstrakcyjne). Oczywiscie pewnei trzeba by jakos zaznaczyc "twarde" includy, ktore maja zostac includami, ale mysle, ze na koncu zamiast 100 plikow mozna by miec plik index.php (jadro) i kilka-kilkanascie modulow ladowanych w zaleznosci od potrzeb. -------------------- "(...)Zrozumienie wymagaloby od Ciebie odrobiny pokory. A dzis, w dobie
obalania autorytetu i udowadniania, ze doswiadczenie jest niepotrzebnym balastem, to jest niemodne.(...)" |
|
|
21.04.2004, 17:50:17
Post
#11
|
|
Grupa: Przyjaciele php.pl Postów: 195 Pomógł: 0 Dołączył: 7.07.2003 Skąd: Warszawa Ostrzeżenie: (0%) |
No, pisalem przeciez:
"Oczywiscie pewnei trzeba by jakos zaznaczyc "twarde" includy, ktore maja zostac includami" -------------------- "(...)Zrozumienie wymagaloby od Ciebie odrobiny pokory. A dzis, w dobie
obalania autorytetu i udowadniania, ze doswiadczenie jest niepotrzebnym balastem, to jest niemodne.(...)" |
|
|
21.04.2004, 19:22:01
Post
#12
|
|
Grupa: Zarejestrowani Postów: 66 Pomógł: 0 Dołączył: 22.04.2003 Skąd: Żory / K-ce Ostrzeżenie: (0%) |
hawk: nie, na odwrót. Zamiast usuwać require_once wycina klasy o podanych identyfikatorach z plików źródłowych i umieszcza w wynikowym. Jeśli tamte klasy potrzebują innych to należy je dołączyć manualnie w pliku konfiguracyjnym.
-------------------- Gadu-Gadu: 3909164
|
|
|
21.04.2004, 19:32:52
Post
#13
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) |
Cytat To ja jeszcze wtrace swoje dwa grosze - nie wiem czy znacie moze taka aplikacje jak POBS http://pobs.mywalhalla.net/. Najprostsza rzecza jaka robi to wlasnie usuwanie bialych znakow, lecz zmienia ona takze nazwy zmiennych, funkcji itd na nieczytelne.
POBS jest ciekawą aplikacją, i nie znałem wcześniej :wink: . Ale tak na oko widać, że ma on poważne wady, spowodowane nie brakiem umiejętności twórcy, tylko tym, że POBS powstał, gdy php nie dysponował funkcjonalnością znakomicie ułatwiającą tego typu zadania. Przykłady, wzięte ze strony programu: - POBS ma drobne problemy z wycinaniem komentarzy, a tokenizer czyni to dziecinnie prostym - POBS myli czasami nazwy stałych z tagami HTML, a tokenizer nie ma z tym problemu - POBS ma duże trudności ze zmiennymi typu $$nazwa, a za pomocą tokenizera można je łatwo rozpoznać - POBS, wycinając spacje, potrafi popsuć kod HTML, a PHP5 (jak zakładam) zrobi to dobrze O obsuscatorze nie myślałem, ale może kiedyś... |
|
|
21.04.2004, 19:57:09
Post
#14
|
|
Grupa: Zarejestrowani Postów: 127 Pomógł: 0 Dołączył: 19.11.2003 Skąd: Poznań Ostrzeżenie: (0%) |
Dyskusja przybrała taką formę, że mogę śmiało stwierdzić że pewne postawione tu wymagania spełnia MMCache: kompiluje plik tekstowy php do bytecodu a podczas tego procesu kod jest oczyszczany. Jedynie nie parsuje include-ów.
Update: Oczywiście wymaga ingerencji w apache'a -------------------- Enceladus
Warsztat: bez warsztatu Aktua |
|
|
21.04.2004, 23:07:46
Post
#15
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) |
@Nalfein:
Aaaaaa, sprytne . Chociaż wtedy jest pewne ryzyko, że "zgubi się" jakieś define(...) i takie, umieszczone poza klasą. Ale w PHP5, mając nowe słowo kluczowe const, stosuję raczej zasadę "jeden plik = jednak klasa i nic poza klasą". @enceladus: MMCache też robi z tego tyle plików, ile było na początku. Chociaż nie znam zasad działania na tyle dobrze, aby stwierdzić, czy weźmie pliki z bytecodem z dysku, czy będzie je trzymał w pamięci. Ciekawe, jaka dla MMCache jest różnica pomiędzy 10 plikami, a 1 plikiem powstałym ze sklejenia tamtych. W sensie szybkości, oczywiście. |
|
|
10.07.2004, 20:48:52
Post
#16
|
|
Grupa: Zarejestrowani Postów: 15 Pomógł: 0 Dołączył: 25.11.2003 Skąd: Białe Błota Ostrzeżenie: (0%) |
Wydaje mi sie, ze lepie byloy taki preprocesor wykorzystac do wydawania release aplikacji. powiedzmy wersja release i debug. wypuszczajac wersje release, preprocesor: obcina komentarze, dalej usuwa wszystko np. pomeidzy #ifdef DEBUG / #endif. Powiedzmy w tym bloku bylyby jakies dodatkowe logi itd potrzebne programiscie a nie w koncowym produkcie.
-------------------- Piotr Usewicz
http://www.layer22.com |
|
|
10.07.2004, 21:05:38
Post
#17
|
|
Grupa: Przyjaciele php.pl Postów: 1 467 Pomógł: 13 Dołączył: 22.02.2003 Ostrzeżenie: (0%) |
a może coś jak w C? Można by było nawet # zostawić jako rozpoznawacz komend preprocesora
Kod <?php i potem tylko#ifdef VERSJA_FINALNA #include "klasa.class.php" #else require_once "klasa.interfejs.php"; require_once "klasa.class.php"; #endif // VERSJA_FINALNA ?> $ convert --in plik.php --out finalna.php -D VERSJA_FINALNA Albo napisać język do opisu różnych akcji. Coś np. jak Kod outfile $klasa "finalna/$1.class.php" Albo coś w tym stylu i potem tylko interpreter.from "klasa.class.php" import * without [includes('*.interface.*')] to $klasa('klasa') Drugi sposób ma tą wadę, że trzeba by było napisać jeszcze conajmniej podstawowy parser php. |
|
|
28.03.2005, 02:45:39
Post
#18
|
|
Administrator PHPedia.pl Grupa: Developerzy Postów: 1 102 Pomógł: 2 Dołączył: 14.09.2003 Ostrzeżenie: (0%) |
Stary topic, ale co tam, nie będę nowego zakładać :]
Co sądzicie o czymś takim ? :]
Konfiguracja poprzez tablice $files -------------------- |
|
|
29.03.2005, 15:20:10
Post
#19
|
|
Grupa: Zarejestrowani Postów: 521 Pomógł: 0 Dołączył: 3.11.2003 Skąd: 3city Ostrzeżenie: (0%) |
Fajny przykład, i dobrze pasuje do dyskutowanego ostatnio autoloadera . Ja bym z tego oczywiście zrobił klasę. I zrobiłbym system pluginów do tej klasy, pobierających tekst pliku i zwracających przetworzony tekst pliku. Np. plugin usuwający komentarze, wycinający whitespace, itd. I takie pluginy można łączyć w łańcuszek - co po kolei ma być zrobione.
Albo inny pomysł - łańcuch przetwarzania powinien mieć postać: input -> processing -> output. Tzn. niech będzie interfejs odpowiedzialny za dostarczanie contentu - np. pobierając z pliku, pobierając z listy plików, itd. Drugi interfejs/klasa to główne przetwarzanie i obróbka zagregowanego contentu. A na koniec interfejs zapisujący wynik obróbki. Taki pipeline pozwala na elastyczne dopasowywanie do potrzeb i dopisywanie nowej funkcjonalności. Najlepiej byłoby opracować coś takiego i wydać razem z autoloaderem... edit: Coraz bardziej podoba mi się pipeline. Można nawet pójść trochę w stronę Cocoona: zrobić sobie drzewko przetwarzania, gdzie na wejściu (liść) jest input, na wyjściu (korzeń) output, a w środku cokolwiek - agregacja, filtrowanie, wycinanie komentarzy, itd. |
|
|
10.04.2005, 01:01:57
Post
#20
|
|
Administrator PHPedia.pl Grupa: Developerzy Postów: 1 102 Pomógł: 2 Dołączył: 14.09.2003 Ostrzeżenie: (0%) |
Cytat(hawk @ 2005-03-29 15:20:10) Fajny przykład, i dobrze pasuje do dyskutowanego ostatnio autoloadera . Ja bym z tego oczywiście zrobił klasę. I zrobiłbym system pluginów do tej klasy, pobierających tekst pliku i zwracających przetworzony tekst pliku. Np. plugin usuwający komentarze, wycinający whitespace, itd. I takie pluginy można łączyć w łańcuszek - co po kolei ma być zrobione. No ba, już jest gotowe
Cytat Albo inny pomysł - łańcuch przetwarzania powinien mieć postać: input -> processing -> output. Tzn. niech będzie interfejs odpowiedzialny za dostarczanie contentu - np. pobierając z pliku, pobierając z listy plików, itd. Drugi interfejs/klasa to główne przetwarzanie i obróbka zagregowanego contentu. A na koniec interfejs zapisujący wynik obróbki. Taki pipeline pozwala na elastyczne dopasowywanie do potrzeb i dopisywanie nowej funkcjonalności. Najlepiej byłoby opracować coś takiego i wydać razem z autoloaderem... edit: Coraz bardziej podoba mi się pipeline. Można nawet pójść trochę w stronę Cocoona: zrobić sobie drzewko przetwarzania, gdzie na wejściu (liść) jest input, na wyjściu (korzeń) output, a w środku cokolwiek - agregacja, filtrowanie, wycinanie komentarzy, itd. Możesz bardziej łopatologicznie napisać ;] -------------------- |
|
|
Wersja Lo-Fi | Aktualny czas: 27.09.2024 - 08:13 |