Vlákno názorů k článku Jazyk Shine: „lepší“ Lua s novými jazykovými konstrukcemi a vylepšeními od Čavo - Keby si chcel niekto shine skompilovať a nemá...
-
Keby si chcel niekto shine skompilovať a nemá konto na github-e (alebo ho len nemá vložené do git-u), tak asi bude lepšie použiť.
git clone https://github.com/richardhundt/shine.git
Inak sa dopracujete k niečomu takémuto:
> git clone git@github.com:richardhundt/shine.git Cloning into 'shine'... The authenticity of host 'github.com (140.82.121.4)' can't be established. ED25519 key fingerprint is SHA256:+DiY3wvvV6TuJJhbpZisF/zLDA0zPMSvHdkr4UvCOqU. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'github.com' (ED25519) to the list of known hosts. git@github.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Ale prečo som to chcel si skompilovať. Nepozdávala sa mi veta v 13. kapitole: „Programovací jazyk Shine má v tomto případě odlišnou sémantiku, protože proměnná a naplněná uvnitř funkce test bude globální:“.
Tak som si to preveril a naozaj to vypísalo tú chybu. Dobre, chce mať definovanú premennú v globálnom priestore. Tak som urobil dva pokusy a tu to začina byť zábavné.
Pripísal som vytvorenie globálnej premennej.
a = 5 function test() a = 10 end test() print(a)Výsledok bol „10“.
Tak som skúsil ju zadefinovať pred volaním funkcie:
function test() a = 10 end a = 5 test() print(a)Výsledok je „5“.
Bŕŕŕ. To hádam nie.
Po tejto skúsenosti neviem, či sa mi chce skúmať tento jazyk hlbšie. Mozno mi niekto vysvetlí, prečo sa to takto správa.
-
Pavel TišnovskýZlatý podporovatelv článku má být "nebude globální", už jsem to opravil.
Chování je skutečně na první pohled divné; v podstatě je tam rozdíl mezi lexical a dynamical scope. Když se nepoužije "local", tak se využije dynamical scope, jako v některých Lispech, Bashi a tuším R-ku. Tedy důležitá je viditelnost v runtime, ne v čase načítání skriptu (nebo compile time).
-
Mám chuť sa zahrať na diablovho advokáta. Tiež ich nepreferujem, ale takéto absolútne tvrdenia sú mi proti srsti.
Napríklad také singletony, kde musí byť jedna inštancia, neviem, ako ináč sa dajú ošetriť.
(Viem si predstaviť niečo ako že sa môžu sa pridať kadejaké anotácie, že "toto bude funkcia, ktorá bude vracať jednu premennú", closure nejak oanotovaná, aby sa dala inštancovať len raz. Ale bude to de facto globálna premenná. Prosím zátvorku nediskutovať, je to moja špekulácia)
Ďalej prosím velectenú redakciu root o schválenie príspevku, skvelí ste, klaniam sa pred vami. Toto je námet na diskusiu, nie trollbait.
2. 4. 2024, 12:03 editováno autorem komentáře
-
Pavel TišnovskýZlatý podporovatel
Tak v closure anotace byt nemusi, muze to fakt mit lokalni promennou a tu porad vracet jako singleton.
Ale mozna to neni napsano presne. Pristup ke globalnim promennym z jinyho kontextu neni vubec idealni. A to si porad myslim, ze je hodne spatne. Uz jen ty obezlicky pri testovani...
2. 4. 2024, 12:38 editováno autorem komentáře
-
Pavel TišnovskýZlatý podporovatel
asi chápu. Funkce, tedy čisté funkce, nemají instance, je to jen mapování. Uzávěry můžeme chápat jako objekty s více instancemi (třeba ten Counter), ale snadno to jde upravit do singletonu - prostě pokud už je vnitřní čítač ne-nilový, tak se vrátí funkce next, jinak se nejprve čítač vynuluje (a opět se vrátí funkce next).
Tím, že do toho čítače nikdo zvenku nevidí, ho taky nemůže měnit, takže se to nemusí řešit (u objektů jo, pokud někdo vidí atributy).
(v Pythonu pro to jde napsat dekorátor, v Lue ne:)
2. 4. 2024, 14:04 editováno autorem komentáře
-
Právě že případy, kdy by globální proměnné nebyly zlo se hledají dost těžko. Prakticky jediný, o kterém vím, je optimalizace u microchipů. A tam se obávám, že to bude spíše mojí neznalostí.
Návrhový vzor Singleton je příkladem ne neideálním, ale vysloveně do nohy si střílícím. Protože zkušenosti s tímto vzorem ukazují, že to vůbec není dobrý nápad.
8. 4. 2024, 19:53 editováno autorem komentáře
-
globální proměnné ponechejme stranou a zůstaňme u singletonu
"Protože zkušenosti s tímto vzorem ukazují, že to vůbec není dobrý nápad"
to není moc argument. Jaké zkušenosti? Výhoda singletonu je, že pokud o něj není zájem, tak se vůbec nevytvoří. Například error handling. Když ti nevznikne při běhu chyba, není důvod vytvářet error handling instanci. Jak bys to řešil bez singletonu?
-
Nevýhody Singletonu jsou shodné s nevýhodami globální proměnné. Plus přináší další nevýhody: Jakmile je singleton inicializován, nemůžeš ho změnit. Nedá se to testovat. Je neflexibilní/nadbytečný.
Singleton nemá žádné výhody, které by nebylo možné udělat jínak.
Toliko tvrzení.
Tvůj příklad s error handlingem: Pokud tvé zadání chápu dobře, tak ty nepopisuješ potřebu jedinečnosti, nýbrž lazy, což je jiný návrhový vzor.
A abych to doplnil, v kódu v mnoha případech potřebuju právě tu jedinečnost, a mohu toho dosáhnout aniž bych vytvářel singleton. Většina DIC má pro to specielní příznak.
Každopádně, hele, tlačme to dál. Zkus jestli tě napadne nějaký jiný příklad, kdyby byl Singleton vhodný. Rád se nechám poučit.
-
Proč bych ho chtěl měnit? Já od něj chci aby byl stále jeden a ten samý. Co znamená že je neflexibilní? Jo a co je vlastně DIC? Tady i internet mlčí. Jinak singleton definovali hoši z Gang of four a je definován s možností lazy loadingu. Na jejich knihu "Design Patterns: Elements of Reusable Object-Oriented Software" jsem šetřil z brigád strašně dlouho a do teď ji mám v knihovně.
Můžu zkusit i pár příkladů u kterých si myslím, že výhody singletonu převažují problémy. Ale tak trochu z tebe cítím takovou tu juniorní aroganci. Ono to je důležité, mladí vpřed. Já tomu říkám syndrom vlkodlaka před prvním úplňkem. Tak se právě chci zeptat jestli se zkusíš držet věci a vynechat nadřazený tón typu "hele tlačme to dál atp"?
-
probudil jsi ve mně zájem. Samozřejmě nemusíš odpovídat, ale nemáš čistě náhodou odkaz na svůj linkedin? Ponechejme teď poměřování mezi sebou. Opravdu mě upřímně zajímá profil člověka, který má názor, že v knize Design Patterns od GoF je všechno špatně. Vždyť na těch principech stojí celé OOP. opět, vynechejme kontroverzní Singleton, ale říct že takový Command, Factory, Iterator, Memento a další jsou špatně bez vysvětlení proč!? Jak říkám, rád bych se podíval na profil člověka s takovýmto názorem. Jen za sebe - programuji 30let, 18let na plný úvazek. Aktuálně na pozici architecta a tech directora a ano, neustálě je čemu se učit a pořád toho víc nevím, než vím, ale řekněme že i já jako hlupák jsem za ty roky něco pochytil od chytřejších kolegů. Ale tvé názory, navíc nikterak nepodložené věcnými argumenty mi přijdou zvláštní.
-
Napsal jsi že praxí zjistím že v GoF je všechno špatně. Tak bych se rád zaměřil na tohle. GoF je označení pro 4 jména. Tak už tady nevím co znamená že v GoF je všechno špatně. Singleton je kontroverzní, k němu se můžeme dostat. Přimhouřím oči a odsouhlasím že také iterátor resp jeho implementace v c++ není ideální. Ale co je špatného na Factory, Observeru atp? To už nedovedu. Tak jak píšu, tady bych začal. Můžeme? Když nechceš sdílet profesní zkušenosti, chápu. Ale třeba public github že bych koukl. Cokoliv co by mi pomohlo pochopit proč říkáš o designových patternech a tedy o SW inženýrství obecně že "všechno špatně"
ČLÁNKY DO MAILU