Vytváření aplikačních systémů Unix-like metodou

gll

To sice ano, ale pro vlastní virtuální procesor se specifickými vlastnostmi si ten generátor musíš napsat sám. Říká se tomu třída :)

Nevím čemu říkáš virtuální procesor. Diskutovalo se tu o utilitách typu grep.

Kód: [Vybrat]
function grep ($in, $pattern) {
    foreach ($in as $line) {
        if(preg_match($pattern, $line)){
            yield $line;
        }
    }
}

k čemu by byla třída?


Franta <xkucf03/>

k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

gll

k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

v php se regulární výrazy AFAIK cachují. Stejný výraz se nezkompiluje dvakrát. Pro parametrizování se dá použít i uzávěr.

Kit

k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

v php se regulární výrazy AFAIK cachují. Stejný výraz se nezkompiluje dvakrát. Pro parametrizování se dá použít i uzávěr.

xkucf03 to vystihl. Pro jednoduché úkoly se dá využít i uzávěr, ale na ty složitější (s více metodami) je mnohem výhodnější si napsat třídu. Také je dobré udržovat nějakou kulturu projektu. Používat uzávěry na stejném levelu jako objekty se mi jeví jako hůře přehledné.

Proč bych měl používat uzávěr, když mohu použít plnohodnotný objekt, se kterým se lépe pracuje a mnohem snáze se rozšiřuje o další metody? V případě uzávěrů bývá problém i s pojmenováním - jedno slovo zpravidla nestačí. U objektů je to mnohem jednodušší: objekt.akce().

gll

k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

v php se regulární výrazy AFAIK cachují. Stejný výraz se nezkompiluje dvakrát. Pro parametrizování se dá použít i uzávěr.

xkucf03 to vystihl. Pro jednoduché úkoly se dá využít i uzávěr, ale na ty složitější (s více metodami) je mnohem výhodnější si napsat třídu. Také je dobré udržovat nějakou kulturu projektu. Používat uzávěry na stejném levelu jako objekty se mi jeví jako hůře přehledné.

Proč bych měl používat uzávěr, když mohu použít plnohodnotný objekt, se kterým se lépe pracuje a mnohem snáze se rozšiřuje o další metody? V případě uzávěrů bývá problém i s pojmenováním - jedno slovo zpravidla nestačí. U objektů je to mnohem jednodušší: objekt.akce().

Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).


Kit

Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

gll

Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

Ano. Je to jedna funkce s nějakými parametry.

Franta <xkucf03/>

Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

Ano. Je to jedna funkce s nějakými parametry.

Jenže to je dané tím, že to v shellu jinak nejde a nemáš si jak držet stav mezi jednotlivými voláními.
Např. když přes find a xargs budeš zmenšovat obrázky, tak musíš tu velikost předávat pořád dokola jako parametry.
Kdežto v objektovém programovacím jazyce by sis inicializoval objekt, který bude zodpovědný za to zmenšování, s těmi parametry a pak ho opakovaně používal.
V shellu se to řeší uložením konfigurace do souboru, když je těch parametrů moc nebo jsou složitěji strukturované. Pak voláš program s jedním parametrem, kterým je název toho konfiguráku. Pak se vlastně dá ten program (binárka) přirovnat ke třídě a ten konfigurák k její instanci (resp. konfigurák drží stav a společně s programem vytvoří proces a to je ta instance).

gll

Jenže to je dané tím, že to v shellu jinak nejde a nemáš si jak držet stav mezi jednotlivými voláními.
Např. když přes find a xargs budeš zmenšovat obrázky, tak musíš tu velikost předávat pořád dokola jako parametry.
Kdežto v objektovém programovacím jazyce by sis inicializoval objekt, který bude zodpovědný za to zmenšování, s těmi parametry a pak ho opakovaně používal.
V shellu se to řeší uložením konfigurace do souboru, když je těch parametrů moc nebo jsou složitěji strukturované. Pak voláš program s jedním parametrem, kterým je název toho konfiguráku. Pak se vlastně dá ten program (binárka) přirovnat ke třídě a ten konfigurák k její instanci (resp. konfigurák drží stav a společně s programem vytvoří proces a to je ta instance).

v shellu se dá použít alias.

v pythonu bych určitě použil functools.partial. V php asi uzávěr. Ušetří mi to psaní kvanta zbytečného kódu a zlepší to čitelnost.


Kit

v shellu se dá použít alias.

v pythonu bych určitě použil functools.partial. V php asi uzávěr. Ušetří mi to psaní kvanta zbytečného kódu a zlepší to čitelnost.

Pokud jsi přesvědčen, že ti v PHP uzávěry ušetří psaní kvanta zbytečného kódu, tak si je dělej. Pro mne jsou výhodnější objekty, protože toho umí víc a kód je hezčí.

BoneFlute

  • *****
  • 1 981
    • Zobrazit profil
Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

Ano. Je to jedna funkce s nějakými parametry.

Jenže to je dané tím, že to v shellu jinak nejde a nemáš si jak držet stav mezi jednotlivými voláními.
Např. když přes find a xargs budeš zmenšovat obrázky, tak musíš tu velikost předávat pořád dokola jako parametry.
Kdežto v objektovém programovacím jazyce by sis inicializoval objekt, který bude zodpovědný za to zmenšování, s těmi parametry a pak ho opakovaně používal.
V shellu se to řeší uložením konfigurace do souboru, když je těch parametrů moc nebo jsou složitěji strukturované. Pak voláš program s jedním parametrem, kterým je název toho konfiguráku. Pak se vlastně dá ten program (binárka) přirovnat ke třídě a ten konfigurák k její instanci (resp. konfigurák drží stav a společně s programem vytvoří proces a to je ta instance).
Už to tu zaznělo: curring.
Kód: [Vybrat]
function grep ($in, $pattern) {
    foreach ($in as $line) {
        if(preg_match($pattern, $line)){
            yield $line;
        }
    }
}
function curr_grep($pattern) {
    return function($in) use ($pattern) {
        return grep($in, $pattern);
    }
}
$curr_grep_a = spec_grep('a*');
$curr_grep_b = spec_grep('b*');

$spec_grep_a($obsah);

Je fakt, že na něco takového jsou třídy hack. A je fakt, že co se týče FP php zrovna nespolupracuje. Ne, že by to nešlo, ale je to děsně ukecaný.

Youda

Re:Vytváření aplikačních systémů Unix-like metodou
« Odpověď #71 kdy: 27. 02. 2017, 10:13:44 »
Heh, to je zase debata.

V kostce ten "UNIX pristup" znamena, ze aplikace je tvorena souhrnem komponent, ktera si predavaji data.
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text, navic je schopna predavat jenom mezi dvema komponentami a jenom jednim smerem.

To znamena, ze je potreba mit:
-message bus
-definovane data interchange API
-aspon primitivni BPEL na routovani dat
-nejaky toplevel framework co komponenty pospousti ve spravnem poradi a umozni jejich spravu
-a protoze se pise rok 2017 tak i nejaky centralni Deployment/DevOps v verzovanim komponent
-a protoze rok 2017 a legislativa EU, musi to byt sifrovane a zabezpecene, treba neco ve stylu PEP (Policy Enforcement Point), ke kterymu se komponenty hlasej, to aby byly schopne RBAC autorizace.

Ano, je samozrejme mozne si neco takoveho napsat sam, za par clovekolet to bude hotovo. Zvlast kdyz Apache Karaf je tak strasne nenazrany, spusteny prazdny Karaf bez naloadovanych bundlu a services si sezere 30MB RAM (priblizne uroven holeho Tomcatu), to je neunosne a na ZX Spectru to rozhodne nepojede.


Potom este stravit par clovekostaleti a vytvorit si svoji obdobu MavenCentral s tou obri sadou predpripravenych komponent a je hotovo.

Preju hodne stesti.
A pokud to prestane bavit, doporucuju vyplout na zapad z pristavu Palos de la Frontera, pry se da cestou na zapad doplout do Indie!


Re:Vytváření aplikačních systémů Unix-like metodou
« Odpověď #72 kdy: 28. 02. 2017, 00:12:09 »
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text
Fakt?

Tohle teda asi není unix roura:
Kód: [Vybrat]
cat /dev/sda1 | cat >/dev/sda2

Youda

Re:Vytváření aplikačních systémů Unix-like metodou
« Odpověď #73 kdy: 28. 02. 2017, 02:31:49 »
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text
Fakt?

Tohle teda asi není unix roura:
Kód: [Vybrat]
cat /dev/sda1 | cat >/dev/sda2

Ehm, vzhledem k tomu, ze je tu rec o komponentovych aplikacich, ktere si predavaji zpravy ve stylu zretezenych cat, grep, awk xargs, prijde mi tato poznamka ponekud zvlastni.
Ale budiz, Allah miluje rozmanitost.

Echt rootovy linuxak si muze postavit system na binarnich streamech, binarni nula bude message delimiter a nula bude dvojita nula.
Timto je puvidni tazateluv problem vyresen a vlakno se muze uzavrit. Transportnim protokolem bude WBSI (Whatever binary shit inside), jenom bych se primlouval za malyho indiana, mohla by teoreticky nastat situace, kdy soucasti deploymentu bude i netcal z intelu na sparc.

Re:Vytváření aplikačních systémů Unix-like metodou
« Odpověď #74 kdy: 28. 02. 2017, 08:42:04 »
Echt rootovy linuxak si muze postavit system na binarnich streamech, binarni nula bude message delimiter a nula bude dvojita nula.
Timto je puvidni tazateluv problem vyresen a vlakno se muze uzavrit. Transportnim protokolem bude WBSI (Whatever binary shit inside), jenom bych se primlouval za malyho indiana, mohla by teoreticky nastat situace, kdy soucasti deploymentu bude i netcal z intelu na sparc.
To uz udelal Microsoft s PowerShellem ;)