takze ako Venom
Žeby mal na mysli toto https://www.csfd.cz/film/265276-venom/prehled/ (https://www.csfd.cz/film/265276-venom/prehled/)
Mohl bych poprosit o nějaké stručné nakopnutí, co mi inline variables přinesou? Konkrétně v kontextu Delphi - co teď Googluji, tak si dovedu představit jejich smysl pro C++, i když mi pořád připadá, že benefity ani zdaleka nevyrovnají ztrátu kompatibility, ale pro Delphi ty use cases nevidím.
Pokud bude case sensitive (jako JavaScript) tak jenom chaos.
...
Jakou ztrátu kompatibility? Kdo chce používat stávající deklarace může pro všechny verze. Kdo chce i inline, tak je to jeho rozhodnutí a kompatibilita vzhledem kupředu. Takže žádná ztráta.Tomu, že kód s novou featurou nelze použít ve starších Delphi, já říkám ztráta. Speciálně za situace, kdy nelze jednoduše doplnit něco, co mi tu featuru umožní získat i ve starších Delphi (např. pomocí IFDEF STAREDELPHI doplním funkci, která v nich ještě nebyla). To tady podle všeho nemůžu - pokud chci inline proměnné, musím buď zahodit starší Delphi, nebo vlastně celý kód napsat dvakrát, čímž je veškerý přínos z větší přehlednosti v háji.
Výhody:Té závorce nevěřím. Jsem si takřka stoprocentně jistý, že proměnná bude platná až do konce funkce, akorát na ni možná kompilátor nedovolí odkazovat.
- zpřehlednění a bezpečnější kód (proměnná je platná jen kde programátor chce)
- pry to je dulezite pro různé jiné moderní jazykové konstrukce, at uz existující (anonymní metody) nebo možnéProto se ptám, protože mě žádná nenapadá.
Nechápu v čem vidíte problém, za mne naprostá bombaNevidím problém. Jen jsem zároveň neviděl přínos (vypadalo to jako "změna pro změnu") a viděl jsem náklady. Nyní už vidím i ty přínosy (náklady bohužel stále jsou).
Mohl bych poprosit o nějaké stručné nakopnutí, co mi inline variables přinesou? Konkrétně v kontextu Delphi - co teď Googluji, tak si dovedu představit jejich smysl pro C++, i když mi pořád připadá, že benefity ani zdaleka nevyrovnají ztrátu kompatibility, ale pro Delphi ty use cases nevidím.Ty benefity jsou v "nehmotne" oblasti jako je pracnost a srozumitelnost/udrzovatelnost kodu. Jak si na to zvyknes, pak navrat k tupym doprednym definicim ti bude vadit s kazdy stiskem klavesy...
- pry to je dulezite pro různé jiné moderní jazykové konstrukce, at uz existující (anonymní metody) nebo možnéModerni... IMHO to je jeden z duvodu, proc Delphi nema dodnes radne resenou persitenci, protoze deserializace vyzaduje bezparametricky konstruktor, aby se daly vytvaret anonymne vytvaret instance
Problem vidim prave v tom ze muzes napsat oboji. Zive si dokazu predstavit jaky zmatek s tim nedusledni programatori napachaji.No to do urcite miry problem byt muze, zejmena u projektu, ktere se budou migrovat do novych Delphi. Tam se sice da organizacne predepsat, aby se pouzival nadale stary zpusob, ale prakticky to urcite nebude fungovat, takze se tam budou michat oba dva styly. Ale osobne vim, ze cokoli mi usnadni zivot, tak moje hlava vstreba v podstate mimodek a to, co ji pridelava praci, tomu se intenzivne vzpira.
- pry to je dulezite pro různé jiné moderní jazykové konstrukce, at uz existující (anonymní metody) nebo možnéModerni... IMHO to je jeden z duvodu, proc Delphi nema dodnes radne resenou persitenci, protoze deserializace vyzaduje bezparametricky konstruktor, aby se daly vytvaret anonymne vytvaret instance
bezparametricky konstruktor jako např. záznamu? uvidimeZaznam, to je takovy divny "hodnotovy" element, ktery buhvi proc zazil reinkarnaci :-O To vypada jako takove zjednodusijici siditko, ale jakmile to nastrkas do generic, tak zacnou byt problemy se spravou zivotniho cyklu a stejne to konci konverzi na regulerni class.
bezparametricky konstruktor jako např. záznamu? uvidimeZaznam, to je takovy divny "hodnotovy" element, ktery buhvi proc zazil reinkarnaci :-O To vypada jako takove zjednodusijici siditko, ale jakmile to nastrkas do generic, tak zacnou byt problemy se spravou zivotniho cyklu a stejne to konci konverzi na regulerni class.
CitaceVýhody:Té závorce nevěřím. Jsem si takřka stoprocentně jistý, že proměnná bude platná až do konce funkce, akorát na ni možná kompilátor nedovolí odkazovat.
- zpřehlednění a bezpečnější kód (proměnná je platná jen kde programátor chce)
CitaceVýhody:Té závorce nevěřím. Jsem si takřka stoprocentně jistý, že proměnná bude platná až do konce funkce, akorát na ni možná kompilátor nedovolí odkazovat.
- zpřehlednění a bezpečnější kód (proměnná je platná jen kde programátor chce)
Já být tebou bych si na to nevsadil. Už jen logicky to musí fungovat podobně třeba jako u vnořené procedury, nebo snad i anonymní metody (tam je to pro mne pořád celkem velká magie), jen se prostě scope jinak ohraničí. Ale na potvrzení si budeme muset počkat.
Delphi: Inline variables and constants
- scope is limited to block
- Lifetime is limited to block - destroyed on block end
- Tightly scoped - cleaner code
- pry to je dulezite pro různé jiné moderní jazykové konstrukce, at uz existující (anonymní metody) nebo možnéModerni... IMHO to je jeden z duvodu, proc Delphi nema dodnes radne resenou persitenci, protoze deserializace vyzaduje bezparametricky konstruktor, aby se daly vytvaret anonymne vytvaret instance
No nic, k Delphi se stejně vrátím maximálně, když budu potřebovat napsat nějakou mobilní appku, tak mi to může být i jedno.
I Ty, Brute?
A jaky by byl potom rozdil mezi recordem a tridou?Instance třídy je ukazatelem na haldu, instance recordu je přímo blok paměti na zásobníku. Jsou situace, kdy chci pointer, a jsou situace, kdy chci přímo paměť. Dále třída je vždy odděděna od TObject, zatímco record předka mít nemusí (nyní nemůže).
Nebo jinými slovy - jaký smysl má, že record nedovoluje dědičnost? Technický důvod pro to žádný není, za sebe vidím pouze kompatibilitu s minulostí (kterou stejně plánované změny ruší, tak proč se na ni ohlížet?) a možnost říct, "podívejte, máme dvě úplně různé struktury".
Jeden z důvodů by byl, že pak struktura by musela být i něco jako tabulku VMT, nebo se pletu?No, ano, ale čtyři bajty na instanci typu a čtyři bajty na virtuální metodu mi přijde jako malá cena za to, že budu mít dědičný record.
Jaky je rozdil vim. Co nechapu je, proc by struktura mela kdy podle nekterych nazoru umet vic nez ukladani hodnot.Protože teď máme divný hybrid mezi původním pascalským recordem, který umí akorát ukládání hodnot, a třídou, která toho umí mnoho. A za tímco ani jedna z krajních poloh mě neuráží, tak pro hybrid nevidím žádný smysl. To ať už je record plnoprávná obdoba třídy se vším všudy, akorát že se vytváří i ničí automaticky přímo na zásobníku. Ne že budu mít něco, co se chová skoro stejně jako třída, ale má to nesmyslné rozdíly typu "instance se vytvoří sama, ale nezavolá se na ní konstruktor, takže není nainicializovaná", "instance se zničí sama, ale neexistuje pro ni destruktor" (oboje řeší teď poslední úprava do 10.3), "instance může mít metody, ale tyto metody se nemohou overridovat", atd. Jakkoliv nemohu říci, že bych jazyk C považoval za vzor hodný následování, tak zrovna tohle má udělané dobře hned od zavedení objektů.
Jinak psal Barry Kelly (https://stackoverflow.com/questions/2095596), ze jednim z problemu dedicnosti recordu by byl (mimo virtualnich metod) ve ztrate hodnot poli pri prirazovani (tedy napr. i pri predavani zaznamu parametrum). Napr. v tomto pseudokodu:Já v tom právě žádný problém nevidím. Ani z pohledu uživatele, ani z pohledu kompilátoru. A pokud by to někde problém byl, od toho je kopírovací konstruktor a/nebo přiřazovací operátor, aby vyhodil výjimku, že takhle tedy ne.
Mně konstruktory a destruktory u recordu moc k srdci nepřirostly.Bohužel, s tím musíme počítat už od okamžiku, kdy se začaly používat interfacy, protože tam je to přesně to samé. Sám právě v rámci čistoty kódu i u nich používám try-finally s tím, že jim přiřadím nil, abych na první pohled viděl, že je to vyřešené. U recordů bych rád volal ve finally metodu Free, která třeba vůbec nic neudělá, jen bude fungovat jako signál, že ano, je to vyřešené, a kdybych se náhodou rozhodl jednou přejít z recordu na třídu (když už jsou skoro to samé...), tak že mi program bude i nadále fungovat, místo aby začal leakovat.
Když někde vidímKód: Delphi [Vybrat]tak zatím jsem zvyklý, že tPokus je třída, tím pádem očekávám, že tam bude něco jako:
Jakmile se x:=tPokus.Create; bude víc používat i u recordu, tak už nebude tak snadno vidět případné opomenutí toho závěrečného uvolnění instance třídy.Můžeš také používat x.Create bez přiřazení. To bude hned vypadat lépe, jako že voláš metodu na neinstancovaném objektu :-).
Jakmile se x:=tPokus.Create; bude víc používat i u recordu, tak už nebude tak snadno vidět případné opomenutí toho závěrečného uvolnění instance třídy. A tedy si budu muset i pamatovat, co je třída a co record - třeba moje "oblíbené" TFormatSettings, u kterého si to ověřuju co chvíli.
Jen pro jistotu: rozumíš, že nemusíš to Create používat, že?Jenže až od Delphi 10.3. V současných Delphi musíš - a ještě to nesmí být konstruktor, protože jinak ti to Delphi nezkompilují:
On to taky není úplně konstruktor.Jaký jiný název navrhuješ pro funkci, která se zavolá na začátku života datového bloku a nastaví ho do nějakého výchozího stavu?
Konstruktor je součástí alokace objektu dané třídy.Ne, to není.
Ten record existuje sám o soběTo také není pravda. I u recordu proběhne alokace, akorát jiným mechanismem, a udělá ji kód dodaný kompilátorem, ne explicitně programátor.
Jen pro jistotu: rozumíš, že nemusíš to Create používat, že?
Dnes je hezky, dnes by to šlo.
Dnes je hezky, dnes by to šlo.
Že by? Už to není "my nesmíme ani naznačovat"? ;-)