Byla vydána aktualizována Příručka pro začínající wikipedisty a wikipedistky (pdf).
Ubuntu plánuje v budoucích verzích nahradit tradiční nástroje pro synchronizaci času (chrony, linuxptp a gpsd) novým, v Rustu napsaným ntpd-rs, který nabídne vyšší bezpečnost a stabilitu.
Byla vydána nová verze 7.6 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Správce hesel KeePassXC byl nahrazen správcem hesel GNOME Secrets. Bitcoinová peněženka Electrum byla povýšena na verzi 4.7.0. Tor Browser byl povýšen na verzi 15.0.8. Další novinky v příslušném seznamu.
Chris Down v obsáhlém článku „vyvrací mýty o zswap a zram“, vysvětluje, co vlastně dělají a jaké jsou mezi nimi rozdíly. Doporučuje vyhýbat se zram na serveru a bez OOM.
Porota v Los Angeles shledala firmy Google a Meta odpovědnými v přelomovém soudním sporu, který se týká závislosti na sociálních sítích; firmy musí zaplatit odškodné tři miliony dolarů (63,4 milionu Kč). Společnosti, které s verdiktem nesouhlasí, čelily obvinění, že své sociální sítě a platformy záměrně navrhly tak, aby si na nich děti vypěstovaly závislost. Porota došla k závěru, že technologické společnosti při navrhování a
… více »Jelikož vývojáři editorů Vim a Neovim začali při vývoji využívat LLM, Drew DeVault se rozhodl forknout Vim a vytvořil projekt Vim Classic. Vychází z Vimu 8.2.0148, tj. těsně před zavedením Vim9 skriptování.
Byla vydána nová verze 0.56 open source počítačové hry Unvanquished (Wikipedie), forku počítačové hry Tremulous. Instalovat ji lze také z Flathubu.
FreeCAD (Wikipedie), tj. svobodný multiplatformní parametrický 3D CAD, byl vydán ve verzi 1.1 (YouTube). Po roce a čtyřech měsících od předchozí verze 1.0. Přehled novinek i s náhledy v poznámkách k vydání.
Společnost OpenAI oznámila [𝕏], že ukončí aplikaci Sora pro generování krátkých videí pomocí umělé inteligence. Podrobné informace a harmonogram pro aplikaci a API budou brzy zveřejněny.
Evropská směrnice NIS2 přináší nové požadavky v oblasti kybernetické bezpečnosti, které se promítají také do správy doménových jmen. Do českého právního řádu je směrnice implementována prostřednictvím nového zákona o kybernetické bezpečnosti. Jedním z praktických důsledků této legislativní změny je posílení požadavků na dostupnost a správnost kontaktních údajů držitelů domén. Správce registru domény .cz, sdružení CZ.NIC, je v
… více »$this->__set('foo');
$this->__get('foo');
Getterem/setter nezpřístupníš žádnou imlementaci (naopak), je doplníš (obvykle) veřejné rozhraní. A setter právě potencionální inkonzistenci brání, protože provede ty patřičné operace aby k tomu nedošlo.
Je lepší gettery/settery vůbec nedělat a atributy objektu ponechat jako privátní…Pominu-li, že mohou existovat různé typy tříd, mezi nimi třeba datové, zajištující právě tu konzistenci dat, kde se to minimálně gettery může hemžit, tak se jedná jen o jeden z možných způsobů jak pracovat.
Tím nám objekt zůstane hezky zapouzdřený a nikdo nemůže narušit jeho konzistenci.Vidím tam hříčku, s tím co je zapouzdřené. Ale jinak počítač odpojený od sítě, taky nebude napaden, jeho využití, nechť každý zváží sám…
Pro většinu drtivou setterů, které vidím v různých aplikacích, toto tvrzení neplatí. Sofistikovaným setterům se omlouvám, ty jsem na mysli neměl. Měl jsem na mysli ty primitivní šmejdy, kterými se to v aplikacích jen hemží.A setter právě potencionální inkonzistenci brání, protože provede ty patřičné operace aby k tomu nedošlo.
No, ono se to logicky těmi primitivními hemží (tam kde se používá předávání dat), protože když tam ten primitivní setter/getter je, tak lze třídu případně upravit a udělat z něj pak sofistikovaný setter/getter), a tedy nerozbije se rozhraní třídy.
Furt někde něco nastavovat setterem a vybírat getterem je často jen blbost, nezkušenost či lenost, ale obecně bych to neodsuzoval.
$obj = new Predmet();
$obj->setTvar('kostka');
$obj->setBarva('bílá');
Metoda setTvar() možná kontroluje, zda parametr je některým z podporovaných objektů a setTvar() kontroluje barvu, ale ten objekt není konzistentní. Po provedení prvního řádku vím, že mám nějaký objekt, ale nevím o něm nic. Použití takového objektu zpravidla způsobí chybu. Po provedení druhého řádku vím, že je to kostka, ale barva je stále v nedefinovaném stavu. Objekt stále není konzistentní.
$obj = new Predmet('kulička', 'modrá');
$obj->setTvar('kostka');
$obj->setBarva('bílá');
Už to mám i s konstruktorem. Předmětem je původně modrá kulička, která se pomocí setterů změní na bílou kostku. Samozřejmě je to také špatně.
Proč o tom píši? Protože je to i v různých návodech a spousta tupců to opisuje do svých aplikací. Ukaž mi příklad nějaké své třídy, ve které to bez setteru/getteru nejde. Samozřejmě s privátními vlastnostmi.
Předmětem je původně modrá kulička, která se pomocí setterů změní na bílou kostku.No dobře, tak třeba změna tvaru nemusí být úplně v pořádku, ale nevidím důvod, proč by tu kuličku nemohl někdo přebarvit. Nebo proč by si člověk nemohl změnit telefonní číslo, student opravit známku, okno změnit stav ze zavřeného na otevřené, ... Jak to chceš bez (nějaké obdoby) setteru řešit? Podle mě, máš prostě tři možnosti. Veřejnou metodu, klasický setter jako takový a nebo metodu typu
setFoo($foo). Pokud tě chápu, tak jsi proti všem těmto možnostem, ...
open(), close(), isOpened().
open() na rozdíl od setOpened(true) nepředávám argument, tedy dle Kitovi logiky, nemůže narušit konzistenci objektu.
open(), close() za setter označit nedá.
open() a close(). Každý z nich to může implementovat jinak. Ty implementace se rozhodně nedají označit za settery, protože se netýkají atributu, ale objektu.
open() a close() jsi mě stejně odzbrojil. Tyto metody už nemanipulují s atributem, ale s objektem.
Možná to vypadá jen jako obyčejná změna názvu metod, ale i prosté přejmenování proměnné může změnit smysl třídy a čitelnost programu.
$objekt->setVisible(false); $objekt->setVisible(true);a
$objekt->hide(); $objekt->show();Uvnitř mohou dělat naprosto totéž, ale sémanticky se liší. Které řešení je pro tebe čitelnější?
)
Zapnutí/vypnutí průhlednosti objektu?
Nastavení příznaku, zdali je daná osoba student nebo ne (nezpůsobí to nic, akorát se podle toho následně bude počítat daňový přiznání)?
Nastavení, zdali se dané osobě má nebo nemá posílat pravidelný newsletter.
Atd....
Obecně: symetrické jsou zpravidla ty metody, které nezávisle na argumentu provedou stejné akce (viz např. první dva příklady, oba nezávisle
na vypnutí/zaptnutí způsobí překreslení), speciálně pak ty vlastnosti, jejichž změna nezpůsobí žádnou okamžitou reakci (druhé dvě vlastnosti).
Pokud píšu plně internacionální program, je samozřejmě lepší výčet. Na jednu věc může být dle kontextu více "nejlepších" řešení.
- průhlednost okna - hodí se mít nastavený alfakanál na konstantní hodnotu, ale kromě toho mít možnost tu průhlednost zapnout/vypnout, aniž by člověk hýbal s nastaveným alfakanálem. Dvě metody jsou tady míň ergonomické, protože tudle vlastnost budu vázat s nějakým zapínacím tlačítkem, jehož vypnutí/zapnutí opět jednoduše a bezproblémově vyřeším setterem a getterem. Další výhoda bool setteru je tu symetrie s getterem - který zde zcela jistě potřebuji.
- výčet student/důchodce atd... použít nejde, protože to nemusí být disjunktní množiny (a pokud v současné právní úpravě některé dijunktní jsou, neznamená to, že za rok budou furt: proto je správné tu disjunktnost zajistit nikoli na úrovni uložení dat, ale na úrovni přístupových metod). A pokud to dáš do konstruktoru, tak se nutnosti setteru nezbavíš, protože samozřejmě člověk během svého života tyto své statusy mění. To už mi přijde, že hledáš jakoukoli cestu, hlavně abys nemusel použít bool setter.
- výčet (nezasílat, jenVýroční, zasílat) užít jde, ale je to imho blbé řešení. Totiž ono je použitelné jen pro dvě kategorie newsletterů (a to ještě těžko, jak je vidět, žes ze čtyř možností jsi dal jen tři, protože čtyři už by byl trochu zmatek - a s dalšími kategoriemi roste počet možností exponenciálně). Přitom běžné je, že buď stačí jen hrubé rozdělení (zasílat/nezasílat - např. většina eshopů na webu nic jemnějšího nepotřebuje), nebo je třeba rozdělení dle kategorií newsletterů - kde bude u každé volba ne/zasílat danou kategorii - pak ale zas je většinou hodně nepraktické mít ty kategorie natvrdo v kódu.
Za povšimnutí také stojí, že mé řešení jde na více kategorií jakžtakž rozšířit (původní setter může zůstat jako "all-in-one" nastavování), zatímco řešení s výčtem bude třeba přepsat.
$obj = new Predmet('kulička', 'modrá');
$obj = new Predmet('kostka', 'bílá');
echo $obj;
Původní objekt byl nahrazen novým, atributy vloženy konstruktorem a getter nahrazen metodou __toString(), která udělá i potřebné výstupní formátování. Takový objekt se dá bez problémů místo echa přímo strčit do výstupní šablony.
Jednou definované objekty už zpravidla neměním. Je to jen příklad, jak se dá udělat elegantní viewer.
__set( $name , $value )
$this->foo = value; // zavolá __set('foo', value)
echo $this->foo; // zavolá __get('foo')
Tiskni
Sdílej: