Byly publikovány informace o kritické zranitelnosti v knihovně pro Rust async-tar a jejích forcích tokio-tar, krata-tokio-tar a astral-tokio-tar. Jedná se o zranitelnost CVE-2025-62518 s CVSS 8.1. Nálezci je pojmenovali TARmageddon.
AlmaLinux přinese s verzí 10.1 podporu btrfs. XFS bude stále jako výchozí filesystém, ale instalátor nabídne i btrfs. Více informací naleznete v oficiálním oznámení.
Společnost OpenAI představila svůj vlastní webový prohlížeč ChatGPT Atlas. Zatím je k dispozici pouze na macOS.
Desktopové prostředí KDE Plasma bylo vydáno ve verzi 6.5 (Mastodon). Přehled novinek i s videi a se snímky obrazovek v oficiálním oznámení. Podrobný přehled v seznamu změn.
Rodina jednodeskových počítačů Orange Pi se rozrostla (𝕏) o Orange Pi 6 Plus.
Na Humble Bundle běží akce Humble Tech Book Bundle: All Things Raspberry Pi by Raspberry Pi Press. Se slevou lze koupit elektronické knihy od nakladatelství Raspberry Pi Press a podpořit Raspberry Pi Press, Raspberry Pi Foundation North America nebo Humble.
Přidaný režim autonomního řízení vozidel Tesla Mad Max je dostupný pro vybrané zákazníky v programu EAP (Early Access Program). Nový režim je na silnici agresivnější, častěji mění pruhy a ne vždy dodržuje rychlostní limity. Agentura JPP spekuluje, že v Česku by se mohl nový režim namísto Mad Max jmenovat Mad Turek...
Byla vydána nová verze 9.18 z Debianu vycházející linuxové distribuce DietPi pro (nejenom) jednodeskové počítače. Nově také pro NanoPi R3S, R3S LTS, R76S a M5. Přehled novinek v poznámkách k vydání.
bat, tj. vylepšený cat se zvýrazňováním syntaxe a integrací s gitem, byl vydán ve verzi 0.26.0.
Byla vydána první verze 0.0.1 [Mastodon] multipatformního renderovacího jádra webového prohlížeče Servo (Wikipedie). Vývoj Serva započal v roce 2012 v Mozilla Corporation. V roce 2020 bylo Servo předáno nadaci Linux Foundation. Servo je napsané v programovacím jazyce Rust.
$dbConnection = new $dbType; $dbConnection->query('...'); $dbConnection->close();Například.
bude dedit a pretezovat bazovou tridu kdyz stejne budete celou dobu pouzivat pouze jednoho potomka ktereho si zvolite v configu podle databaze na dostupne na serveru?Samozrejme, ze ano. A budes snad ty opakovat stejny kod vicekrat i kdyz by bylo mozne ho napsat dostatecne abstraktne a jednou a psat samostatne jen kod, ktery opravdu samostatny musi byt? Odkazu te na zaklady OOP znova -- tentokrat aby sis nastudoval jaky je vyznam rozhrani. Signatura a kontrakt rozhrani rikaji programatorovi, co ma naprogramovat aby jeho pojeti dane komponenty dobre pracovalo s existujicim systemem. Konektory na ruzne databaze jsou idealnim prikladem, databazi je mnoho a je tu realna pravdepodobnost, ze fanousek nejake jine DB bude chtit na ni PunBB provozovat. A jake ma moznosti za soucasneho stavu? Studovat jak trotl existujici nijak nesladene implementace tech jejich layeru misto aby naprogramoval svuj layer proti existujicimu rozhrani a prip. vyuzil z nejake abstraktni tridy kod, ktery muze byt univerzalni (v oblasti podpory ruznych DB by se neco takoveho urcite naslo). Navic bude muset krome psani noveho layeru upravovat i onen CASE. Kdyby to bylo vyreseno pres nejaky typ reflexe (v PHP se AFAIK da instancovat trida podle jmena v retezci, da se tak myslim i odkazovat na promennou), nebyl by CASE vubec potreba.
Predstav si ze budes psat multiplatformni tridu File, pokus by si zbrkle pouzil OOP napr takto: FileBase bude bazova trida(nebo rozhrani jestli chcete) a z te bude dedit trida FileWindows ktera bude specializovana na windows, dale FileUnix pro Unix atd.. bude se pri kazdem volani metody zbytecne testovat zda neni objekt potomkem a zda nema metodu pretizenou, zbytecne protoze za cely zbytek zivota programu od kompilace se nidky nepouzije jina specializaceJa nechapu, co mas porad s tim pretezovanim a testovanim (nehlede na to, ze nejspis myslis prekryti metody jinou implementaci v potomkovi a ne pretizeni -- pridani stejne pojmenovane metody s jinou signaturou v ramci jedne tridy). Nebude se testovat vubec nic. Na kazde platforme se podle konfigurace instancuje jina trida a na to zadne testovani neni potreba (minimalne u PHP a Javy muzu z fleku rict, ze instancovat tridu i volat na ni metody lze ze stringu, takze neni potreba jediny IF nebo CASE). A na te tride se pak budou volat metody definovane rozhranim. A kazda si to udela po svem, to me jako "klientovi" tech trid je uplne jedno, kdyz mi vrati co chci. Delal jsem Java app, ktera mela nacitat nekolik druhu bitmap a nezavisle na typu bitmapy na ni provadet serii operaci. Kod, ktery zajistoval vyber spravne tridy pro bitmapu neobsahoval jediny podminkovy konstrukt a vzdy se vybrala ta spravna trida, vsechny dedici z AbstractBitmap. Nedokazu si predstavit to peklo kdybych pak mel operace nad abstraktnim polem obrazovych dat psat v kazde tride zvlast. Vzdyt je to prasarna! Jiste, muzes si na to vytvorit nejakou sadu nevazanych funkci a tem ta data predhodit -- ale to IMHO bije do oci, "drbani se levou rukou za pravym uchem". Problem s tvym pohledem je ale jeste uplne jinde a uz jsem to nakousl vyse, kdyz jsem psal od ceho je rozhrani. Ty porad mluvis o behu programu, ale OO design existuje z velke casti pro programatory. Pro vetsi systemovost, jednodussi rozsiritelnost a vymenitelnost komponent. Jak uz jsem popsal -- tvuj system bez jednoticiho prvku bude znamenat peklo pro implementatory komponent, ktere se budou met stejne chovat, ale mit jinou logiku. Vazne by jsi chtel studovat nejakou tridu a zjistovat z jejiho kodu co vlastne vraci, abys mohl napsat podobnou, ale treba misto MySQL pro Oracle?
__autoload()
).
__autoload()
a díky něčemu jako new $dbType
ještě ke všemu zkrátíš kód.
Udelat nekolik trid stejneho jmena resicich podobny problem (navic nemajicich zadneho predka!) a vybirat mezi nimi nejakym CASEm je naprosta prasarna.
Možná pro někoho, kdo odmítá jiného boha než OOP. Ale například v C se takto pomocí maker pracuje už víc jak 30 let a nikdo to za prasárnu nepovažuje...
.Opavdu ne?Možná pro někoho, kdo odmítá jiného boha než OOP. Ale například v C se takto pomocí maker pracuje už víc jak 30 let a nikdo to za prasárnu nepovažuje...
.
Tiskni
Sdílej: