Funguje TypeScript aj za run-time?

[Wal-De-Mar]

Takže v Jave budem čítať vstup, čo len z konzoly, a pri pokuse priradiť načítaný string do premennej typu int mi program nespadne na runtime error?

to typescript nedovolí. Musíte nejdřív převést na číslo.

Ale dovolí. Lebo za runtime tam z TS syntaxu neostane ani zmienka. Vo formulári ti užívateľ zadá text miesto čísla a TS ti s tým nijak nepomôže. Len si pletieš buildtime s runtime.

[Reklama]

[BoneFlute]

Jeden tu motá dohromady build time s run time, iný motá dohromady refaktorizáciu s typmi. To je tak všetko, čo som sa dozvedel. Ako vždy na tomto fóre, nič.

Tak si říkám, možná by bylo užitečnější, když by si radil spíše ty nám, ne? Určitě se máme od tebe hodně co naučit.

[Wal-De-Mar]

Alebo naopak? Rozlišujem medzi buildtime a runtime a tvrdím, len prijebanci sa môžu za runtime odvolávať na statické typy? Že sú im za runtime na piču a musia si strážiť vstupy rovnako, ručne, prídavnými typovými kontrolami, či už v staticky, či dynamicky typovanom jazyku? Inak im program zhodí / hackne 10 ročné decko? A ešte sa mi iný dement pochváli, že staticky typovaný jazyk je lepší, lebo za  runtime nestráži ani rozsah hodnôt? A??? Šak kontrola ručne navyše aby sa to za behu nestalo, lebo overflow/underflow je najpriamejšia cesta ako kompromitovať apku! Vám to tu ale pekne jebe vy "programátori"

Takhle to dopadá, když se nedostudovanci dají na programování. A pokud máš IT vysokou školu, tak radši nechci ani vědět kterou.

Zkus si v tom svém Javascriptu toto:

Kód: [Vybrat]

> parseInt("10765432100123456789")
a budeš překvapený, co ti vyleze. Přičemž je docela běžné, že se id v JSONu posílají v numerickém formátu. Něříkám, že to je problém, prostě to je takto definováno, ale je zjevné, že o tom vůbec nevíš.

Čo si ty za debila... A čo má parseInt, manuálne sparsovanie hodnoty, spoločné s typmi??? Veď to je to, čo hovorím: že kým si sám, napríklad s parseInt, alebo obdobne sám neustrážim hodnotu na vstupe, tak typový systém už vôbec nie.

[Wal-De-Mar]

Jeden tu motá dohromady build time s run time, iný motá dohromady refaktorizáciu s typmi. To je tak všetko, čo som sa dozvedel. Ako vždy na tomto fóre, nič.

Tak si říkám, možná by bylo užitečnější, když by si radil spíše ty nám, ne? Určitě se máme od tebe hodně co naučit.

Áno, preto mali moje kurzy také dobré hodnotenia, preto aj po čase nájdeš komentáre, že som dobrý :*

[mmm]

Takže v Jave budem čítať vstup, čo len z konzoly, a pri pokuse priradiť načítaný string do premennej typu int mi program nespadne na runtime error?

to typescript nedovolí. Musíte nejdřív převést na číslo.

Ale dovolí. Lebo za runtime tam z TS syntaxu neostane ani zmienka. Vo formulári ti užívateľ zadá text miesto čísla a TS ti s tým nijak nepomôže. Len si pletieš buildtime s runtime.

TS rozumí konverzím a assercím. Ví, že výsledek parseInt, Number, parseFloat je číslo. Rozumí testování na NaN. V runtime zmizí pouze anotace specifické pro TS, javascriptové asserce zůstanou. Flow funguje stejně.

[Reklama]

[Tomáš Roll]

Iste. Falzifikácia je vo výsledku to isté, ako verifikácia. A ty si pre mňa zatiaľ iba ďalšia obeť TS hype. Napísať, že TS je riešenie špagety kódu, Flow je nanič a do konca, že TS developer sa ani nemusí učiť JS, to je zbierka takých nezmyslov..

Proč se potom ptáš, když máš předem hotový názor?

[BoneFlute]

TS rozumí konverzím a assercím. Ví, že výsledek parseInt, Number, parseFloat je číslo. Rozumí testování na NaN. V runtime zmizí pouze anotace specifické pro TS, javascriptové asserce zůstanou. Flow funguje stejně.

Jen tě doplním, že TS není z kategorie neprůstřelných. Tudíž si nevynutí (jako Elm), aby byly vstupy monadické, tudíž to nedohlídá.

PS: Tento příspěvek není pro @Wal-De-Mar

[.]

Alebo naopak? Rozlišujem medzi buildtime a runtime a tvrdím, len prijebanci sa môžu za runtime odvolávať na statické typy? Že sú im za runtime na piču a musia si strážiť vstupy rovnako, ručne, prídavnými typovými kontrolami, či už v staticky, či dynamicky typovanom jazyku? Inak im program zhodí / hackne 10 ročné decko? A ešte sa mi iný dement pochváli, že staticky typovaný jazyk je lepší, lebo za  runtime nestráži ani rozsah hodnôt? A??? Šak kontrola ručne navyše aby sa to za behu nestalo, lebo overflow/underflow je najpriamejšia cesta ako kompromitovať apku! Vám to tu ale pekne jebe vy "programátori"

Takhle to dopadá, když se nedostudovanci dají na programování. A pokud máš IT vysokou školu, tak radši nechci ani vědět kterou.

Zkus si v tom svém Javascriptu toto:

Kód: [Vybrat]

> parseInt("10765432100123456789")
a budeš překvapený, co ti vyleze. Přičemž je docela běžné, že se id v JSONu posílají v numerickém formátu. Něříkám, že to je problém, prostě to je takto definováno, ale je zjevné, že o tom vůbec nevíš.

Čo si ty za debila... A čo má parseInt, manuálne sparsovanie hodnoty, spoločné s typmi??? Veď to je to, čo hovorím: že kým si sám, napríklad s parseInt, alebo obdobne sám neustrážim hodnotu na vstupe, tak typový systém už vôbec nie.

Ty sis to do té konzoly nezadal, co? Vyčítáš ostatním jazyků přetečení/podtečení, hážeš na všechny strany sprostá slova, ale sám nic nevíš. Tady máš výsledek a fčil mudruj, ty ...

Kód: [Vybrat]

> parseInt("10765432100123456789")
10765432100123458000
Za domácí úkol dostáváš zjistit, proč tomu tak je, ty chytráku.

[Bacsa]

Takže v Jave budem čítať vstup, čo len z konzoly, a pri pokuse priradiť načítaný string do premennej typu int mi program nespadne na runtime error?

to typescript nedovolí. Musíte nejdřív převést na číslo.

Ale dovolí. Lebo za runtime tam z TS syntaxu neostane ani zmienka. Vo formulári ti užívateľ zadá text miesto čísla a TS ti s tým nijak nepomôže. Len si pletieš buildtime s runtime.

Hoďte na něj někdo deku 

[BoneFlute]

Ale dovolí. Lebo za runtime tam z TS syntaxu neostane ani zmienka. Vo formulári ti užívateľ zadá text miesto čísla a TS ti s tým nijak nepomôže. Len si pletieš buildtime s runtime.

Hoďte na něj někdo deku 

+1

[Bacsa]

Jeden tu motá dohromady build time s run time, iný motá dohromady refaktorizáciu s typmi. To je tak všetko, čo som sa dozvedel. Ako vždy na tomto fóre, nič.

Tak si říkám, možná by bylo užitečnější, když by si radil spíše ty nám, ne? Určitě se máme od tebe hodně co naučit.

Áno, preto mali moje kurzy také dobré hodnotenia, preto aj po čase nájdeš komentáre, že som dobrý :*

Kurzy na popeláře?

[BoneFlute]

Jeden tu motá dohromady build time s run time, iný motá dohromady refaktorizáciu s typmi. To je tak všetko, čo som sa dozvedel. Ako vždy na tomto fóre, nič.

Tak si říkám, možná by bylo užitečnější, když by si radil spíše ty nám, ne? Určitě se máme od tebe hodně co naučit.

Áno, preto mali moje kurzy také dobré hodnotenia, preto aj po čase nájdeš komentáre, že som dobrý :*

Ale já ti to neberu. Jen je mi to tak nějak jedno.

[Wal-De-Mar]

Takže v Jave budem čítať vstup, čo len z konzoly, a pri pokuse priradiť načítaný string do premennej typu int mi program nespadne na runtime error?

to typescript nedovolí. Musíte nejdřív převést na číslo.

Ale dovolí. Lebo za runtime tam z TS syntaxu neostane ani zmienka. Vo formulári ti užívateľ zadá text miesto čísla a TS ti s tým nijak nepomôže. Len si pletieš buildtime s runtime.

TS rozumí konverzím a assercím. Ví, že výsledek parseInt, Number, parseFloat je číslo. Rozumí testování na NaN. V runtime zmizí pouze anotace specifické pro TS, javascriptové asserce zůstanou. Flow funguje stejně.

Hurá, blížime sa k tomu, na čo som pôvodne pýtal. Takže to spresním: majme funkciu v čistom JS:

Kód: [Vybrat]

function naDruhu (num) {
  return num * num
}

Táto funkcia si vôbec nestráži typ a pokiaľ ju niekto zavolá so zle zadaným parametrom z formulára, napríklad v tvare naDruhu('Jožo'), funkcia dá nečakaný výsledok. Použijem teda akože TS a nadefinujem typ:

Kód: [Vybrat]

function naDruhu (num: number) {
  return num * num
}

Nedal som do kódu žiadnu kontrolu, pretypovanie, či parsovanie parametru. Lebo veď som nadefinoval typ parametru a spolieham naň. Že to nie je presný syntax TS nie je dôležité. Dôležité je, na čo sa pýtam, že čo sa udeje pri transpilácii. Lebo pokiaľ sa po transpilácii vyššie uvedená funkcia s typmi jednoducho transpiluje do čistého JS tak, že sa len odstránia definície typov, čiže naspäť do pôvodného tvaru,

Kód: [Vybrat]

function naDruhu (num) {
  return num * num
}

tak mi je TS a celé typy na kokot, akurát tak mám hinty počas písania a kontrolu počas transpilácie, ktorá však nič zlé nezistí, lebo nevie dopredu, či mi užívateľ zadá vo formulári platné číslo. Keby však robila to, čo chcem vedieť či naozaj robí, či definícia typu zároveň zabezpečí, že pri transpilácii sa môj kód rozšíri o kontrolu typu, aby fungoval aj počas behu aplikácie, takže napríklad takto:

Kód: [Vybrat]

// moja definícia
function (num: number) {
  return num * num
}

// po transpilácii napríklad takto,
// ako tu písal iný, s parseInt
function (num) {
  if (!parseInt(num)) throw new Error()
  return num * num
}

Zasa. Nemudrovať nad konkrétnym kódom. Otázka znie: zabezpečí mi definícia typu, že bude kontrolovaná otypovaná premenná aj za behu? Tak, že mi do kódu dopíše nejakú kontrolu? Alebo si takéto parsovanie / pretypovanie / kontrolu na správny typ dodanej za behu, vopred neznámej za návrhu, musím aj tak robiť sám, dopísať do kódu ručne? Sám?

[Tomáš Roll]

Když ti je TS na kokot, tak ho nepoužívej. Je zbytečné házet perly sviním.

[Wal-De-Mar]

Takže v Jave budem čítať vstup, čo len z konzoly, a pri pokuse priradiť načítaný string do premennej typu int mi program nespadne na runtime error?

to typescript nedovolí. Musíte nejdřív převést na číslo.

Ale dovolí. Lebo za runtime tam z TS syntaxu neostane ani zmienka. Vo formulári ti užívateľ zadá text miesto čísla a TS ti s tým nijak nepomôže. Len si pletieš buildtime s runtime.

TS rozumí konverzím a assercím. Ví, že výsledek parseInt, Number, parseFloat je číslo. Rozumí testování na NaN. V runtime zmizí pouze anotace specifické pro TS, javascriptové asserce zůstanou. Flow funguje stejně.

Hurá, blížime sa k tomu, na čo som pôvodne pýtal. Takže to spresním: majme funkciu v čistom JS:

Kód: [Vybrat]

function naDruhu (num) {
  return num * num
}

Táto funkcia si vôbec nestráži typ a pokiaľ ju niekto zavolá so zle zadaným parametrom z formulára, napríklad v tvare naDruhu('Jožo'), funkcia dá nečakaný výsledok. Použijem teda akože TS a nadefinujem typ:

Kód: [Vybrat]

function naDruhu (num: number) {
  return num * num
}

Nedal som do kódu žiadnu kontrolu, pretypovanie, či parsovanie parametru. Lebo veď som nadefinoval typ parametru a spolieham naň. Že to nie je presný syntax TS nie je dôležité. Dôležité je, na čo sa pýtam, že čo sa udeje pri transpilácii. Lebo pokiaľ sa po transpilácii vyššie uvedená funkcia s typmi jednoducho transpiluje do čistého JS tak, že sa len odstránia definície typov, čiže naspäť do pôvodného tvaru,

Kód: [Vybrat]

function naDruhu (num) {
  return num * num
}

tak mi je TS a celé typy na kokot, akurát tak mám hinty počas písania a kontrolu počas transpilácie, ktorá však nič zlé nezistí, lebo nevie dopredu, či mi užívateľ zadá vo formulári platné číslo. Keby však robila to, čo chcem vedieť či naozaj robí, či definícia typu zároveň zabezpečí, že pri transpilácii sa môj kód rozšíri o kontrolu typu, aby fungoval aj počas behu aplikácie, takže napríklad takto:

Kód: [Vybrat]

// moja definícia
function (num: number) {
  return num * num
}

// po transpilácii napríklad takto,
// ako tu písal iný, s parseInt
function (num) {
  if (!parseInt(num)) throw new Error()
  return num * num
}

Zasa. Nemudrovať nad konkrétnym kódom. Otázka znie: zabezpečí mi definícia typu, že bude kontrolovaná otypovaná premenná aj za behu? Tak, že mi do kódu dopíše nejakú kontrolu? Alebo si takéto parsovanie / pretypovanie / kontrolu na správny typ dodanej za behu, vopred neznámej za návrhu, musím aj tak robiť / dopísať do kódu ručne? Sám?