napi js

... es mekkora orom amikor kiderul hogy a javascript a style.zIndex-eket stringkent hasonlitja ossze!

Hozzászólások

Mivel a z-index értéke nem csak numerikus lehet, hanem más is, ennek van is értelme. Az egy hibás feltételezés, hogy a z-index mindig numerikus érték, innen ered ez a meglepőnek tűnő, de amúgy normális viselkedés.

A JS typejugglingjának gyönyörei. Jobban jársz, ha integerműveleteknél (komparációnál is) mindig mind a két oldalra ráhúzol egy parseInt()-et, úgy kevesebb lesz a kellemetlen meglepetés. Persze, ha az van benne, hogy "kecske", akkor azzal sem vagy előrébb, validálni kell őket. De általában sok agybajt megspórolsz a parseInt()-tel, ha ezt ökölszabályként alkalmazod.

Teljesen irreleváns, hogy ezt speciel véletlenül pont lehet szakmailag indokolni, mert egyfelől a JS typejugglingja még mindig egy agyhalál (hint: loose equality), másfelől meg ettől még áll, amit leírtam: ha integer értékek közt végez műveletet, akkor parseInt()-elje mindkét oldalt. És ezen ökölszabályt követve, ugyanez vonatkozik a lebegőpontosokra is (parseFloat()).

Micsoda lehengerlő műszaki érvektől hemzsegő és személyeskedéstől teljesen mentes megnyilvánulást láthattunk. Elolvastad te egyáltalán amit írtam? Vagy megint csak addig sikerült, amíg amygdala hijacket kaptál és nekiálltál kötözködni a semmin? Vagy csak értelmezni nem sikerült, amit írtam?
Indokold már meg plz., hogy a parseInt() használatának javaslata miért is volt itt irreleváns hülyeség?

"Indokold már meg plz., hogy a parseInt() használatának javaslata miért is volt itt irreleváns hülyeség?"

Azért, mert a zIndex értéke nem csak szövegként tárolt szám lehet, hanem olyan is, mint 'auto', 'inherit', 'unset', 'initial'. És őket értelmetlen parseInt()-elni. Aki itt parseIntelni akar, az feltételezi, hogy a zIndex értéke számszerű. De nem az, ehhez persze érteni kell a CSS-hez.

Aha és ha az ominózus z-index érték numerikus, akkor szerinted mit fog vele csinálni a böngésző? Mert szerintem numerikusan értelmezni. És egy numerikus értelmezést hogyan implementálsz JS-ben? Mert szerintem parseInt()-tel. Ennek megfelelően:

function getZIndex(o)
{
	var nzi = parseInt(o.style.zIndex);
	if (!isNaN(nzi))
	{
		return nzi;
	}
	// ide johet a kiszamitosdi
}

Szóval egyáltalán nem volt irreleváns hülyeség, csak gondolkodni is kéne kicsit.

Indokold már meg plz., hogy a parseInt() használatának javaslata miért is volt itt irreleváns hülyeség?

Nem hinném, hogy írtam volna ilyet. De igazad van, valójában abba is lehet kifogásolnivalót találni :) 

Oké, segítek:

  1. A type juggling egyrészt egy PHP specifikus terminológia, amit te keresel az a type coercion vagy type casting. Abban egyetértünk, hogy ez szőrszálhasogatás, és a két terminológia közel ugyanazt a jelenséget fedi le.
  2. Bárhogy is hívjuk, amiről Apal ír, annak nincs köze hozzá, hiszen csupán arról van szó, hogy ő rosszul azt feltételezte, hogy egy bizonyos api egy bizonyos értéket számként ad vissza, holott nem. A két zIndex összehasonlításánál nem történik type casting.

Tehát a reakciód hiányos volt, a javaslatod pedig ráadásul rossz, hiszen a zIndex VEHET FEL nem számszerű értékeket, a számmá konvertálás ilyenkor többet árt, mint használ. És nem érdekel hogy mit írtál még le (kecske), senki se mondta, hogy a teljes mondanivalódat kritizáltam.

Majd persze kijavítanak, de te nem elfogadod ezt, hanem "Teljesen irreleváns, hogy ezt speciel véletlenül pont lehet szakmailag indokolni, mert egyfelől a JS typejugglingja még mindig egy agyhalál"

Olyan egyértelmű, hogy csak fikázni akartad a nyelvet ahelyett, hogy a problémára próbáltál volna koncentrálni. Ha jó megoldást akartál volna javasolni jöhettél volna azzal, hogy a style.zIndex nem feltétlenül a valós értéket tartalmazza, csak az inline stílust, hogy van jobb css api, ami számokkal és mértékegységekkel tud visszatérni, stb.

Hát ez teljesen kész...

> A type juggling egyrészt egy PHP specifikus terminológia, amit te keresel az a type coercion vagy type casting. Abban egyetértünk, hogy ez szőrszálhasogatás, és a két terminológia közel ugyanazt a jelenséget fedi le.

Megválaszoltad magadnak, bár a szőrszálhasogatás enyhe kifejezés.

> Bárhogy is hívjuk, amiről Apal ír, annak nincs köze hozzá, hiszen csupán arról van szó, hogy ő rosszul azt feltételezte, hogy egy bizonyos api egy bizonyos értéket számként ad vissza, holott nem. A két zIndex összehasonlításánál nem történik type casting.

Ez az ami irreleváns volt, mert én leírtam, hogy neki kell megcsinálnia kézzel. Csak nem sikerült elolvasni, most meg össze-vissza magyarázol.

> Tehát a reakciód hiányos volt, a javaslatod pedig ráadásul rossz, hiszen a zIndex VEHET FEL nem számszerű értékeket, a számmá konvertálás ilyenkor többet árt, mint használ. És nem érdekel hogy mit írtál még le (kecske), senki se mondta, hogy a teljes mondanivalódat kritizáltam.

Atyaég... /o\
Tehát magyarul azért hibás amit leírtam, mert nem vettem figyelembe, hogy nem csak szám lehet benne és valójában hiába írtam le szó szerint, hogy lehet benne más is számokon kívül és akkor validálni kéne, akkor is hibás amit mondtam, mert téged nem érdekel, hogy mit írtam le. No. Fucking. Comment. Szerintem ez a vita kb. itt vesztette el teljesen a komolyságát.

> Olyan egyértelmű, hogy csak fikázni akartad a nyelvet ahelyett, hogy a problémára próbáltál volna koncentrálni. Ha jó megoldást akartál volna javasolni jöhettél volna azzal, hogy a style.zIndex nem feltétlenül a valós értéket tartalmazza, csak az inline stílust, hogy van jobb css api, ami számokkal és mértékegységekkel tud visszatérni, stb.

Olyan megoldást adtam, amit működik, tehát jó megoldást akartam adni és adtam is. De te nem olvastad el, csak az első felét, mert nem érdekel, mert fáj az igazság. Nem olvasod el, amit írok, mert nem érdekel és aztán valami totál fals baromságot írsz. Ez is biztos olyan, mint amit a JS viselkedésére mondtál a múltkor, hogy "nem ésszerű, de logikus."

Dafuq? Ez komoly? Akkor is, ha a beírt ojjektum szám? Vagy ilyen nincs is javascriptben?

Nekem ez már magas. Ha két elem zIndex-e 4 és 100, akkor a lexikografikus rendezés szerint a 100 a kisebb, szám szerint pedig a 4. Itt melyik lesz a kisebb, lehet tudni? Mert ha a 100 a kisebb, akkor eddig rosszul használtam, csak azt nem értem, hogy miért nem volt hiba belőle. Ha viszont a 4 a kisebb, akkor miért az, hogyha string?

(Disclaimer: nem vagyok JavaScript programozó, de csináltam már JS-ben dolgokat, amik még működtek is. De úgy néz ki csak véletlenül :-)

Na várj. Ha beállítod CSS-ben a z-indexet numerikus értékre, akkor a böngésző jól fogja összehasonlítani, mert ő tudja, hogy mi a tényleges numerikus érték, még ha a CSS-ben megadtad, hogy 'auto', 'inherit' vagy 'initial' vagy 'unset'. Ezekből a böngésző tényleges numerikus értéket fog számolni, amikor renderel, és ő jól fog összehasonlítani és jól renderel.

Míg ha JS-ben akarod ellenőrizni, hogy két zIndex közül melyik kisebb, akkor nem használhatod a < operátort, ugyanis nem a böngésző által kiszámított Z indexet kapod meg (ami mindig numerikus lenne), hanem azt, ami a CSS-ben van, így például azt akarnád összehasonlítani, hogy 'auto' meg '100', ami nem fog menni értelmesen.
Jó tanács: JS-ben ne akarj zIndexet összehasonlítani anélkül, hogy nem implementálod a Z index kiszámító algoritmust, amit a böngésző is implementál.

Ha a valódi Z Indexét (a kiszámított értéket) akarod a böngészőtől lekérdezni, akkor az szívás, ugyanis a getComputedStyle API sem adja vissza a numerikus Z index értékét, ha mondjuk a CSS-ben beállított érték 'auto'.

Természetesen a szokásos JS-agyhalál módon teljesen inkonzisztens: hol "lexikografikusan", hol "aritmetikusan" (csak akkor miért fordítva van ez is?), a "100" nem csak a "4"-nél, de a "004"-nél is kisebb. Ha! De csak akkor, ha zIndex-eket komparálsz! Konstans, vagy változóba rakott sztringeknél már fordítva van: a "004" kisebb, mint a "100". Pedig az is string! Alien a konzisztencia...

https://jsfiddle.net/jmuysavr/

Ez megint nem a JS hülyesége, csak nem érted, hogy a web stack melyik komponense mit csinál.

Ugyanis attól még, hogy a CSS-be 004-et írsz be, az a CSS értelmező számára 4 lesz, így a JS is azt látja, hogy "4". Teljesen jó ez a működés, csak érteni kéne, hogy melyik stack elem mit csinál.

Teljesen konzisztens a működés, csak a kódod nem ugyanazt hasonlítja össze, mint amit te gondolsz.

Írasd csak ki document.getElementById('zIndexTest3').style.zIndex értékét. Nem 004 lesz, hanem 4. Jó okkal. 

Ugyanis: https://www.w3.org/TR/css-syntax-3/#convert-a-string-to-a-number

 

Én is utálom azt, hogy a W3C specifikációk totálisan inkoherensek, de attól még nem kell agyatlanul szidni azokat, ha nem ismeri az ember. Az általad felvázolt viselkedés teljesen szabályos és megintcsak, semmi köze ahhoz, hogy a JS hogyan komparál értékeket. A CSS parzoláshoz van köze.

A szuk keresztmetszetet ott erzem (es konkretan ez volt az ahol eljott a hiba is nalam) hogy xyz programnyelvben azt mondom hogy ty1=42; ty2=3137; akkor utana a (ty1<ty2) feltetel nem teljesul. Ugyanabban a programnyelvben.

Azaz ebben az esetben az osszes div zIndex-e nem css-en keresztul hanem javascript-en keresztul keletkezett, magaval a div-vel egy blokkban: x1=document.createElement("div");  x2=..., stbstb. modon. Mondhatni, a CSS nyelvezeteig el sem jutottam mert az nem is volt relevans. Marmint oke, x1.style.zIndex=... es ehhez hasonlo ertekadasok vannak/voltak.

Ertem/sejtem a belso logikat amit mondasz, de ez valahol megsem annyira intuitiv. Ezert is tartott legalabb 10-15 percig rajonnom hogy itt most mi a wtf van :) Ha mondjuk szerveroldali backend generalt volna css-t adott z-index-ekkel, rendesen z-index: "3137" formaban (ahogy a referencia mondja), akkor lehet hogy nem tartott volna ennyi ideig.

"Ertem/sejtem a belso logikat amit mondasz, de ez valahol megsem annyira intuitiv. "

Nem az intuicio a lenyeg. MINDEN CSS property tipusa es emiatt az erteke JavaScriptben string. Akkor is, ha numerikus ertekkifejezes lenne benne. Es ez fuggetlen attol, hogy az zIndex, left, display, fontWeight vagy barmi mas. Mindig string a style-ban levo property erteke. Azert, mert nem feltetlenul numerikus az erteke, ugyanis van 3 CSS default, ami mindig valid ertek, barmelyik propertyre: 'inherit', 'unset' es 'initial'. Sosem szabad JS-bol a CSS propertyket nem stringkent kezelni. Ennyit kell csak egyszer megjegyezni, es maris megerted a dolgot.

" z-index: "3137""

Ez mondjuk pont invalid, hiszen a z-index értéke az vagy a 3 default vagy 'auto' vagy egy egesz szam. A "3137" egyik sem. Backend oldalon ezt ugy kell generalni, hogy z-index: 3137;, az a valid ertek.

Hogy ezt a CSS értelmező húzta rá, azt értem, de mi az, hogy "megint"? Ha a fentebbi szóváltásunkra célzol, ott pont neked nem sikerült megragadni a lényeget, nem nekem.

Ami meg az inkoherenciát illeti, az a baj, hogy nem csak a specifikációk, de az implementációk is teljesen inkoherensek, még egy böngészőn belül is, nemhogy böngészők között...
Hogy ennek a fura komparálásnak itt a CSS parsing az oka, az egy dolog, de ott a fentebbi táblázat, amiből azért elég jól kiderül, hogy a JS agyhalott módon komparál értékeket.

Miért? Nem lehet a JS-ben stringet komparálni? Vagy nincs JS-ben type juggling? Vagy mit akartál mondani? Hogy a stringekkel nem zsonglőrködik? Akkor itt van még egyszer a tábla. Az üres string pl. megfelel üres tömbnek, nestingtől függetlenül. Ez nem type juggling, stringekkel? Vagy az, hogy a "1" az true és a "0" meg false, az még egy dolog, de akkor a "-1" miért nem true? Logikailag az, aritmetikailag meg pláne (~0). Ez logikus komparálás?

De mondok mást string és type juggling témakörben: hogy a '8' - 2 az 6, az még oké, de a '8' + 2 akkor miért '82'? Fő a konzisztencia. Egy nagy lábosban. Túl bonyolult lett volna konkatenációra egy másik operátort használni, mint a + jelet? Még a PHP-nak is sikerült, pedig az nagy szó. Aztán még több string és még több type juggling: a "kecske" + + "kecske" az "kecskeNaN". Logikus. Egyáltalán, miért nem hal el egy ilyen formula láttán? Biztos erre is van valami fasza indoklás, hogy ez working as intended. Ez a nyelv egy agyrém.

Személyeskedés látom az megy. Mi váltotta ki? Mivel és hol bántottalak? Beszóltam tán? Mert én nem emlékszem ilyesmire, arra annál inkább, hogy te végig csak beszólogattál, sőt azzal nyitottál. Miért vesztetted el így az önuralmadat? Miért fröcsögsz? Ekkora fájdalom, ekkora sértés neked, ha valaki szidja a JS-t? Ha igen, akkor nem én vagyok a hülye. Nézz gyorsan tükörbe.
Amúgy mondanám, hogy olvasd el még egyszer, dehát mint fentebb kifejtetted, téged nem érdekel, mit írok. Csak akkor minek reagálsz egyáltalán? Hogy fröcsögni lehessen? Leszarod, mit ír a másik, majd te eldöntöd, hogy mit írt és arra írsz valami beszólásokkal megtűzdelt fals ökörséget?

Kérdésedre válaszolva: itt egy gyengén típusos nyelvről beszélünk, azaz típusok csak elméletben vannak. Azt hiszed string és nem az. Amikor azt mondtam, hogy stringek komparálása alatt is van type juggling azt nem azt jelentette, hogy "kecske1" == "kecske2" esetén van type juggling, mert ennek semmi értelme nem lenne, hanem azt, hogy szeretnél összehasonlítani két változót, amiről te feltételezed, hogy string típusú (erre írtam, hogy "stringek komparálásakor") és aztán egyik nem/másik nem/egyik sem az és aztán jön a meglepi, amikor kiderül, hogy "" == []. Naná, ezt ki lehet védeni, ha levalidálod a változókat, pl. typeof-fal (vagy, ha speciel egyezőséget/eltérőséget vizsgálsz, akkor === és !==), de akkor a végén annyi validálásra, manuális konverzióra, típusellenőrzésre és egyéb biztonsági mechanizmusra lesz szükség a nyelv baromságai miatt, hogy a végén tízszer annyi lesz a kód, mert kerülgetni kell olyan problémákat, amik abból erednek, hogy a JS koncepcionálisan el van baszva. Dehát mit várunk egy olyan nyelvtől, amit anno 10 nap alatt dobtak össze? (Nem, ez nem vicc.) Mégis mi értelme van egy olyan nyelvet használni, ahol folyamatosan ellenőrizni kell a típusokat, mert a konverzió alatti megfeleltetéstől "gyakran" kihullik az ember foga? Ennyi erővel használhatnánk valami statikusan típusos nyelvet is, ott legalább indokolt a manuális konverzió.

Na, erre mit fogsz válaszolni? Hogy megint oldalakon át bizonygatom a nemlétező igazamat? Ha valaki olyat mond, ami neked nem tetszik, az automatikusan nem igaz és punktum, tök mindegy mivel támasztja alá? Szép lehet, okos nem? Mindenkinek lehet véleménye, de csak neked lehet igazad? Mert eddig kb. ez jött le és nem csak ebben a topicban.

itt egy gyengén típusos nyelvről beszélünk, azaz típusok csak elméletben vannak

Ez az amiben nincs igazad. Minden referenciának pontosan ismert a típusa - futás időben, a hívás helyén. Ha nem így lenne, akkor nem működne a typeof, az instanceof vagy a strict equality.

akkor a végén annyi validálásra, manuális konverzióra, típusellenőrzésre és egyéb biztonsági mechanizmusra lesz szükség a nyelv baromságai miatt, hogy a végén tízszer annyi lesz a kód

Nem kell. Úgy kell megírni a kódot hogy mindig ismerd a referenciáid lehetséges típusát, és úgy alkalmazás az implicit/explicit típuskonverziókat hogy soha ne álljon elő nem definiált állapot. Nem állítom, hogy ez egyszerűbb, mint statikusan tipusos nyelven programozni, ezért is letezik a TypeScript.

> Ez az amiben nincs igazad. Minden referenciának pontosan ismert a típusa - futás időben, a hívás helyén.

Nem. Nem a VM-ben: a kódban. Egy JS kódban egy változónak nincs típusa. Te nem deklaráltál semmilyen típust, csak a változót, amibe adat került és te pedig azt valamilyen módon felhasználod. Ha egyszerűen akarod megírni, akkor kiindulsz abból, hogy ott ilyen és ilyen típusnak kell lennie, ami ha mellémegy, akkor happy debugging, vagy, lekezeled, hogy milyen típusú is az adott pillanatban vált a változód, ami nyilván több meló és kód, mint az egyszerű felállás. Ezt eredményezi a JS agyrém módon zajló type jugglingja.

> Nem kell. Úgy kell megírni a kódot hogy mindig ismerd a referenciáid lehetséges típusát, és úgy alkalmazás az implicit/explicit típuskonverziókat hogy soha ne álljon elő nem definiált állapot.

Pont erről beszéltem, hogy le kell kezelni a type jugglingból eredő összes lehetséges állapotot, átfedést, fals pozitív konverziót (ld. a tábla) és ez fog a végén sokszoros munkaidőt és kódmennyiséget eredményezni. Nem értem mi nem érthető.

> Nem állítom, hogy ez egyszerűbb, mint statikusan tipusos nyelven programozni, ezért is letezik a TypeScript.

Tehát magad is elismered, hogy a JS típuskezelése annyira problémás, hogy megoldásnak azt javaslod, hogy inkább használjunk egy másik nyelvet, ami majd lefordul JS-re. Ergo a problémát JS-ből nagyobb szívás megoldani, mint nyelvet váltani. (Nem meglepő, a JS maga a probléma.) Ennyi erővel van egy raklap egyéb nyelv is, amihez van JS transpiler/compiler; ez nem érv a JS védelmében, hogy lehet rá fordítani másik nyelvből, ez inkább éppen azt jelzi nagyon is jól, hogy a JS annyira "jó", hogy az emberek kínjukban már inkább más nyelvekből fordítanak JS-re, mert még az is kevesebb szívás.

Kevered a dinamikus típusosságot a gyenge típusossággal. A két fogalom ortogonális egymásra, mind a négy lehetséges kombinációra tudok példát.

  Statikusa típusos Dinamikusan típusos
Erősen típusos Java Python
Gyengén típusos C* JavaScript

* Erről megoszlanak a vélemények, az tény, hogy a C típusrendszere sokkal megengedőbb mint más statikusan típusos nyelveké, pl.: pointer artimetika, signed/unsigned közötti automatikus konverzió, boolean hiánya, stb.

Az, hogy egy referenciának nem ismered előre a típusát az a dinamikus típusossághoz köthető, a "type juggling" a gyengén típusossághoz.

Pont erről beszéltem, hogy le kell kezelni a type jugglingból eredő összes lehetséges állapotot, átfedést, fals pozitív konverziót (ld. a tábla) és ez fog a végén sokszoros munkaidőt és kódmennyiséget eredményezni. Nem értem mi nem érthető.

Privát kód esetén, amikor csak te hívod azt a kódot, akkor pontosan tudod hogy mivel hívod, felesleges lekezelni a nem létező eseteket. Ha 3rd party is hívhatja, akkor ledokumentálod mivel lehet hívni, ami abban nincs az nem definiált viselkedés. Ha te hívsz 3rd partyt, azon meg a rendes teszt lefedettség segít, de az nyelvfüggetlenül hozzátartozik a professzionális szoftverfejlesztéshez (értsd: akkor sem elfogadható ha egy Java kód nincs tesztekkel lefedve).

Tehát magad is elismered, hogy a JS típuskezelése annyira problémás, hogy megoldásnak azt javaslod, hogy inkább használjunk egy másik nyelvet, ami majd lefordul JS-re.

Ne forgasd ki a szavaimat, nem ezt állítottam. A TypeScript csak statikus típusosságot ad a JavaScripthez (lásd fenti táblázat, nem keverendő a type inference-szel), a típusrendszer a kettőben megegyezik. Mindkettőnek megvan a helye és előnyei-hátrányai. Vannak esetek, amikor a statikus típusosság segít, és vannak esetek, amikor csak hátráltat.

> Kevered a dinamikus típusosságot a gyenge típusossággal. ... Az, hogy egy referenciának nem ismered előre a típusát az a dinamikus típusossághoz köthető, a "type juggling" a gyengén típusossághoz.

Nem kevertem, maximum a kommentben összemostam a kettőt, de ez igazából mindegy abból a szempontból, hogy amit elmondtam a JS típuskezelésével kapcsolatban, az áll, mert ahogy a táblázatodból is látszik a JS gyengén és dinamikusan típusos.

> Privát kód esetén, amikor csak te hívod azt a kódot, akkor pontosan tudod hogy mivel hívod, felesleges lekezelni a nem létező eseteket. Ha 3rd party is hívhatja, akkor ledokumentálod mivel lehet hívni, ami abban nincs az nem definiált viselkedés. Ha te hívsz 3rd partyt, azon meg a rendes teszt lefedettség segít, de az nyelvfüggetlenül hozzátartozik a professzionális szoftverfejlesztéshez (értsd: akkor sem elfogadható ha egy Java kód nincs tesztekkel lefedve).

A létező esetek számossága is elegendő munkát ad, pont ezt magyarázom.

> Ne forgasd ki a szavaimat, nem ezt állítottam. A TypeScript csak statikus típusosságot ad a JavaScripthez (lásd fenti táblázat, nem keverendő a type inference-szel), a típusrendszer a kettőben megegyezik. Mindkettőnek megvan a helye és előnyei-hátrányai. Vannak esetek, amikor a statikus típusosság segít, és vannak esetek, amikor csak hátráltat.

Nem forgattam ki, azt írtad, hogy: "Úgy kell megírni a kódot hogy mindig ismerd a referenciáid lehetséges típusát, és úgy alkalmazás az implicit/explicit típuskonverziókat hogy soha ne álljon elő nem definiált állapot. Nem állítom, hogy ez egyszerűbb, mint statikusan tipusos nyelven programozni, ezért is letezik a TypeScript."
Ebből nekem az jött le, hogy a TypeScript azért létezik, mert egyszerűbb egy statikusan típusos nyelvben programozni, mint egy dinamikusan típusosban lekezelgetni az összes lehetséges felállást. (Egyébként ezzel egyet is értek.) Ettől függetlenül a TypeScript még mindig nem a JavaScript, hanem egy másik nyelv.

Ettől függetlenül a TypeScript még mindig nem a JavaScript, hanem egy másik nyelv.

A saját önmeghatározásuk szerint (kiemelés tőlem):

TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.

Továbbá:

At this point, you’re probably ready to start using TypeScript files. The first step is to rename one of your .js files to .ts. If your file uses JSX, you’ll need to rename it to .tsx.

Finished with that step? Great! You’ve successfully migrated a file from JavaScript to TypeScript!

Tehát az állításod csak félig igaz, nem minden TypeScript kód JavaScript, de minden JavaScript kód TypeScript.

> kiemelés tőlem

Kiemelhetted volna azt is, hogy "that compiles to plain JavaScript".

> Tehát az állításod csak félig igaz, nem minden TypeScript kód JavaScript, de minden JavaScript kód TypeScript.

Kissé fals módon, de ez kb. a C és a C++ közti párhuzamhoz hasonlítható, mert a C++ is felülről kompatibilis a C-vel, majdnem minden C kód C++ is, a C kódok közel 100%-át fordítja a C++ compiler, de mégsem mondja senki, hogy a két nyelv ugyanaz, mert nem is azok. Tehát az állításom nem csak félig, de teljesen igaz: a TypeScript az nem a JavaScript, az egy másik nyelv. De ez csak a kisebbik baj, mert ha a browserek megennék a TypeScriptet, akkor le lehetne tojni, hogy ez most két nyelv, vagy egy. De nem eszik. A browserek csak JavaScriptet esznek, az meg megeszi a gépet is, meg a webet is.

Kivéve hogy vannak olyan C programok amik nem valid C++ programok, ezúttal szintaktikai és szemantikai különbségek egyaránt vannak. Pl. a mindenkinek ajánlott Deep C (and C++) diasor első példája gond nélkül fordul és fut mint C program, de nem fordul mint C++ program.

De ez csak a kisebbik baj, mert ha a browserek megennék a TypeScriptet, akkor le lehetne tojni, hogy ez most két nyelv, vagy egy. De nem eszik. A browserek csak JavaScriptet esznek, az meg megeszi a gépet is, meg a webet is.

De minden JavaScript program TypeScript is, ezért vannak olyan TypeScript programok amiket a böngészők transpileolás nélkül tudnak futtatni.

> Kivéve hogy vannak olyan C programok amik nem valid C++ programok, ezúttal szintaktikai és szemantikai különbségek egyaránt vannak. Pl. a mindenkinek ajánlott Deep C (and C++) diasor első példája gond nélkül fordul és fut mint C program, de nem fordul mint C++ program.

Elolvastad te amit írtam?

a C++ is felülről kompatibilis a C-vel, majdnem minden C kód C++ is, a C kódok közel 100%-át fordítja a C++ compiler

Le volt írva, hogy nem teljesen kompatibilis felülről, csak majdnem.

> De minden JavaScript program TypeScript is, ezért vannak olyan TypeScript programok amiket a böngészők transpileolás nélkül tudnak futtatni.

Bocs, de ez akkora csúsztatás, hogy lavinának is beillene. Fogtál egy tisztán JavaScript kódot, beleraktad a TypeScript kódba és közölted, hogy akkor az is TypeScript kód, tehát a browserek tudják futtatni a TypeScript kódok egy részét. Hát nem. Azok a kódok, amikről beszélsz, azok nem TypeScript kódok, hanem JavaScript kódok, amik felhasználhatóak TypeScript kódban is, de attól még nem azok. Azok a kódok már akkor is valid JavaScript kódok voltak, amikor a TypeScriptet még ki sem találták.

Ennyi erővel ezt is lehetne C++ kódnak nevezni, mert megeszi a C++ fordító:

char *kecske = "kecske";

De ettől ez még C kód, ez C-ben már akkor is ment, amikor C++ még nem is volt, másfelől meg C++-ban van már string:

string kecske = "kecske";

Na ez C++ kód, mert ez nem megy C-ben, csak C++-ban. Ugyanez a TS/JS felállásra is. Ami megy egy JavaScript VM-ben, az JavaScript. Ami meg nem, az meg nem.

Na, erre mondtam, hogy csúsztatás, méghozzá orbitális. Attól, hogy a TypeScript visszafelé kompatibilis a JavaScripttel és minden JavaScript egyben valid TypeScript is, attól még ez baromira nem így van, hogy a browserek tudnak TypeScriptet futtatni. Ez belemagyarázás, a lovon fordítva ülés. Azonfelül ez a diagram még hibás is, mert a C/C++ átfedést teljesen rosszul ábrázolta: a C programoknak egy kisebb, a C++-ból csak picit kilógó körnek kellett volna lennie. (Azt nem tudom, hogy az arányok stimmelnek-e, de kb. így.)

Ne aggódj, az önuralmam teljesen a helyén van. Nem gondolnám, hogy dúlnom fúlnom kell, vagy sértődöttnek lennem ahhoz, hogy kritizáljam az állításaidat.

Nézd. Az van, hogy pontatlanul és felületesen fogalmazol, tévedsz dolgokban, és ezt tényként állítod, majd megsértődsz, ha valaki kritizálja. Nem én. Mások is. Vagy szerinted itt mindenki hülye, és csak a te igazad szent?

Ha vitázni akarsz, ám legyen, de akkor alaposan ásd magad bele ezekbe a dolgokba, és ne felületes félinformációk alapján oktass ki mindenkit. Javaslom alaposan ásd bele magad a specifikációba és esetleg nézz bele mélyebben egy js engine működésébe, hogy lásd, hogy ezek a dolgok hogy működnek a háttérben.

Ja, azért hülyéztél le többször is, mert cseppet sem vesztetted el az önuralmadat. Azért közölted, hogy leszarod, amit írok, arra reagálsz, amire akarsz, mert cseppet sem sértődtél be. Tudod kinek add ezt a bullshitet elő.

Én sértődtem meg? Egyelőre te fröcsögsz magadból kikelve, nem én. Az én igazam szent? Te írtad le szószerint, hogy nem érdekel, hogy én mit írok, akkor is rossz, amit írok, ha leírtam azt is, amit szerinted nem. Az pedig tény, hogy a JS szar. Csak nem fogod fel, mert nem akarod felfogni.

Félinformációk... 16 éve szívok a JS-sel, elég sokáig bírnám ecsetelni (ahogy a mellékelt ábra mutatja is), hogy miért tűzrevaló szemét az egész nyelv. Kioktatni egyelőre te oktattál ki engem, iszonyatos butthurt picsogó módon, személyeskedéssel nyitás, ukázkinyilvánítás, a másik ember véleményének, műszaki érveinek deklaráltan szándékos semmibevétele, majd te megmondod, hogy én mit mondtam, ahelyett, hogy elolvasnád és értelmeznéd... A JS meg egy raklap szar marad, tök mindegy mit erőlködsz.

A példában az egyszerűség kedvéért illusztráltam a problémát konstansokkal. Nyilván, aki ilyet leír így, konstansokkal, az inkább menjen kecskepásztornak, csakhogy x - y esetén is ugyanez lesz a helyzet, ha x == '8' és y == 2 és azért lássuk be, ez viszont simán előfordulhat, pl. ha x pl. egy HTML inputból jön be, y meg egy algoritmus eredménye (vagy, amit apal írt egyel feljebb). Nyilván, validálni kell a dolgokat, ahogy fentebb is írtam. Na de, itt jön be akkor a kérdés, hogyha úgyis szénné kell validálni mindent, akkor mivel vagyunk előrébb, mint egy erősen típusos nyelvnél?

bantikoltok ha azt mondom kifejezes?

mert: 10px, auto, 100%, calc(100vw - 10px)

es ez csak a left. De ez szerintem barmire igaz js-ben... Ezert utaljuk.

De vannak mar egesz egesz jo transpilerek. 

pl: http://www.jsweet.org/

bantikoltok ha azt mondom kifejezes?

Hogy mit csinálunk?

 

mert: 10px, auto, 100%, calc(100vw - 10px)

es ez csak a left. De ez szerintem barmire igaz js-ben... Ezert utaljuk.

Mit akarsz mondani? Mi a left? Mi az, hogy a js-ben? Ezek CSS kifejezések, a JS-nek max annyi köze van a dologhoz, hogy van DOM api a CSS manipulálására. 

Szerkesztve: 2020. 03. 30., h - 19:53

Ebben az a legszebb hogy a specifikáció szerint a teljes DOM és CSSOM API nagyon is típusos, a style attribute értéke egy CSSSTyleDeclaration ami az összes lehetséges CSS attribútum - érték párt le kell hogy írja, ezért ahelyett hogy a getPropertyValue() hol számmal, hol stringgel, hol valami mással térne vissza a benne tárolt értéktől függően, egységesen mindig stringgel tér vissza mint egységes típus. Nyilván az API tervezésekor megtehették volna, hogy több interfacet is adnak ugyanarra a attribútum - érték párra ami lehetővé tenné az eltérő típusú visszatérési értékeket, de a z-index esetén még a property neve sem határozza meg egyértelműen az érték típusát mert lehet auto vagy egy egész szám. Továbbá minden CSS property lehet initial, inherit, revert vagy unset.