PHP preprocessor Opcje

[hawk]

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ł?

[seaquest]

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

[Nalfein][WR]

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.

[hawk]

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ć

[Nalfein][WR]

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:

[XML] pobierz, plaintext 
<?codegen use="php-cache"?>
<cache>
  <part>
        <source path="./core/Object.php" />
      <class>Object</class>
  </part>
  <part>
      <source path="./core/Worker.php" />
      <class>Worker</class>
  </part>
  <part>
        <source path="./core/Component.php" />
      <class>Component</class>
  </part> 
  <part>
        <source path="./util/List.php" />
      <class>List</class>
  </part> 
  <part>
        <source path="./util/Map.php" />
      <class>Map</class>
  </part> 
  <part>
        <source path="./application/Application.php" />
      <class>Application</class>
  </part> 
  <part>
      <source path="./application/CustomApplication.php" />
      <class>CustomApplication</class>
  </part>
  <part>
        <source path="./application/PaladineFramework.php" />
      <class>PaladineFramework</class>
  </part> 
</cache>
[XML] pobierz, plaintext 

Procesor wyciąga klasy po regexach. Bardzo proste, a spełnia swoje zadanie.

[Nalfein][WR]

serafin - to zarzuć może nazwą...

Argument co do czasu wykonywania jest chybiony. Operacja przecież będzie wykonywana tylko przy zmianach projektu.

[e-Gandalf]

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

[hawk]

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.

[wojtek]

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.

[e-Gandalf]

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.

[e-Gandalf]

No, pisalem przeciez:

"Oczywiscie pewnei trzeba by jakos zaznaczyc "twarde" includy, ktore maja zostac includami"

[Nalfein][WR]

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.

[hawk]

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

[enceladus]

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

[hawk]

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

[LoPMX]

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.

[Jabol]

a może coś jak w C? Można by było nawet # zostawić jako rozpoznawacz komend preprocesora

Kod

<?php
#ifdef VERSJA_FINALNA
#include "klasa.class.php"
#else
require_once "klasa.interfejs.php";
require_once "klasa.class.php";
#endif // VERSJA_FINALNA
?>

i potem tylko
$ 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"
from "klasa.class.php" import * without [includes('*.interface.*')] to $klasa('klasa')

Albo coś w tym stylu i potem tylko interpreter.

Drugi sposób ma tą wadę, że trzeba by było napisać jeszcze conajmniej podstawowy parser php.

[bela]

Stary topic, ale co tam, nie będę nowego zakładać :]

Co sądzicie o czymś takim ? :]

[PHP] pobierz, plaintext 
<?php
function dump($dump) {
	print('<pre>');
	var_dump($dump);
	print('</pre>');
}
 
$files = array(
	   'dirs' => array(''),
	   'disabled_dirs' => array(''),
	   'files' => array(''),
	   'disabled_files' => array(''),
);
//dump($files);
 
function getFiles($dir) {
	$aFiles = array();
	foreach($dir as $d) {
	$rd = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( $d ), true );
		foreach ($rd as $file) {
			if(!$file->isDir() && end(explode('.', $file)) == &#092;"php\") {
				$aFiles[] = $file->getPathname();
			}
		}
	}
	return $aFiles;
}
 
$rf = array_diff(getFiles($files['dirs']), getFiles($files['disabled_dirs']));
$rf = array_merge($rf, $files['files']);
$rf = array_merge(array_diff($rf, $files['disabled_files']));
//dump($rf);
 
$bigFile = null;
foreach($rf as $file) {
	$buff = php_strip_whitespace($file);
//	highlight_string($buff);
	$buff = preg_replace( array('/^(<?php|<?)/', '/?>$/'), array('', ''), $buff);
	//dump($buff);
	$bigFile .= $buff;
 
}
$bigFile = '<?php '. $bigFile . ' ?>';
//highlight_string($bigFile);
file_put_contents('merged.php', $bigFile);
?>
[PHP] pobierz, plaintext 

Konfiguracja poprzez tablice $files

[hawk]

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.

[bela]

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

[PHP] pobierz, plaintext 
<?php
error_reporting(E_ALL);
class PreProcessor {
	private $plugins;
	private $config;
	private $fileContent;
	private $files;
	public function __construct() {
	}
 
	public function start () {
		$this->files = $this->getF($this->config);
		$this->loadFiles();
		$this->processPlugins();
	}
 
	private function getFiles($dir) {
		$aFiles = array();
		foreach($dir as $d) {
		$rd = new RecursiveIteratorIterator( new RecursiveDirectoryIterator( $d ), true );
			foreach ($rd as $file) {
				if(!$file->isDir() && end(explode('.', $file)) == &#092;"php\") {
					$aFiles[] = $file->getPathname();
				}
			}
		}
		return $aFiles;
	}
 
	public function setConfig($aConfig) {
		$this->config = $aConfig;
	}
 
	public function getConfig () {
		return $this->config;
	}
 
	public function setPlugins($aPlugins) {
		$this->plugins = $aPlugins;
	}
 
	public function getPlugins () {
		return $this->plugins;
	}
 
	private function getF($aF) {
		$rf = array_diff($this->getFiles($this->config['dirs']), $this->getFiles($this->config['disabled_dirs']));
		$rf = array_merge($rf, $this->config['files']);
		$rf = array_merge(array_diff($rf, $this->config['disabled_files']));
		return $rf;
	}
 
	private function processPlugins() {
		foreach($this->plugins as $k => $v) {
			$plugin = new $v;
			$this->fileContent = $plugin->process($this->fileContent);
		}
	}
 
	private function loadFiles() {
		foreach($this->files as $k => $v) {
			$this->fileContent[$v] = file_get_contents($v);
		}
	}
 
	private function getFileContent() {
		return $this->fileContent;
	}
 
	public function setFileContent($content) {
		$this->fileContent = $content;
	}
 
	public function save($dir = null) {
		foreach($this->fileContent as $k => $v) {
			file_put_contents($dir . $k, $v);
		}
	}
}
 
class comments {
	function __construct() {
	}
 
	function process($files) {
		foreach($files as $k => $v) {
			$files[$k] = php_strip_whitespace($k);
		}
		return $files;
	}
}
 
function dump($dump) {
	print('<pre>');
	var_dump($dump);
	print('</pre>');
}
 
$files = array(
	   'dirs' => array(''),
	   'disabled_dirs' => array(''),
	   'files' => array(''),
	   'disabled_files' => array(''),
);
 
$pre = new PreProcessor();
$pre->setConfig($files);
$pre->setPlugins(array('comments'));
$pre->start();
$pre->save('new/');
print 'Hehe, udalo sie preprocesorawac kod;)';
?>
[PHP] pobierz, plaintext 

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ć ;]

[bela]

Cytując manual

file_get_contents() is the preferred way to read the contents of a file into a string. It will use memory mapping techniques if supported by your OS to enhance performance.

;]

[Nievinny]

Ok, to jeszcze zakodować to przez Zend SafeGuard (chyba jakoś tak?) to zupełnie będzie nieczytelne..., nie ma jakiejś funkcji usuwającej tylko komentarze?

[bela]

php_strip_whitespace" title="Zobacz w manualu PHP" target="_manual ?

[edit]
Co do requirów to jest to 'trochę' skomplikowane ;]

No bo tak możemy użyć 4 funkcji do załączenia pliku, ale to najmniejszy problem.
Większy problem jest z czymś takim

[PHP] pobierz, plaintext 
<?php
$abc = 'path/to/file.php';
require_once($abc);
 
//albo 
require_once(PATH . './../file.php'); //;]
?>
[PHP] pobierz, plaintext 

Macie jakieś sensowne pomysły jak to rozwiązać ?:]

[Nievinny]

Bela -> tylko komentarze bez spacji, czyli wcięcia by pozostały...
I jeszcze mała wada, gdy podaję cały skrypt ze struktórą katalogową to jak wiadomo nie może zapisać plików w podkatalogach bo nie istnieją, a więc trzeba dorobić tworzenie katalogów odpowiednich (bo nie każy będzie kożystał ze zwalczania requirów) ;]

#---- EDIT ----#
Co do require to może token_get_all()" title="Zobacz w manualu PHP" target="_manual i T_REQUIRE, T_REQUIRE_ONCE i ewentualnie te z include?
Lum można szukać przeszukując ciąg za pomocą wyrażeń regularnych i pobierać to co pomiędzy require( 'czyli to' )?

Ten post edytował Nievinny 10.04.2005, 14:02:58

[bela]

Pocięcie do tokenów raczej nie załatwi sprawy, bo to analiza leksykalna a nie składniowa :] Byłoby trzeba napisać jakiś 'mini' analizator, który podmieniałby zmienne etc ;]

---
[edit]
nowa wersja ;]
http://openpb.net/work/dev/bela_666/phppl/preprocessor/

[hawk]

@bela_666: łopatologicznie, hmmm... sam mam mgliste pojęcie. Wyobrażam sobie taki łańcuszek, gdzie można dowolnie przestawiać elementy. Na początku jest coś, co produkuje treść (np. czyta z pliku), na końcu coś, co konsumuje treść (np. zapisuje). Jakoś to skonfigurować, utworzyć łańcuch i niech pracuje.

Taki system może również np. czytać plik XML, robić na nim XSLT do kodu php i wiele innych rzeczy. Najważniejsze jest odseparowanie funkcjonalności związanej z czytaniem plików - dzięki temu można wziąć tą treść z innego miejsca.

Co do require, sprawa jest faktycznie bardzo skomplikowana. Zwłaszcza że niektóre require nie mają z góry określonej ścieżki. Jest ona ustalana w trakcie wykonania. Wg mnie, analiza tego jest z góry skazana na niepowodzenie i tak naprawdę niepotrzebna . Przecież mamy wspaniały autoloader, który jest właśnie po to, aby nie trzeba było pisać ani jednego require. W wątku o autoloaderze pisałem, że jego główną zaletą jest wywalenie tych require, co pozwala dowolnie łączyć, dzielić i przesuwać pliki z kodem. Jedno idzie w parze z drugim.

[bela]

@bela_666: łopatologicznie, hmmm... sam mam mgliste pojęcie. Wyobrażam sobie taki łańcuszek, gdzie można dowolnie przestawiać elementy. Na początku jest coś, co produkuje treść (np. czyta z pliku), na końcu coś, co konsumuje treść (np. zapisuje). Jakoś to skonfigurować, utworzyć łańcuch i niech pracuje.

Taki system może również np. czytać plik XML, robić na nim XSLT do kodu php i wiele innych rzeczy. Najważniejsze jest odseparowanie funkcjonalności związanej z czytaniem plików - dzięki temu można wziąć tą treść z innego miejsca.

No to to rozumiem, i w ostatnim kodzie wzorowałem się na Cocoonie ( generatory, transformatory etc ;] ). Ale o co chodzi z tym drzewem i liscmi :]

[hawk]

OK, przykład takiego drzewa:

Kod

a.xml -> a.php _
                 \_ ab.php
          b.php _/

Plik a.xml transformujemy (XSLT) do a.php, po czym sklejamy z b.php, wycinając np. whitespace, i zapisujemy ab.php.

Tego nie zrobisz twoim systemem, bo pluginy działają na wszystkich plikach i nie można wykonać transformacji XSLT tylko na jednej gałęzi.

[NuLL]

Czy może mi się tylko wydaje czypoprsotu trzeba napisać podklasę liścia i nałożyć filtr czy jakieś transformatory na kazdy z osobna, lub ew. na wszystkie ?

Patrząc dalej - zmalować jakiś XML-owy konfig, że poinstruował PreProccesor co ma robić z danym liściem i jak zachoać się w danej sytuacji ?

[Vengeance]

A czy mi się tylko wydaje, czy to wszystko jest poroniony pomysł

O ile samo "złączenie wszystko w jedno" to jeszcze zalicze do dobrych niekiedy spraw, to w takim "udziwnianiu" już nei widze sensu :]

ps. moje zdanie, nie krzyczcie ;P

[NuLL]

Mimo iż dopisałem swoją wizję tego czegoś - to jest to dla mnie też zupełnie zbędne...

Vee - do własnego zdania ma prawo każdy

[hawk]

No dobra, jakiś bardziej praktyczny przykład takiego skomplikowanego preprocesora .

Generowanie map dla autoloadera. Załóżmy, że chcemy wygenerować mapę, w skład której będą wchodzić pliki z kilku różnych katalogów. Nie chcemy mieć w niej niepotrzebnych plików. Oczywiście, można zrobić to na wiele różnych sposobów, ale jednym z nich jest właśnie system, który może pobierać dane (pliki) z różnych katalogów, zbierać razem i przesyłać dalej do przetwarzania.

Albo inaczej: chcę scalić 5 plików z kodem i 1 plik php z jakimiś danymi konfiguracyjnymi. Z całego kodu należy wyciąć komentarze i whitespace. Z danych konfiguracyjnych nie, i do tego mają znaleźć się na początku pliku, żeby po jego otworzeniu można było coś z tego wyczytać. Znowu, można zrobić to inaczej, można machnąć ręką, ale zastosowania są.

Gdyby tylko dało się to jakoś prosto składać w sensowny pipeline...

[Sedziwoj]

Ktoś pisze interpreter PHP więc wiele można

A co do samego pomysłu to mi też taki do głowy wpadł, tylko że czytając ten tekst doszedłem że to nie takie proste. A dokładnie to myślałem nad usuwaniem 'zbędnych' rzeczy, czyli odstępy, wcięcia, łamanie linii itp. oraz komentarzy. Co nie było by może zbyt trudne, jednak już przynosi pewne problemy.

Co do łączenia plików, to już jest problem, bo powstaje nam istny graf, w tym część gałęzi można poznać dopiero w czasie wykonywania... (mówię o ładowaniu w czasie wykonywania odpowiednich plików)

Ale skoro interpreter to zjada, to dlaczego my byśmy nie mogli tego zrobić

[Zeman]

Ja się dołączę do rozmowy.

Jak robiłem pluginy do mojego edytora mające za zadanie przerabianie plików PHP podczas kładzenia ich na serwer, nasunął się pewien "problem" o którym nie pomyślałem wcześniej, a mianowicie:

Plik php na serwerze ma inną postać niż edytowany w edytorze, a to powoduje błędne raportowanie o błędach, tzn standardowy komunikat "Parse error: syntax error, unexpected ',' in c:\usr\apache\httpd\html\zeman_serw\web2biz\index.php5 on line 3" nam może nic nie powiedzieć dgyż linia 3 na serwerze to już nie linia 3 w edytorze.

Oczywiście można z tym sobie poradzić, ale chciałem zwrócić uwagę, że takie coś będzie występować.

[Sedziwoj]

Chyba raczej taki błąd się nie pojawi, ale na pewno będzie się rozchodziła numeracja.
To jest pewien problem, choć nie do końca, bo 'parse error' powinno być przed 'kompilacją' wyłapane, a późniejsze błędy, przy dobrej obsłudze będą niewiele gorzej lokalizowane (przy obiektowym programowaniu)

[cicik]

Przyznam się, że mi taki pomysł też po głowie chodzi jednak w dużo bardziej rozbudowanej wersji.
Marzy mi się narzędzie, które po pierwsze zrobi to co proponujecie czyli poskleja odpowiednie pliki razem, wytnie białe znaki etc. ale również zrobi dokumentację kodu na podstawie komentarzy.
Coś jak PHPDocumentor tylko dużo szybsze i z kilkoma nowymi tagami - brakuje mi np. tagów do określania jakie wyjątki rzuca dana funkcja i kiedy. I generalnie chciałbym aby generowało to dokumentację na kształt MSDN w Visual Studio bo ona tam ejst naprawdę dobrze zrobiona.
Co więcej takie narzędzie musiałoby być napisane w jakimś C++ lub C# żeby działało szybciej.
Do tego można by jeszcze dorobić narzędzie do generacji klas do testów jednostkowych i narzędzie, które testuje pokrycie kodu testami (poprzez dołączenie do każdego ifa i pętli odpowiednich funkcji do sprawdzania czy coś się wywołało czy nie).

Generalnie potrzebne do tego wszystkiego byłoby napisanie jakiegoś porządnego parsera składni PHP aby można było plik z kodem zmienić na graf obiektów w danym języku. Ale o tym większego pojęcia jeszcze nie mam. Póki co napisałem tylko w C# profilera interpretującego plik wypluwany przez APD. Aczkolwiek marzy mi się właśnie napisanie całego takiego pakietu z narzędziami "około phpowymi".

Temat dość zaawansowany, pewnie na niejedną magisterkę ale gdyby to dobrze zrobić to nawet pewnie by się to sprzedać dało.

Pozdrawiam

Ten post edytował cicik 12.04.2007, 21:19:54

[akubiczek]

Skoro temat wyskoczył do góry, to dodam jeszcze odnośnie preprocesora, że przecież można wykorzystać nieśmiertelny cpp (c preprocesor) - który ma spore możliwości, a nie trzeba wynajdować koła od nowa

[g00fy]

widzialem i korzystalem z takiego programu , tylko ze on wszystko zamienial na EXE ;]