Autor | Zpráva | ||
---|---|---|---|
Radek9 Profil |
#1 · Zasláno: 22. 10. 2013, 22:26:02
preca1:
Předpokládám, že nikdo nebude šahat na už vytvořené vlastnosti globálních objektů. Jde mi o to, že kdyby někdo v tom objektu ext předefinoval hasOwnProperty , tak by to nefungovalo správně.
„Jak řešíš, že někdo může přepsat isNaN ?“
Jestli myslíš isNaN na globálním objektu, tak to vůbec nepoužívám. Používám Number.isNaN (s polyfilem pro starší prohlížeče), které pracuje pouze s čísly.
|
||
preca1 Profil |
#2 · Zasláno: 23. 10. 2013, 06:56:59
Radek9:
„Jde mi o to, že kdyby někdo v tom objektu ext předefinoval hasOwnProperty...“ Dík. Tobě se to někdy stalo? Dokážu si představit, že pokud píšeš vlastní knihovnu, kterou může používat kdokoli, tenhle problém vzniká. Ale pokud používáš uzavřenou sadu kódu, tak to neni potřeba, ne? Tudíž bych vždycky používal instanční metodu a jen ve speciálních případech (píšu vlastní knihovnu, používam špatně napsanej kód) bych používal statickou metodu. |
||
Radek9 Profil |
#3 · Zasláno: 23. 10. 2013, 14:13:45
preca1:
V uzavřeném kódu se mi to skutečně nestalo. Ale jsem zastáncem toho, že na prototypu Object u by nemělo být vůbec nic. Proto jsem si celkem navykl používat toto:
var ObjectProto = Object.prototype, hasOwn = ObjectProto.hasOwnProperty; Object.owns = function (obj, prop) { return hasOwn.call(obj, prop); }; Stejně jako Object.clone , Object.defineProperty atd., tak i tato funkce mi logicky sedí ven na Object .
|
||
Chamurappi Profil |
#4 · Zasláno: 23. 10. 2013, 14:29:52
Reaguji na Radka9:
„kdyby někdo v tom objektu ext předefinoval hasOwnProperty , tak by to nefungovalo správně“
1) Co by tím ten někdo získal? 2) Pokud tím skutečně něco získat chce, není pravděpodobné, že mu to tímhle zmaříš? „na prototypu Object u by nemělo být vůbec nic“
To je skoro i nutnost, hodně věcí se tím může rozbít. Sám do svých for -in smyček běžně hasOwnProperty nepíšu a pokud mi někdo vylepší Object.prototype , je to jeho chyba.
„Používám Number.isNaN (s polyfilem pro starší prohlížeče), které pracuje pouze s čísly.“
V čem je to lepší? Oba isNaN y musí kontrolovat typ, pro čísla by měly být stejně rychlé a o datovém typu proměnné stejně asi většinou máš jasno. Takže jediné, co získáš, je zpomalení v nepodporujících prohlížečích.
|
||
Radek9 Profil |
#5 · Zasláno: 23. 10. 2013, 16:08:43
Chamurappi:
> 1) Co by tím ten někdo získal? > 2) Pokud tím skutečně něco získat chce, není pravděpodobné, že mu to tímhle zmaříš? Jak říkám, asi taková situace nikdy nenastane, takže jsem ani nepřemýšlel o důvodech, které by k tomu někdo měl. Nicméně z toho principu, že by prototyp Object u měl být prázdný, to prostě nechávám přímo na Object u.
„To je skoro i nutnost, hodně věcí se tím může rozbít.“ Mně ani tak nejde o položky, které by si tam přidal uživatel (ve for-in by je navíc mohl skrýt pomocí Object.defineProperty , což také považuji za jednu z absurdit JS). Jde mi spíš o to, že by logicky měl být potomek Object u úplně prázdný primitivní objekt. Přitom má v základu metody jako hasOwnProperty , propertyIsEnumerable , isPrototypeOf . Jediné, které jakž takž chápu, jsou toString a valueOf , ale navrhovat JS, tak to asi taky řeším trošku jinak.
„pro čísla by měly být stejně rychlé“ Jelikož ten globální převádí ostatní datové typy na číslo, bude o pár mikrosekund pomalejší. :-) |
||
Časová prodleva: 10 let
|
0