Vlákno názorů k článku PHP 8: trojnásobný výkon díky JIT a užitečné novinky pro programátory od nextsux - Asi už jsem z PHP po těch letech...
-
no, tomu rozumim. Ale to same se prece tyka napriklad data. A toho se tato zmena pokud dobre ctu netyka. Takto se potvrzuje jen PHP schiza, kdy neco se chova tak a neco jinak. Pokud je to chtena zmena, cekal bych, ze obecne echo zacne kaslat na locales - ne jen pro integery.
Stejne tak pokud potrebuju machine-machine, tak se da argumentovat stejne. Si to zformatuju. Stejne machine-machine vetsinou nekomunikuji echem, ale mam nejaky format jako json/xml/protobuf/...Ale rikam, z PHP jsem pryc dlouho, tak jsem fakt pryc od problemu, ktere ho a jeho vyvojare trapi. Jen me to prekvapilo, tak jsem chtel znat nazor lidi, co jsou PHP bliz
-
- - (neregistrovaný)
V php AFAIK vždy když vypisujete Date/Time/DateTime nějak datum formátujete. Navíc formáty data a času až zas tak nesouvisí s locale a běžně se jich používá několik, např. "Y-m-d\TH:i:s" spolu s "d/M/Y" či "d M Y" atd. zatímco u desetiné čárky používáte striktně podle locale a tedy by to mělo být také předmětem formátování. Vidím to prostě jako Single Responsibility principle.
2. 12. 2020, 13:20 editováno autorem komentáře
-
tak teď to moc nechápu. To mi chcete říci, že datum posíláte z PHP např. ve formátu d/M/Y a číslo se pak ještě nějak formátuje, takže ho čech vidí jako "1,24" a američan "1.24". Nechce se mi věřit, že toto myslíte vážně...
Všechno souvisí se vším, přeci. Pokud má být web / app lokalizována, musíte správně zapisovat jak datumy, tak čísla. Texty se také lokalizují ne? Nebo máte na webu: "Dnes být středa, 12/2/20. Kredit je: 1.323 CZK"? Na druhou stranu je pravdou, že lidi často ani neumí zapsat správně česky datum a čas, takže se raději úchýlí z "poamericko-databávovým" formátům ;-(
-
- - (neregistrovaný)
V php přece pracujete s nějakými datetime strukturami, které musíte formátovat na správný formát minimálně při převodu do textové podoby, případně při definici. Číslo ne. Tedy teď už ano. Ale číslo není objekt aby mělo metodu jako např. DateTime::format() nebo date(format), tak se použije tuším je to format_number nebo něco takového.
Pointa je, že při práci s datatime formát dříve či později definujete. Při práci s čísly ne. Teď už ano. Toť můj názor.2. 12. 2020, 15:30 editováno autorem komentáře
-
nesouhlasím :-)
Jsou dvě možosti, tak jak to vidím já:
1) server side - komplet HTML se připraví přímo PHP a pak se jen vyplivne. To ale znamená, že čísla datumy MUSÍ využívat locales, resp. v HTML. Pokud s ním pracujete v PHP, rozhodně nemáte čísla ani datumy lokalizované. Data jsou třeba v UNIX timestampu nebo UTC nebo v tom co vám vyhovuje. Čísla jsou s tečkou.2) pokud PHP slouží třeba jako API, posíláte data, ať už datumy, čísla atd v nějakém výchozím formátu. Vlastní převod do locales provádíte až na klientu.
-
- - (neregistrovaný)
Těch možností je daleko více, můžete např. přelívat data z db do db s nějakým pomocným requestem na různá API ... a je to úplně jedno.
Podle mě jde o "Single responsibility principle". Struktura drží data, formátování výstupu provádí jiná, k tomu určená funkce. U DateTime atd. to tak je, u float to tak nebylo.
Jak to vidím já, tak výstup z takové "echo" by měl být vždy stejný, protože nejde o to, jestli se nějaký programátor zrovna rozhodl to použít pro wep app, ale mělo by to vracet string reprezntaci float tak, jak s ním pracuje php. S tečkou. A pak se taky ten string dá lehce přetypovat zpět, s čárkou už ne, musíte změtit čárku na tečku. Možná to dělají jako přípravu na další změny.2. 12. 2020, 20:14 editováno autorem komentáře
-
-> 87vdf4vg82
Mícháte dohromady 3 věci - vnitřní kódování data a čísel, jejich prezentaci a prostředek k jejich převodu z a do tisknutelné podoby:
Vnitřní kódování na nejnižší úrovni může být v nějakém vlastním binárním formátu nebo jako číslo (unixový čas, jak píše Hurvínek) nebo v nějak kódovaném řetězci (nejlépe ISO 8601), to samé pro čísla či další typy dat, ale vždy jednotně bez vlivu prostředí, v kterém SW pracuje či z jaké oblasti data zpracovává, tudíž je vyloženě nevhodné pro kódování řetězcem volit některý lokalizovaný formát.
Teprve v okamžiku, kdy data potřebuju zobrazit uživateli nebo naopak od něj přijmout, dochází ke konverzi, a je úplně jedno, zda jsou data uložena v primitivním typu, nebo objektu, podstata je pořád stejná.
Že to takhle v SW často není řešeno, je věcí jinou. -
- - (neregistrovaný)
@SB
Ne, ne, to do toho mícháte Vy. Na nějakém vnitřním kódování nezáleží, celé je to o tom, že funkce jako "echo" mají vypsat co je jim dáno a nestarat se o nějaké locale nebo kdoví co ještě. No, maximálně tak převést hodnoty primitivních datových typů, jako např. float, do textové podoby takové, jako je vždy daný jazyk schopen opět přečíst. Jaká to je, je celkem jedno. Jelikož php pužívá u float tečku, jeví se jako vhodné použít .... famfára ... tečku. Kdyby to byla čárka, tak asi čárku - minimálně to usnadní čtení výpisů errorů a taky to tak nějak dává smysl.
Formátování do locale a kdoví čeho dalšího má dělat nějaká úplně jiná funkce.
Jinak víceméně opisujete to, co tady bylo řečeno již několikrát - funkce pro výpis nemá nahrazovat funkci pro formátování. Co s tím má společného nějaké vnitřní kódování na nějaké vnitřní úrovni moc nechápu ...
-
Datum je taky jen číslo. Že může být obaleno objektem je implementační detail. Dokud hodnotu (ať už číslo, datum nebo cokoli jiného) neserializujete do textu, nemá žádný formát. Tedy ani číslo. Systémová locales právě proto umožňují měnit formát výpisu - čísla i datumu. Při deserializaci máte pak logicky problém, protože potřebujete znát formát, abyste hodnotu správně načetl. V PHP je to mimochodem ukázka diletantsví, není v tom ale samo, jinde není také situace zrovna růžová.
