Základní kurz VI. – Proměnné

Again:
Technická poznámka: Možná lepší uložení by bylo někde, kde se nemusí před stažením zadávat CAPTCHA.

Na první pohled mi to přišlo trochu upovídané a místy vyžaduje znalosti, nebo spíš porozumění problematice, které si nejsem jistý že bude mít čtenář základního kurzu.
Zítra si to pročtu blíž.

Again:
nejvíc mi tam chybí zmínka o tom že je php dynamicyk typovaný, je hezké že ti to nevyhovuje, ale je to jedna z nejdůležitějších vlastností a dost se od toho odvíjí. Nevím co bude v příštích kapitolách, takže někam bych doplnil přetypování. Píšeš tam chybně že název proměnné musí začínat písmenem nebo podtržítkem. (by měl je lepší tvrzení). "variable variables" využiješ třeba při extraktu pole, hned příležitost zmínit i funkci. Příklad se špatnou velikostí písmen nemusí vypsat nic, dle nastavení vypíše notice, nejde tedy o zcela bezchybný stav jak se mi jeví z toho že nevypíše nic. Chybí tam toho dost podle mě, otázkou je co bude v dalších kapitolách.


Moc se mi to nelíbí, text neposuzuju, vypadá to skoro jak kdybych to psal já a to by byla katastrofa :)

Again:
nj na to že by tam měly být jen základy sem nějak nemyslel, spíš naopak :) (práveže to nezná, tak aby to poznal). Ale zvážil bych zda některými věcmi tu hlavu trochu nepoplést, ale uvést to na pravou míru, třeba to notice je podle mě podobné jako doporučování konvence. Proměnné proměnné používám často, dokonce zrovna teď. Dynamický typování určitě doplnit, nejsme hocijaký javisté :-P

Again:
Druhá dávka připomínek poté, co jsem si to víc pročetl:
Myslím, že pro začátečníka který třeba nikdy neprogramoval to bude matoucí.
Po úvodním odstavci se rozebírají datové typy, ale začátečník asi bude mít problém to pochopit, když třeba ani neví, jak takový zápis proměnné vypadá.
Navíc třeba: „V případě, že potřebujeme například uložit do proměnné číslo 5, vybereme si příslušný číselný typ.“
A později dokonce: „Hodnoty u proměnných, jak už bylo napsáno výše, závisí na svém datovém typu.“
Podle mě to ve čtenáři vytváří úplně špatnou představu, že když chce definovat proměnnou, zvolí její název a datový typ a podle toho tam pak může dávat hodnoty.
Jenže tak to přece není. Zvolí název a uloží tam hodnotu, která zároveň určuje datový typ.
Ta věta se dá úplně otočit: „V PHP datový typ proměnné závisí na její hodnotě“ a z pohledu výkladu to bude schůdnější, než ta původní varianta.

Dál se tam dost počítá s tím, že čtenář už nějaký programovací jazyk viděl. Posunul bych to víc do roviny někoho, kdo nikdy neprogramoval.
Například mi přijde zbytečný odstavec o deklaraci proměnných. Nebo třeba zmiňovat obor celých čísel.

Výklad pro začátečníky by bylo lepší strukturovat jinak:
- Začít tím zápisem, aby měli představu, jak to vlastně vypadá.
- Potom pravidla pro názvy, ale nevím, jestli do toho míchat i ty konvence. Určitě by to chtělo oddělit syntaktická pravidla a dohodnuté konvence.
- Potom rozebrat datové typy.

Dále:
- proměnné proměnné dle mého názoru zabírají moc místa, hlavně ten příklad je zbytečně rozsáhlý.
- Zrušit vatu jako: „Tímto bych ukončil kapitolu o proměnných“
- Méně odkazů na příští kapitoly. Text by měl především vycházet ze znalostí, které čtenář už má, ne se pořád odkazovat na věci, které ještě nezná.
- Jelikož datové typy proměnných se přímo ve skriptu neuvádějí, není moc důvod používat striktně anglické termíny pro datový typ. Pro začátečníka bude možná schůdnější psát, že proměnná je řetězec nebo celé číslo.
- U reálných čísel chybí varování, že mají omezenou přesnost.
- U celých čísel by to chtělo víc rozepsat ty jiné číselné soustavy. Ne v kontextu toho, aby je čtenář používal, ale v kontextu toho, že by mohl třeba omylem zapsat číslo v osmičkové soustavě.
- Kontrolní otázky ano, ale měly by být víc zaměřené na důležité věci, které si čtenář má ze základního kurzu odnést. Není třeba je zkoušet z terminologie. A třeba 4) by bylo lépe formulovat ve stylu, jestli lze proměnnou tak zapsat. Případně dát několik zápisů a vybrat, které z nich jsou správně.

Joker:
„Jelikož datové typy proměnných se přímo ve skriptu neuvádějí, není moc důvod používat striktně anglické termíny pro datový typ. Pro začátečníka bude možná schůdnější psát, že proměnná je řetězec nebo celé číslo.“
S tím úplně nesouhlasím. Patří to k programování, je to potřeba pro vytváření tabulek v MySQL, jsou to klíčová slova ve veškeré literatuře. Pojmy jako integer, string, ... by měly být zmíněny.

Alphard:
„Pojmy jako integer, string, ... by měly být zmíněny.“
To rozhodně. Možná to v mém příspěvku špatně vyznělo, nechci tvrdit, že by tam anglické termíny být neměly, ale že nemusejí být primární.
Čili rozhodně by tam být měly, ale šlo mi zjednodušeně o něco takovéhoto:
Datové typy:
- String (řetězec)
vs.
Datové typy:
- Řetězec (string)

Nelíbí se mi to. Jsou tam kostrbaté formulace, které odrazují od čtení i zkušeného, začátečníka spíš odradí.
Namátkově:

- "Datové typy prezentují druh zadané informace v proměnné."
načež následuje informace, že pro číslo 5 je vhodné zvolit číselný typ a skoro celý zbytek textu je o tom, že typ není třeba určovat. Už tato věta samotná je matoucí a nicneříkající - přesně to, co člověk přeskočí, protože mu to nic neříká.

- "boolean – datový typ boolean nabývá pouze hodnoty true a false. Tento datový typ je vhodný
například pro testování podmínek, kdy podle něho můžeme zjistit, jestli je podmínka pravdivá
či nikoliv"
Podle něho? Podle čeho přesně? Podle datového typu? Nikoliv. Podle hodnoty booleovské proměnné nebo výrazu.

- "float – datový typ float se zabývá čísly s plovoucí desetinnou čárkou, avšak namísto čárky se
uvádí tečka."
"avšak"? To slovo se používá úplně jinak. A vůbec tady není zmíněna "zaokrouhlovací chyba" floatu.

- string – datový typ string slouží výhradně pro ukládání textových řetězců, které mohou
obsahovat libovolné informace (čísla, písmena, znaky z ASCII tabulky apod.). U tohoto typu
se přiřazovaná informace k proměnné uzavírá do uvozovek nebo apostrofů. Mnoho
začátečníků přikládá k tomuto typu vesměs všechny hodnoty, to je ale špatně. Pokud chcete
například zapsat číslo, výhradně k tomuto účelu používejte vhodný datový typ. Nikdy by se
neměl objevit zápis typu "5" nebo "5.17".

Opět slova jako "ukládání", "informace", "přikládání k tomuto typu". Poslední věta je věcně špatně. Řetězec "5" je naprosto v pořádku, chybou je pracovat s ním jako s číslem.

A tak dále. Možná se opakuju po někom výše, ale ten text mi připadá špatný. Sorry.

Again:
„Problémem je, že tohle je jakási specialita PHP. Až takový uživatel okusí Pascal (na kterém se běžně začíná) nebo i další jazyky, tak se bude hodně divit, že dostane facku za každý špatně napsaný datový typ.“
Ale ta učebnice se týká právě PHP.
Navíc někdo kdo začíná s PHP se nejspíš bude pohybovat v prostředí webu a nejpravděpodobnější další jazyk se kterým se setká je JavaScript. A ten taky určuje typ proměnné podle hodnoty.
Čili někomu, kdo se nejdřív naučil HTML, pak JavaScript a teď se učí PHP to může naopak přijít jako normální chování.

„Na druhou stranu, pokud to někdo myslí s programováním vážně, tak bude muset některé věci překousnout. Nemůžeme to vyprávět jak pro děti do 12 let.“
Ovšem ten základní kurz nemá za cíl vychovat schopného programátora v C-like jazycích, ale aby čtenář pochopil základy PHP.

Překlep: "liteláry" (§ Hodnoty proměnných). Místo $znamkaZcestiny bych asi čekala $znamkaZCestiny, když mluvíte o camelCase, ale to je detail.

„Narozdíl od ostatních jazyků, z nichž jmenujme např. Javu, se datový typ před proměnnou neuvádí a proměnnou nemusíme předem ani deklarovat (tj. vytvoření speciálního místa v operační paměti).“
- začátečník si pod tím "vytvořením spec.místa" nic nepředstaví. Co to napsat opačně: "V některých prog.jazycích (např. Java) se před prvním použitím musí každá proměnná deklarovat (tj. určit, jak se bude jmenovat a jaký typ dat se do ní bude ukládat). V PHP to není nutné, proměnná prostě začne existovat tehdy, když ji poprvé použijete." (což vlastně napsal už Joker, jak koukám).

Možná to trochu předbíhá, ale chybí mi tam zmínka o var_dump. Občas tu začátečníkům radíme: „Vypište si hodnotu“, ale ne všichni vědí jak. Tím, že var_dump ukazuje i datový typ, najde určitě využití např. v příkladech k automatickému přetypování.

„// příkaz není ukončený středníkem, proto skončí fatal errorem“ (§ Nejčastější chyby) - jen v případě, že za ním nenásleduje koncový tag ?>.

„Rozdíl mezi int a float spočívá právě v zápisu desetinných čísel, přičemž u typu int není tento zápis dovolen.“ - co to znamená, vyhodí mi to chybu? Ve většině případů se spíš jedno z čísel tiše přetypuje.

Tori:
„Možná to trochu předbíhá, ale chybí mi tam zmínka o var_dump.“
To by u proměnných bylo dobré zmínit.
Zároveň se na tom dají hezky ukázat ty datové typy.

Jinak s tím středníkem, možná je zbytečné dávat tam zvláštní příklad na středník, o tom se píše v základech syntaxe.

Tori:
„V PHP to není nutné, proměnná prostě začne existovat tehdy, když ji poprvé použijete.“
To je sice asi pravda, ale nemělo by to vyznít tak, že vůbec není třeba definovat proměnnou (nebo kontrolovat jestli existuje) a pracovat s ní. Je jen otázkou kdy v tom někdo udělá špatně dohledatelnou chybu. Navíc nedefinovaná proměnná hází E_NOTICE. Místo použijete bych psal definujete.

$a++; var_dump($a); je sice funkční kód, ale snad se shodneme na tom, že bychom takový zápis nikoho učit neměli :)

Toto mi přijde důležitý - normální uvozovky vs. jednoduché uvozovky a parsování výrazu uvnitř (to bývá poměrně často i na pohovorech)
vs.

Lamicz:
„Toto mi přijde důležitý - normální uvozovky vs. jednoduché uvozovky a parsování výrazu uvnitř (to bývá poměrně často i na pohovorech)“
To jsem sem zrovna přišel napsat, že by se u proměnných mělo zmínit jejich začlenění do řetězce a rozdíl mezi uvozovkami a apotrofy.

Uvozovky a apostrofy zmiňuji v základech syntaxe, ale jen do té míry, že jsou to dva způsoby zapsání řetězce.

I když možná bychom to mohli udělat ještě jinak a řetězcům věnovat samostatnou kapitolu po operátorech.

Joker:
„I když možná bychom to mohli udělat ještě jinak a řetězcům věnovat samostatnou kapitolu po operátorech.“
Už dlouho tady přepisuji odpověď a přemýšlím, co by bylo nejlepší. Zatím se mi zdá, že pro podrobné vysvětlení bude potřeba samostatný díl v pokročilé části.

> U reálných čísel chybí varování, že mají omezenou přesnost.
> Doplním
Ma-li být díl o proměnných úplný, měl by obsahovat i rozsahy jednotlivých typů. Proč je z "normální čísla" najednou 5.4686256E+21.
Vysvětlení nepřesnosti vyžaduje ukázku zápisu desetinného čísla v binární soustavě, popsat princip. Navíc tady padl návrh vysvětlit zápis v osmičkové soustavě, pochopitelně bude následovat hexa. Když už budou zmíněny, měly by být ukázky aplikace.

[#15][#16]
Podobný problém bude ve chvíli, kdy přibydou pole a objekty. Jejich zápis do řetězců není triviální a zdá se mi, že hodně lidí má problém i s takovou samozřejmostí jako je

Přemýšlel jsem o sérii článků zabývající se všemi používanými datovými strukturami, která by byla zároveň přípravou pro databáze.

Mně se ten text nelíbí. Místy je dost kostrbatý, zavádějící, místy dokonce lživý a zároveň v něm chybí spousta podstatných informací.


[#4] Again:
„Čím ještě může začínat název proměnné kromě písmen a podtržítka?“
Znaky \x7f-\xff (máš to i v textu, který cituješ), ty zmiňuješ pouze a-z.

„To samé platí o nastavení direktivy display_errors, pokud je zapnuté E_NOTICE, což je poněkud rozporuplné nastavení, tak se nám zobrazí veselé "Undefined variable", ale proměnnou stejně nevypíše.“
Příklady by měly předpokládat E_ALL | E_STRICT a možné chyby explicitně zmiňovat. Jakuba Vránu prosím necitovat, na svém webu počítá s vypnutým E_NOTICE (viz poznámka v patičce).

„To dynamické přetypování je dobrá připomínka, pokusím se to tam doplnit.“
Přetypování do této kapitoly nepatří. O něm by měla pojednávat následující kapitola.

„kolikrát jste už prakticky použil proměnné proměnné?“
Je to sice rarita a bad practice, ale zmíněno by to být mělo. Klidně v rozšiřující/nepovinné části textu.

[#6] Joker:
„Pro začátečníka bude možná schůdnější psát, že proměnná je řetězec nebo celé číslo.“
Je nutné, aby znal jejich anglický ekvivalent. Bez toho se neobejde. Nejsem si jist, kterou verzi preferovat, spíše bych se ale příkláněl k anglické verzi. Nicméně asi záleží na konkrétním použití (ve větě nebo samostatně).

[#10] Again:
„a také ze stávajícího textu na Linuxsoftu“
Osobně bych se v textu na Linuxsoftu moc neinspiroval, nepíšeme přeci jeho kopii.

„Problémem je, že tohle je jakási specialita PHP.“
Opravdu? A co třeba Ruby, Javascript, Python, Bash a další?
Pascal bych sem netahal. Stejnětak odkazování se na jiné jazyky (např. v příkladech, někde jsem zahlédl Javu). Předpokládejme neznalost.

„V prvé řadě mi šlo o to, ať začátečník neprovádí výpočty s řetězci, což mu díky Type Juggling všechno projde.“
Opravdu? A co třeba '2' + '2,25' (čárka je zde úmyslně), to neprojde, ale zároveň ani nebude křičet a výsledek bude jiný (4) než očekávaný (4.25).

[#12] Tori:
„V PHP to není nutné, proměnná prostě začne existovat tehdy, když ji poprvé použijete.“
To ale není (obecně) pravda. Záleží na kontextu použití. Například volání metody na neinicalizované proměnné skončí fatální chybou. Taktéž neplatí tvrzení, že by se při prvním užití v nefatálním případě deklarovala. Viz toto:
Generuje 2x hlášku E_NOTICE.

[#15] Lamicz:
Souhlasím, určitě je třeba zmínit. Zároveň tam chybí možnosti použití proměnných a výrazů v řetězci, jak zmiňuje Alphard v [#17].


Co mi v textu chybí:
- přepisování hodnot proměnných, stejným i jiným typem;
- chování neinicializovaných proměnných - při čtení a zápisu z/do nich;
- všechny datové typy - chybí i ty zásadní jako NULL, pole objekty apod. bych zmínil, ale nerozebíral podrobně;
- přístup k řetězci jako k poli, tj. $string[0];
- integer a další možné overflow;
- kontroly pomocí isset a empty;;
- reference (spíše asi do rozšiřující části, viz výše);


Text má určité nedostatky, některé části se například špatně čtou. Zejména mi vadí, že je psán chvíli formou my, pak zas vy. Omáčka a subjektivní dojmy tam rozhodně nepatří (tj. např.: „Tato vlastnost mi v PHP příliš nevyhovuje“) - vyhodit. Uváděj tam pouze informace, které nejsou subjektivní a jsou pravdivé.

Příště prosím jinam než na otravné sharing servery s captchou.

Again:
„typované jazyky jsou dle mého názoru mnohem přesnější a pro začátečníka vhodnější“
To je sice možné, ovšem PHP takové není, takže se tím nemá cenu zabývat.

„Co třeba zápis '2'+'2.25', tady všechno projde a uživatel si veselé počítá s řetězci.“
Opravdu? Ale on nepočítá s řetězci, jelikož ty stringy se přetypují na int a float a s těmi se pak počítá.

„Pokud vím, tak čárka se neuvádí u desetinných čísel snad ani na kalkulačce“
V české typografii se pro oddělení desetinný míst používá čárka. Dokonce to má i v názvu. Takže se nemůžeš divit, že tam hodně lidí určitě čárku napíše. Dalším důvodem, proč ji mohou psát je i to, že při českém rozložení ten oddělovač desetinných míst v numerické části klávesnice píše čárku.

Again:
„než hádat jestli má uživatel povolené E_NOTICE“
Ale tady nikdo nehádá. Zkrátka to předpokládejme.

„Já ale nemám v plánu popisovat přetypování“
Ale napsal jsi přetypování, ne typování. Proto jsem to zmínil.

„jenže jsem nechtěl uživatele nijak nabádat k jejich užívání“
Souhlasím, standardně se to běžně nepoužívá.

„ostatní jazyky jsem viděl maximálně z rychlíku“
To je čistě tvůj problém, že nemáš větší rozhled. Do testu každopádně úvaha nepatří.
Mimochodem i třeba Ruby a Python dovolují míchat více typů, třeba "hello" * 2 v Ruby vypíše "hellohello".

„Pokud vím, tak čárka se neuvádí u desetinných čísel snad ani na kalkulačce“
Jak říká Keeehi, česky je správně čárka, ne tečka. Viz článek na Wiki.

„uvádím pouze základní datové typy (skalární)“
U float chybí ještě zmínka o jeho aliasu double (což je taky specialita PHP).

„Co se týče NULL, tak taky nevím, jestli je to nutné rozebírat“
U NULL bych asi jen zmínil, že to znamená žádná hodnota a jak/kdy je vhodné ji použít.

„začátečník nezná podmínky, takže mu to bude docela k ničemu“
Začátečník sice nezná podmínky, ale zná výpis pomocí echo, může tedy udělat:


Ještě mě teď napadly další věci:
- zmínit ještě jazykový konstrukt unset,
- ukázat a vysvětlit zrádnost desetinné čárky tímto zápisem: echo 2,25;, kdy nebude vypsáno "2,25" dle očekávání, ale 225.

Again:
Mé poznámky:
- Bylo by dobré v rámci proměnných vysvětlit i zpracování proměnných uvnitř řetězce. Kdyžtak v Základní kurz IV. – Základy syntaxe je už přibližně vidět, co všechno je popsané u vysvětlení příkazu echo.
Escapování tam je nastíněné, ale dolar nezmiňuji, protože tam nelze předpokládat znalost proměnných.
Vysvětlení by mělo pokrývat zhruba toto chování:
Jde se odrazit od termínů vysvětlených v základech syntaxe, takže by to mohlo být asi tímhle stylem: V řetězci v uvozovkách se proměnné zpracují, dolar se chová jako speciální symbol a proto se musí escapovat. U řetězce v apostrofech dolar speciální význam nemá, nemusí se escapovat a proměnné se nezpracují.

- U názvů mi místo zvlášť výčtu co může být na začátku a co uvnitř názvu přijde srozumitelnější napsat výčet co může být v názvu s tím, že proměnná nesmí začínat číslem. A hodilo by se pár příkladů platných a neplatných názvů.
Dál ty jednotlivé povolené hodnoty nemohou být postavené na stejnou úroveň, že „Název proměnné musí začínat znaky a-z/A-Z, podtržítkem nebo některým z ASCII
znaků od 127 do 255 (0x7f-0xff).“ Doporučení by mělo být: Písmena, podtržítko, případně čísla (uvnitř), nic jiného nepoužívat.
Třeba 0x7F (kontrolní znak DEL) si neumím reálně představit v názvu proměnné, znaky 0x7F-0x9F mohou (v UTF-8) v editoru plodit divné efekty a 0xA0 je nedělitelná mezera, takže $znamka z cestiny sice je platný název proměnné a kód funguje, ale použití něčeho takového v životě nesmíme doporučit.

Navrhuji to formulovat v tomhle stylu:
Název proměnné může obsahovat písmena, podtržítko a čísla, ale nesmí číslem začínat. PHP v názvech dovoluje použít i některé další znaky (tyto, když předpokládáme kódování skriptu UTF-8), ale nepoužívejte je, může to působit různé nečekané problémy (např. jsou povolená jen některá písmena s diakritikou, takže třeba $známka funguje, $čeština nefunguje - stále předpokládáme kódování skriptu UTF-8).

Z následující odrážky bych škrtl to „ve své podstatě“. Prostě „název musí být unikátní a při použití názvu definovaného už dříve pracujete s tou dřívější proměnnou“.
Neškodilo by k tomu přidat dvě věci:
1. Pokud nějaká proměnná ve skriptu má podivné neočekávané hodnoty, vyplatí se zkontrolovat, jestli není omylem pojmenovaná stejně jako jiná proměnná.
2. Varovat před recyklací názvů proměnných, tj. definováním nějaké obecné proměnné třeba $a a jejím používáním k různým účelům v různých částech skriptu.

„Musíte uznat, že tento zápis je více přehledný, než předchozí příklad.“
Jednak „více přehledný“, fuj! V češtině máme stupňování, takže kdyžtak přehlednější. Ale vynechal bych i to „Musíte uznat“, „V této učebnici se bude používat tento zápis, protože je přehlednější“.

„kód se díky nim stává nepřehledný a při operaci s nimi se často přepíšete“
Hned tři „češtinské“ výtky: Díky ve spojení s negativním následkem (častá chyba), „stává se nepřehledný“ a „při operaci s nimi“.
„Kód je kvůli nim méně přehledný“, nebo „Zhoršují čitelnost kódu“ a při práci s nimi se často přepíšete.

- U úplně prvního příkladu na desetinné číslo bych možná přidal zmínku, že tečka místo čárky je úmyslná (jak je pak vysvětlené níž).
- „chybové hlášení ‚Undefined variable‘“, možná bych tam vypsal větší kus. A čistě technicky to je jen poznámka (notice).
V případě potřeby můžu dodat rozpracovanou kapitolu o chybách, kde se řeší typy hlášek.

- „o 32 bit. nebo 64 bit. rozsahu (závisí na platformě), což znamená, že maximální velikost čísla na 64 bitové platformě je (+/-) 9 223 372 036 854 775 807.“
Možná lepší než konkrétní hodnoty by bylo zmínit konstantu PHP_INT_MAX (ale pozor, jelikož se neprobíraly konstanty, asi to bude chtít taky napsat, že se tam nepíše dolar ani uvozovky).
Asi lepší formulace by byla, že int má omezený rozsah, který se může lišit podle platformy na které server běží, nejvyšší možné číslo lze zjistit echo PHP_INT_MAX, nejnižší možné je o 1 nižší s negativním znaménkem.
Taky mi chybí zmínka, jak vlastně PHP na přetečení reaguje: Integer se automaticky konvertuje na float (který má větší rozsah) a příliš velký float se změní na INF.

- „opakem je podtečení (underflow)“
Chybné použití termínu podtečení. Uložení velmi nízkého záporného čísla (tzn. čísla se záporným znaménkem a vysokou absolutní hodnotou) způsobí taky přetečení.
Podtečení může nastat jen v plovoucí čárce a navíc obvykle nezpůsobí problém, takže asi není vůbec třeba ho zmiňovat.

- „Číslo taktéž nemusí být nutně zapsané v desetinné soustavě“
Začátečník asi nebude záměrně ukládat čísla v jiných soustavách, bylo by lepší to koncipovat jako upozornění na to, že ty zápisy znamenají jiné číslo, než by mohl intuitivně očekávat.
Čili ne ve smyslu „Číslo v osmičkové soustavě zadáte takto“, ale „Pozor, číslo s nulou na začátku se bere jako osmičková soustava“.

- „špatně zapsané desetinné číslo (4,7), způsobí fatal error“
Prosil bych změnit na „parse error“ (v článku o chybách bude dělení: Parse error, Fatal error, Warning, Notice, Deprecated a Strict standards).

- „Desetinná čísla datové typu float nejsou příliš přesná“
Tohle je chybně.
Jednak většina lidí má představu o „takové normální úrovni přesnosti“ někde kolem 2 desetinných míst a 14 míst je dost vysoká přesnost :-)
Ale hlavně, podstata problému není nepřesnost typu float ve smyslu nějakého omezení počtu desetinných míst (podobně jako když Pí místo 3,14159… vezmu 3,14).
Ostatně přece na absolutně přesný výpočet (0,1+0,7)*10 stačí přesnost na 1 desetinné místo, což odporuje tvrzení, že float má přesnost zhruba na 14 desetinných míst.
Podstata problému je v tom, že float neumí reprezentovat jakékoliv číslo, a to ani z nějakého omezeného intervalu, což je dané už tím, že reálných čísel je na libovolném intervalu nekonečně mnoho.

Vysvětlení bych asi začal nejdřív tím příkladem (z čehož mimochodem vyplývá, že budeme v kapitole o základech syntaxe muset alespoň nastínit výrazy a některé operátory). Pokračoval úvahou, že reálných čísel je na libovolném intervalu nekonečně mnoho, zatímco počítač nekonečně velkou paměť nemá a navíc aby skript mohl rozumě fungovat, může jedno číslo obsadit jen velmi malý prostor v paměti. Proto float nedokáže uložit libovolné číslo, ale místo zadaného čísla prostě uloží nejbližší číslo, které uložit dokáže.

- Přístup k řetězci jako k poli by měl být až u polí, tady to bude matoucí.

- Námět: Nepřesunout var_dump před popis datových typů, aby se pak mohl používat pro výpis místo echo?

Dodatek:
U typu bool by ještě mohlo být, že hodnota „true“ se typicky používá ve významu „ano“ nebo „pravda“ a hodnota „false“ ve významu „ne“, „není pravda“.

Again:
Nechtěl bys to příště publikovat v nějakém rozumnějším formátu, než pdf (např. texy, markdown nebo Google Doc)?


„Každá proměnná má svůj datový typ, jedinečný název a hodnotu.“
Vzhledem k tomu, že ta jedinečnost je vázaná na scope (oblast platnosti?), tak bych to vynechal. Dále bych změnit pořadí, takže vznikne:
Každá proměnná má svůj název, hodnotu a datový typ.

„Zápis a výpis proměnných“
Spojení „zápis proměnných“ nepovažuji za vhodné. Lepší je „inicializace proměnných“.

„Pokud tak neučiníte, nejenže nevznikne nová proměnná, ale…“
Netřeba vysvětlovat, co se stane, když ten dolar vynechají. Stačí, že vezmou na vědomí, že ten dolar tam prostě patří.

„název proměnné (…), který podléhá hned několika pravidlům“
Ty pravidla začátečníka nezajímají. Vysvětlovat jim, že název proměnné nesmí obsahovat např. null byte považuji za zbytečné a zbytečně matoucí.

„Kromě těchto závazných pravidel (…) existuje v PHP také řada konvencí.“
Zbytečně formální.

„Musíte uznat, že tento zápis je více přehledný, než předchozí příklad.“
Nikdo nic uznávat nemusí. Je to věc osobní preference.

„Je lepší zvolit název ‚x‘ nebo ‚souradniceX‘?“
Podařilo se ti vymyslet jeden z mála příkladu, kde $x je správné pojmenování proměnné :)

Ten odstavec bych přepsal asi takto:
Inicializace proměnné (tady bude české vysvětlení) začíná speciálním znakem $ (dolar), za nímž těsně (tj. bez žádných mezer) následuje název proměnné (někdy se označuje jako identifikátor).

Název proměnné nesmí začínat číslem a obsahovat mezery ani jiné speciální znaky. Může obsahovat diakritiku, ale není to doporučeno. Název proměnné by měl vystihovat, co proměnná obsahuje, např. $jmeno nebo $rokNarozeni. Všimněte si také, že je zvykem psát název proměnné malými písmeny, u víceslovných proměnných je první písmeno druhého a dalšího slova velké (tady by to možná chtělo slovní optimalizaci).



„Poslední důležitou součástí každé nové proměnné…“
Tenhle odstavec je lepší, ale přepsal bych ho asi takto:
Za názvem proměnné následuje (obvykle oddělený jednou mezerou z každé strany) znak = (rovná se nebo také operátor přiřazení), za nímž je uvedený výraz, jehož hodnota bude přiřazena proměnné. (nevhodně použitý termín „výraz“, neboť nebyl ještě vysvětlen)

„$znamkaZCestiny“
Máš docela talent na vymýšlení špatných příkladů. Chtělo by to někoho s opačným talentem. Já to bohužel nejsem, ale i tak se domnívám, že lepší příklady budou třeba:


„Nyní máte vaše hodnoty uložené v označených proměnných…“
Dal bych před to nadpis „Výpis proměnných“ nebo možná spíš „Vypsání hodnot uložených v proměnných“.

„Datové typy prezentují druh zadané hodnoty v proměnné.“
Neřekl bych, že něco „prezentují“. Dobrou alternativu ale zatím nemám.

„dynamický typovaný jazyk“
Nikoliv. PHP je „dynamicky typovaný jazyk“.

„maximální velikost čísla na 64 bitové platformě je (+/-) 9 223 372 036 854 775 807“
64-bitová verze PHP se pokud skoro nepoužívá (možná se mýlím), takže by měly být uvedeny spíš rozsahy pro 32 bitovou a existenci 64 bitové verze bych klidně zamlčel.

„Číslo taktéž nemusí být nutně zapsané v desetinné soustavě, ale můžete použít i šestnáctkovou/osmičkovou a dvojkovou soustavu.“
Tohle bych přeformuloval:
Čísla lze kromě v desítkové soustavě zapsat také ve dvojkové (od PHP 5.4), osmičkové nebo šestnáctkové soustavě.
Navíc vůbec nevysvětluješ, jak to zapsat, pouze ukazuješ pár příkladů, ze kterých to nemusí být jasné. Navíc je otázka, jestli by to vůbec mělo být probíráno v této kapitole, vzhledem k tomu, že to nesouvisí s proměnnými, ale jedná se o obecnou vlastnost literálů. To platí vlastně i pro datové typy.

„datový typ string slouží výhradně pro ukládání textových řetězců“
To není pravda. V PHP není string nic jiného, než sekvence (naprosto libovolných) bytů.

„můžete k těmto znakům přistupovat jednotlivě pomocí indexu“
To právě vůbec není pravda. Přistupuješ k jednotlivým bytům. Navíc ten příklad tak trochu předpokládá znalost polí.



„Tato proměnná nemá žádnou hodnotu, je však datového typu string“
To není pravda. Má hodnotu a tou hodnotou je prázdný řetězec.

„S prázdnými/neinicializovanými proměnnými souvisí také klíčové slova (…) isset, empty a unset.“
To chování není rozhodně tak jednoduché, tak se domníváš, že si z příkladu odvodí.


Je toho ještě spousta k připomínkování, ale už mě to nebaví.

Jan Tvrdík:
„Název proměnné nesmí začínat číslem a obsahovat mezery ani jiné speciální znaky. Může obsahovat diakritiku, ale není to doporučeno.“
Tohle ale není pravda, viz můj příspěvek (od začátku odstavce s označeným textem).
Z české diakritiky mohou být jen samohlásky s čárkou a háčkem. Souhlásky s diakritikou a ů nejsou platné. Zato může být mezera (resp. tvrdá mezera 0xA0) a kupa speciálních znaků, třeba $£¥¢¤ nebo $x²×½x±¾ jsou platné názvy proměnných.

Joker:
„Souhlásky s diakritikou a ů nejsou platné.“
To by mě zajímalo, jak jsi na to přišel. Konkrétně ů se v UTF-8 (což předpokládáme) zapíše sekvencí bytů 0xC5 0xAF. Oba jsou v povoleném rozsahu.

Jan Tvrdík:
Moje chyba, ony jsou vlastně povolené všechny vícebajtové znaky z UTF-8, protože mají vždycky všechny bajty vyšší než 127.

Joker:
„V této učebnici se bude používat tento zápis, protože je přehlednější“
Já si to myslím také, ale pořád se jedná o subjektivní názor, který bychom neměli označovat za fakt. Správná formulace by tedy byla „protože ho považujeme za přehlednější“. Nicméně pořád trvám na tom, že lepší je tam tu větu vůbec nepsat.