ugrás a tartalomhoz

Problémás JavaScript fejlesztői interjú kérdések

Poetro · 2013. Dec. 17. (K), 01.41

Már több mint negyed éve interjúztatok JavaScript fejlesztői állásra, és észrevettem, hogy a mi kérdéssorunkból mire tudják a legkevesebben a választ, illetve mire adnak rendszeresen hibás választ. Ezeket a kérdéseket és válaszokat próbáltam összegyűjteni, hátha mások tanulni tudnak belőle.

Hogyan működik az öröklődés JavaScriptben?

A JavaScriptben prototípusos (prototypal) öröklődés van, ami azt jelenti, hogy egy osztály a prototípusától örökli a tulajdonságait. A prototípusa pedig szintén örökölhet tulajdonságokat a saját prototípusától, így jön létre a prototípus lánc (prototype chain). A prototípus lánc azt jelenti, hogy amikor a objektum egy tulajdonságát kérdezzük le, akkor a JavaScript motor előbb megnézi, hogy az definiálva van-e magán az objektumon, majd annak prototípusán, majd a prototípus prototípusán stb. Ha megtalálja, akkor visszadja, ha nem, akkor undefined értéket ad vissza vagy ReferenceError hibát dob.

Milyen értéket kap egy változó alapértelmezetten?

undefined.

Mi a különbség a null és az undefined között?

Az undefined azt jelenti, hogy a változó még nem kapott értéket vagy nem is lett definiálva. A null azt jelenti, hogy a változó létezik, és a fejlesztő szándékosan jelezni akarja, hogy a változónak nincsen értéke.

Hogyan adódnak át a paraméterek a függvénynek?

A primitív típusok (number, string, boolean, undefined, null) érték szerint, az objektumok (azaz minden más) pedig referencia szerint.

Hogyan működik az események propagálása (terjesztése)?

Az események terjesztésének két fázisa van (egyes elméletek szerint három), lefutási sorrendben: az elfogási fázis (capture phase)[, a célpont fázis (target phase)] és a buborékolás fázis (bubbling phase). A capture phase-ben az esemény a dokumentum tetejétől, külsejétől indul, és jut el végül a célponthoz. A bubbling phase során pedig az esemény a célponttól elindul és fölfele végigfut az összes szülő elemen.

Milyen pozicionálás (position) értékek léteznek a CSS-ben és hogyan működnek?

static
Az elem része a dokumentum folyamnak (document flow), nem számít pozicionáltnak.
relative
Az elem része a dokumentum folyamnak, helyzete relatív az eredetileg elfoglalt pozíciójához képest.
absolute
Az elem nem része a dokumentum folyamnak, helyzete relatív a legközelebbi pozicionált elem pozíciójához képest.
fixed
Az elem nem része a dokumentum folyamnak, helyzete relatív a nézetablakhoz (viewport) képest, nyomtatás esetén minden egyes lapon.
 
1

legközelebbi

Nagy Gusztáv · 2013. Dec. 17. (K), 07.40
absolute
Az elem nem része a dokumentum folyamnak, helyzete relatív a legközelebbi pozicionált elem pozíciójához képest.


A "legközelebbi" szó így talán félreérthető. Annyiban pontosítanám, hogy a szülői láncban a legközelebbi pozicionált szülőről van szó.
2

igaz

Poetro · 2013. Dec. 17. (K), 09.15
Elnézést, kicsit pontatlan voltam, köszönöm a pontosítást.
3

ráadásul

zzrek · 2013. Dec. 17. (K), 09.18
Ráadásul csak akkor függ a hely az offsetParent-től, ha megadjuk, mert ha a pozíció nem definiált, akkor az elem helyzete a dokumentumfolyamtól függ.
4

Szia, És amúgy miért

virág · 2013. Dec. 17. (K), 10.41
Szia,

És amúgy miért kérdezel ilyeneket interjún? Mindig kíváncsi voltama arra, hogy ez mire jó. Szerintem semmit nem mér fel, abszolút semmit. Erre egyébként ha jól tudom már az olyan nagyobbacska vállalatok mint a Google is rájöttek, ha jól tudom nyáron volt hír, hogy a marketing szempontból marhára jól mutató, hiper-szuper nehéz tesztjeik az ég világon semmit nem érnek. Bárhogyan is, szerintem az ilyen kérdezgetés és a gyors tesztek maximum arra jók, hogy az interjúztatók kiélhessák egy kicsit a felsőbbrendűségi érzéseiket és utána ezt publikálják is pl. egy ilyen blogban. Hogy miért nem ér semmit? Sok ember izgulós, sok ember leblokkol ha kérdezik, vagy csak simán nem jut eszébe. valószínű, hogy az interjúztatónak is lehet olyan kérdéseket feltenni amire nem tudna válaszolni... A kicsit hosszabb lélegzetvételű teszt feladatok és elsősorban a próbamunka, amit odahaza, nyugodtan megcsinálhat valaki, ezerszer többet elárulnak a pályázó tudádásáról és kódolási szokásairól, mint az ilyen kérdések.

Na persze, mindenki azt csinál amit akar, ez csak a személyes véleményem, lassan 15 éve dolgozok ezen a területen és bennem ez a vélemény alakult ki. :)
5

A Google-nél más jellegű

Hidvégi Gábor · 2013. Dec. 17. (K), 11.40
A Google-nél más jellegű kérdéseket tettek fel, a Poetro által felsoroltak az alaptudás részei, amit – szerintem – a legszebb, kéjvágyó selőkkel teli álmunkból felverve is tudnunk kell. A felvételi egy stresszhelyzet, ha ott nem tud az illető jól válaszolni, vagy esetleg a rávezetésre sem tud reagálni, akkor valós körülmények között is van rá esély (leadás előtti héten), hogy rosszul fog teljesíteni.
6

Egyetértek, aki ezekkel sincs

bamegakapa · 2013. Dec. 17. (K), 12.04
Egyetértek, aki ezekkel sincs tisztában, az ne jelentkezzen Javascript fejlesztőnek, mert nyilvánvalóan nem tudja ellátni a feladatát. Pont.

Egyik sem mondható nehéznek vagy trükkösnek Poetro kérdései közül. Ezek egyszerűen az alapok.
40

Én nem biztos

vbence · 2013. Dec. 18. (Sze), 11.05
... hogy fel tudnám sorolni a 4 értéket, de erre van a referencia.
41

Szerintem fel tudnád

bamegakapa · 2013. Dec. 18. (Sze), 11.34
Szerintem fel tudnád :).

Persze ha akár név nélkül tudod, hogy van 4 ami ezt meg azt csinálja, akkor adott problémával szembesülve be fog ugrani, hogy az egyik position érték itt jó lehet. Ilyenkor segíthet a referencia.

Saját tapasztalat szerint ha napi szinten sitebuildel vagy uit programoz az ember, normális esetben gyorsan rögzülnek ezek, mert sokszor jönnek jól.
7

Alapok

Poetro · 2013. Dec. 17. (K), 12.45
És amúgy miért kérdezel ilyeneket interjún?

Azért, mert szeretném tudni, hogy a jelentkező tisztában van-e az alapokkal, amiket munkája során minden nap használnia kell. Ha ezeket az alapvető koncepciókat rávezetés után sem tudja megválaszolni, kifejteni, akkor nem fogja tudni jól, vagy egyáltalán végezni a munkáját.
hiper-szuper nehéz tesztjeik az ég világon semmit nem érnek

Ez nem hiper-szuper nehéz, egyszerűen az alapokat fedi le.
Arra nem vagyok kíváncsi, ki mennyire ért a jQuery-hez, lévén a munkája során nem fog jQuery-t használni. A nyelv, a DOM és a CSS alapjaira vagyok kíváncsi, ugyanis az fogja használni, egy olyan keretrendszerrel, amit valószínűleg még soha nem használt, és ami többek között ezekre az alapokra épül.
Sok ember izgulós, sok ember leblokkol ha kérdezik, vagy csak simán nem jut eszébe

Az ember munkája során nap mint nap stresszhelyzetbe kerül, különböző okok miatt, és ha a telefonos beszélgetés alatt, amikor általa ismerős környezetben van, nem tudja az alapokat sem, az nem túl jó fényt vet az folytatásra.
próbamunka, amit odahaza, nyugodtan megcsinálhat valaki, ezerszer többet elárulnak a pályázó tudádásáról és kódolási szokásairól

Igen, szoktunk ilyet is kérni, illetve amennyiben van publikus kódja, akkor azt nézzük meg, nem terheljük a jelentkezőt még egy próbafeladat megoldásával, mivel a már elkészült kódja alapján általában meg tudjuk állapítani, hogy egyáltalán érdemes-e behívni / felhívni interjúra.

Természetesen, hat tudsz valami ennél jobb módszert arra, hogy heti 4-5 embert tudjon egy fejlesztő interjúztatni, és közben elvégezze a munkáját is, akkor arról szívesen hallanék egy leírást.
33

Természetesen az interjúztató

BlaZe · 2013. Dec. 18. (Sze), 01.27
Természetesen az interjúztató sem tud mindent, tőle is lehet olyat kérdezni, amit nem tud :) Sőt, ha ketten megyünk akár ugyanabból a csapatból interjúztatni, akkor azt azért tesszük, mert egyikünk egyik, másikunk egy másik területen tudja jobban felmérni a jelölt tudását.

Ezek a kérdések nem is arra valók, hogy az interjúztató a felsőbbrendűségi érzését kiélhesse. Nálunk ez úgy megy, hogy minden jelölttel adnak egy pozíció leírást is, és azzal kapcsolatos kérdéseket kell feltenni. Meg persze általánosakat is. Átfedés mindig van. Vannak kérdések, amik a jelölt számára öncélúnak tűnnek, és valószínűleg azokról a kérdésekről gondolják ezt, amikre nem tudják a választ. Hisz ha valamire nem tudod a választ, nem is tudod miért kérdezik. Pár kérdéssel ki lehet deríteni valakiről, hogy bizonyos dolgokról, amik szerepelnek pl a cv-jében, milyen mély ismeretekkel rendelkezik. Ha pl beírja, hogy dolgozott x technológiával 2 évig, és azzal kapcsolatban felteszel egy kérdést, hamar kiderül, hogy csak használta, vagy vette a fáradtságot arra is, hogy utánamenjen, hogy mi az, amit használ, és miért. Ha nem ment utána, annak értelemszerűen komoly üzenete van. Ha ez csak 1-2 a cv-jében lévő technológiára igaz, akkor rá lehet fogni, hogy csak érintőlegesen használta. De ha pár technológiára van felfűzve az egész cv, akkor ott kilóg a lóláb, ha nem vágja. Pl volt, hogy valaki azt állította, hogy ismeri a springet. Amikor megkérdeztük, hogy milyen bean scope-okat ismer, akkor azt már nem tudta, pedig ez nem egy eldugott dolog benne... Interjúról kifelé jövet megbeszéltük a kollégával, hogy milyen szimpatikus srác, értelmesnek is tűnik, de sajnos nem tudtuk még biztonsággal felvételre ajánlani. A springes kérdéshez hasonló ez a js öröklődés dolog is. Ha erre a kérdésre nem kerül szóba a prototype akár válasz, akár visszakérdezés formájában, akkor az egy erős felkiáltójel az interjúztatónak.

Fontos még megemlíteni, hogy egy interjún nem kell mindenre tudni a választ. Sőt. Jelöltként én kimondottan azokat az interjúkat szeretem, ahol tudnak olyat kérdezni, amire nem tudom a választ, vagy nagyon el kell gondolkodnom. Ez egy jele annak, hogy jó helyen vagy, és tanulni fogsz, ha megállapodtok. És fordítva is fontos, interjúztatóként is kell tudd azt az érzést kelteni, hogy itt nálatok lehet tanulni, ergo érdemes elfogadja majd az ajánlatotokat. A dolog tehát az arányokon múlik, és persze hogy mire nem tudja a jelölt a választ.

Én jelöltként nagyon utáltam az olyan interjúkat, ahol csak egy igen/nem válasz jött. Abból számomra semmi nem derül ki (kivéve, amit én közben le tudtam mérni). Én nagyon értékeltem mindig az olyan interjúztatókat, akik azt mondták, hogy ezt jól tudtad, de ezek azok a területek, ahol még tanulnod kell, hogy a jövőbeli karriercélodat elérd. Szerintem ez korrekt. Bár tény, hogy kevesen mernek ilyen feedbacket adni, mert veszélyes. Nem mindenki szereti, és nem mindenki tolerálja.

És Pepitával egyetértve, szerintem jó dolog, hogy van ilyen bejegyzés a leggyakoribb interjú hibákról. Bár js területen nincs tapasztalatom, de javaban is megvannak ugyanezek a kérdések: ott főként collection és multithread területen megy a szétlövés. A kettő kombinációja meg aztán végképp magic.

Na de hogy olvasnivaló is legyen, interjú témában egy szerintem nagyon érdekes poszt Verhás Pétertől.

Illetve a java interjúk iránt érdeklődőknek egy angol nyelvű blog, ahol tematikusan össze vannak gyűjtve gyakran feltett kérdések: javarevisited
8

Annyi fűznék hozzá, hogy

anti81 · 2013. Dec. 17. (K), 13.19
Annyi fűznék hozzá, hogy interjúztatóként érdemes odafigyelni arra, hogy amit kérdezek mennyire van összhangban azzal, ahogy az alany értelmezi a kérdésem.
A buktatónak minősülő kérdéseket igyekszem többféle módon megfogalmazni, amennyiben lehetséges.

Például ha egy "Milyen értéket kap egy változó alapértelmezetten?" kérdésre többször is olyan szintű választ kapok, hogy "amilyet adok neki" vagy "semmilyet", akkor megkérdezem, hogy "Egy var-ral bevezetett p változóra typeof függvényt hívok, mit kapok eredményül?". Ezt már nem lehet félreérteni.
9

valóban

zzrek · 2013. Dec. 17. (K), 14.37
A "Hogyan adódnak át a paraméterek a függvénynek?" kérdésen nekem is el kellett gondolkodnom, hogy most mi is a kérdés. Nem jutott eszembe, hogy az érték-mutató kettősségre akar rákérdezni.
A "Hogyan működik az öröklődés JavaScriptben?" kérdésben pedig az a nehéz, hogy hogyan mondjak ne túl sokat és ne intézzem el mégis két szóval -- vagyis nehéz megítélni itt is, hogy milyen részletességgel kéri a kérdező.
A "Milyen értéket kap egy változó alapértelmezetten?" pedig lehet erősködni, hogy mondjuk a function zuzu(){} hatására is létrejön egy alapértelmezett változó, mégsem undefined.
Az utolsó kérdés pedig nem is JS.

Nyilván ez csak szőrszálhasogatás :-)

(egyébként a typeof az nem fv)
10

Imho ha valaki kommunikálni

inf3rno · 2013. Dec. 17. (K), 16.53
Imho ha valaki kommunikálni akar, akkor olyan kérdéseket tesz fel, amik elősegítik a kommunikációt. Ezek a kérdések ilyen szempontból inkább akadályként viselkednek, mert azon kell agyalni szinte mindegyiknél, hogy vajon mire gondoltál, milyen választ vársz. Szinte mindegyik elméleti fejtegetés, aminek nem sok köze van a gyakorlathoz. Ezek után egyáltalán nem csoda, hogy sokan ezeken a kérdéseken véreznek el. Jelen esetben teljes mértékben egyetértek virággal.

Hogyan működik az öröklődés JavaScriptben?

Az attól függ, hogy melyik öröklési modelt követed. http://davidshariff.com/blog/javascript-inheritance-patterns/ De ez meg olyan dolog, hogy nekem is google-zni kellett párat, hogy megtaláljam a megfelelő szakszavakat "inheritance pattern", mert olyan régen foglalkoztam a témával. Sokkal relevánsabb lenne, hogy mi az, hogy polimorfizmus, milyen két implementálási módja van (inheritance, composition), melyiket érdemesebb használni (composition over inheritance) és miért (sokan eltúlozzák az öröklődést, kompozit osztályokat meg alig használnak), mutass rá egy példát js-ben bármilyen keretrendszerrel. Az öröklődést úgyis a keretrendszer fogja megoldani helyettünk... Nem baj, ha ezek közül nem mindre tud válaszolni, ha hajlandó tanulni...

Milyen értéket kap egy változó alapértelmezetten?

Sokkal konkrétabb lenne rákérdezni, hogy mi az, hogy ha kiírod egy változó értékét a konzolba (mi az, hogy konzol?), akkor mit jelent az, hogy undefined, null, végtelen ciklus a kirajzolás során, stb...? Egyáltalán hogyan lehet debuggolni egy kódot, érdemes e kivételeket dobni, vagy null-al visszatérni, stb... Ezek vitatott kérdések (bizonyos körökben), de gondolom van rá saját irányelvetek, amit mindenkitől megköveteltek.

Hogyan működik az események propagálása (terjesztése)?

Mi az, hogy cancelBubble és stopPropagation? Esetleg felhozol egy példát, ezzel kapcsolatban, és megkérded mi fog történni, vagy hogy hogyan valósítaná meg az illető, stb...
11

Szinte mindegyik elméleti

Hidvégi Gábor · 2013. Dec. 17. (K), 17.53
Szinte mindegyik elméleti fejtegetés, aminek nem sok köze van a gyakorlathoz.
A jó munkához jó elméleti alapok kellenek, a fenti kérdésekkel pedig ezt jól fel lehet mérni. Szerintem nem gond, hogy a kérdések általánosak, mert így a delikvens szépen kifejtheti, ami a fejében van, meg lehet tudni, hogyan gondolkodik, mit tart fontosnak. Nem az a lényeg, hogy konkrét kérdésekre adjon konkrét válaszokat, hanem az, mennyire látja át a dolgokat, és egy ilyen beszélgetés megindítására a fenti kérdések nagyon jók.

Gyakorlati hasznuk is van a kérdéseknek, mert a referencia szerinti átadás nagyon hasznos dolog, én például sokáig nem voltam vele tisztában, emiatt egy csomó fölösleges kört futottam bizonyos helyeken.

Az attól függ, hogy melyik öröklési modelt követed.
JS-ben egyféle öröklés van, ne keverd ide azt, hogy mások miket szeretnének behozni más nyelvekből.
12

JS-ben egyféle öröklés van,

inf3rno · 2013. Dec. 17. (K), 18.06
JS-ben egyféle öröklés van, ne keverd ide azt, hogy mások miket szeretnének behozni más nyelvekből.

Ez mese. Eleve nincs is öröklődés js-ben by default, ha lenne, akkor nem lenne csak a reserved words-ben az extends és a super, hanem használva is lenne. Ez a prototípus alapú bűvészkedés csak egy a lehetséges megvalósítások közül.

és egy ilyen beszélgetés megindítására a fenti kérdések nagyon jók

Pont azt mutattam meg az előbb, hogy az ilyen kérdések beszélgetés elindítására teljesen alkalmatlanok, nem támogatják a kommunikációt, hanem gátolják. Csak annyit lehet felmérni velük, hogy az illető, akit kérdezünk ugyanúgy gondolkodik e, mint mi, vagy teljesen máshogy. Ohh ezen kívül még valamire jók, ha visszakérdez, akkor jók a kommunikációs képességei, ha meg nem, hanem elkezd agyalni, hogy vajon mire gondolsz, akkor meg inkább olyan típus, aki mindent maga próbál megoldani.
14

Ha a "by default" úgy van

bamegakapa · 2013. Dec. 17. (K), 18.33
Ha a "by default" úgy van értve, hogy a kezdetek kezdete óta, akkor bizonyos szemszögből igazad van (a függvényekkel és azok prototype-jával való játék valóban a bűvészkedés kategória, amibe már sokmindent beleerőltettek).

Az Object.create() viszont szerintem egyértelműsítette ezt a helyzetet, és így már van (prototípusos) öröklődés JS-ben bűvészkedés nélkül.
19

Az Object.create() viszont

inf3rno · 2013. Dec. 17. (K), 19.40
Az Object.create() viszont szerintem egyértelműsítette ezt a helyzetet, és így már van (prototípusos) öröklődés JS-ben bűvészkedés nélkül.


Az Object.create() csak egy egyszerű függvény, ami megkönnyíti a prototípusos öröklődést, semmi több.

Ez az egész dolog már ott elhalt, hogy js-ben nincsenek osztályok és metódusok, azok nélkül meg nem lehet öröklődésről beszélni. Ugyanígy nincsenek interface-ek, azok nélkül meg nincs sok értelme polimorfizmusról beszélni. Tudjuk imitálni ezeket a dolgokat a js-ben elérhető eszközökkel, de nem lehet azt kijelenteni, hogy egyik vagy másik út (pl a prototípusos öröklődési minta) kizárólagos. Ez olyan, mintha a vizsgáztató megkérdezné, hogy hogyan tárolsz fát adatbázisban, és ha nem a nested set-ről kezdenél beszélni, hanem az adjacency list model-ről, akkor megbuktál, mert bocs, én nem erre gondoltam... :D

Mondjuk így végiggondolva a helyes válasz erre:
Hogyan működik az öröklődés JavaScriptben?

az, hogy sehogy, nincs öröklődés javascriptben, vannak öröklődési minták, amikkel öröklődést lehet imitálni.

off:
Szerintem az már régen rossz, ha egy kérdés a vizsgáztató beszűkült látásmódját bizonyítja, nem pedig arról szól, hogy a vizsgáztató megpróbáljon minél többet kihozni a vizsgázóból. Persze ezt lehet úgy magyarázni, hogy hát ha valaki nem bírja vizsgán a stresszhelyzetet, akkor majd a határidő csúszásakor sem fogja bírni, de ez elég sokat elárul az adott cégről is. Csak néhány példamondat erre:
  • mindenkinek ki kell találni, hogy mire gondol a főnök, ha erre képtelen, akkor nincs helye a cégnél
  • nem segítjük egymást, hanem inkább akadályokat gördítünk mások elé, és ha valaki így nem boldogul, akkor nincs helye a cégnél
  • aki nem bírja a határidő csúszásával járó stresszt, és a napi 10+ óra munkát, ami ezzel jár, annak sincs helye a cégnél

azt hiszem érezni az iróniát...
22

Azt hiszem egy nagyon fontos dolgot

Pepita · 2013. Dec. 17. (K), 21.49
végig kifelejtettél:
Poetro mindenképp szóban teszi fel ezeket a kérdéseket, vagy személyesen, vagy telón. Tehát bármikor ott az alkalom a pontosításra, visszakérdezésre, stb.
Azt hiszem - ha "beérik" -, komolyabban is válaszolok, eddig úgy tűnik, egy dolgot csak én vettem észre.
25

Köszönöm a kiegészítést.

inf3rno · 2013. Dec. 17. (K), 22.00
Köszönöm a kiegészítést.
28

Nem értem, miért ne lehetne

bamegakapa · 2013. Dec. 17. (K), 22.27
Nem értem, miért ne lehetne osztályok nélkül öröklödésről beszélni, meg hogy akkor a prototípusos öröklődés mi is a Javascriptben, ha nem öröklődés. Ha valami elméleti hiányosságom van, szívesen tanulok újat.
31

+1

zzrek · 2013. Dec. 17. (K), 23.48
+1
34

Még egy apróság

bamegakapa · 2013. Dec. 18. (Sze), 01.59
Egy egyszerű példával érzékeltethető, hogy a prototípusos öröklődés mégiscsak natív, by default dolog a Javascriptben:
/* 
[] azaz new Array() - örököl az Array.prototype objektumtól
a-nak máris van egy rakás jópofa metódusa, pl. join
*/
var a = [];

/*
felülírjuk a joint
Array.prototype.join érintetlen, a-nak van saját
*/
a.join = 1;
console.log(a.join); //1

/*
aztán töröljük a-ról a join-t
és mégis van neki, a prototípusláncon keresztül
*/
delete a.join;
console.log(a.join); //function join() { [native code] }
Mi ez, ha nem öröklődés? Nem mondom, hogy Javascriptben alapból a legszofisztikáltabb nyelvi elemek és más eszközök állnak rendelkezésre a különféle hagyományos objektumorientált programozási technikák minél széleskörűbb kiaknázásához, de azért ezt csak öröklődésnek lehet nevezni.
42

Én abból indultam ki, hogy

inf3rno · 2013. Dec. 18. (Sze), 15.09
Én abból indultam ki, hogy öröklődés osztályok között van, js-ben pedig nincsenek osztályok. Nem véletlen öröklődési mintáknak hívják ezeket a jelenségeket, és nem öröklődésnek. Én legalábbis így gondolom, de ha bebizonyítod az ellenkezőjét, akkor szívesen elhiszem.

Btw a lényegen ez nem változtat, továbbra sem tartom jó ötletnek elméleti kérdésekkel zaklatni a vizsgázót gyakorlati kérdések helyett, de ez valószínűleg az én beállítottságomtól függ.

Helyesbítek, úgy gondolom, hogy vannak állások, amikhez magas szintű elméleti tudás szükséges, de egy js fejlesztői állás nem ilyen, ahhoz inkább gyakorlati tudás kell. Azt, hogy valakinek milyen gyakorlati tudása van, le lehet mérni az általa készített kódból, esetleg néhány egyszerű teszt feladatból, amiknél szóban el tudja mondani, hogy hogyan oldaná meg őket.
46

És ha lesznek?

Poetro · 2013. Dec. 18. (Sze), 17.07
És ha lesznek osztályok, akkor megváltozik a véleményed? Azok továbbra is prototype alapon fognak működni, csak a class és az extends el fogja fedni.

Ráadásul ez az JavaScript fejlesztői álláshoz elég magas szintű elméleti tudásra van szükség, egyrészt azért, mert senior pozícióra keresünk embert, másrészt azért mert nagyon komplex az alkalmazás kliens oldala.
48

Piros fény

Hidvégi Gábor · 2013. Dec. 18. (Sze), 17.57
nagyon komplex az alkalmazás kliens oldala
Mivel egyszerűbb már nem lesz, a legjobban jártok, ha kidobjátok, és a tapasztalataitokat felhasználva teljesen újraírjátok, különben interjúztathatsz az életed hátralevő részében, ami nem feltétlenül a legtermelékenyebb tevékenység.
49

Miért?

Poetro · 2013. Dec. 18. (Sze), 18.31
És ha újraírjuk, attól mitől lesz kevésbé komplex? Komplex feladatot valósítunk meg ezért az alkalmazás komplex. Ha te mondjuk egy Word szintű szövegszerkesztőt írsz, attól még nem lesz kevésbé komplex, ha újra megírod. Mi egy igencsak összetett kliens oldali single page alkalmazást írunk, amihez hasonló nem igazán létezik a piacon, vagy legalábbis én még nem találkoztam ilyennel.
50

Ez a tapasztalatom. Én is

Hidvégi Gábor · 2013. Dec. 18. (Sze), 19.46
Ez a tapasztalatom. Én is single page alkalmazáson dolgozom most már évek óta (frontend, backend), ami mindkét oldalon újra lett írva, és minden szempontból (méret, sebesség, karbantarthatóság stb.) jobb kód született, mert működés közben derült ki sokminden, amire pl. nem gondoltunk, nem gondolhattunk korábban.
54

+1, ha bonyolult a feladat,

inf3rno · 2013. Dec. 18. (Sze), 23.24
+1, ha bonyolult a feladat, akkor bonyolult lesz a kód is.

Egyébként sok dolog van, ami miatt feleslegesen túl komplex lesz egy kliens oldali alkalmazás. Az egyik elterjedt ilyen minta, hogy vastag klienst használtok, és a business logic-ot nem csak szerver, hanem kliens oldalon is implementáljátok. Egy másik minta az overengineering vagy a nem megfelelő irányból (alacsony absztrakciós szintről magasabb felé haladva) elkezdett fejlesztés, ezeket viszont TDD használatával el lehet kerülni. Aztán pl js specifikus, hogyha valaki nem használ require.js-t, akkor nem szokta szétdarabolni kis modulokra a kódját, mert fél, hogy túl lassú lesz a végeredmény, és így tovább... Láttam már 7x-es öröklést is kint a vadvilágban a maga természetességében... :D

Nem hiszem, hogy ezek miatt kukába kellene dobni egy amúgy jól megírt kódot, inkább el kell gondolkodni azon, hogy hol hibáztunk, levonni a konklúziót, és a megfelelő eszközökkel kijavítani a hibát. Ha menthetetlen a kód, túl sok helyen bele kéne nyúlni, csak akkor érdemes újraírni az egészet jobban átgondolva.
63

Az egyik elterjedt ilyen

Poetro · 2013. Dec. 19. (Cs), 10.24
Az egyik elterjedt ilyen minta, hogy vastag klienst használtok, és a business logic-ot nem csak szerver, hanem kliens oldalon is implementáljátok.

Igen, mi egy vastag klienst implementálunk, és a szerver mindent kiszámol, ami a megjelenítéshez szükséges, de a teljes megjelenítés, és annak logikája kliens oldalon számítódik ki. Ha valaki kíváncsi, pár kereséssel megtudhatja, milyen termékről van szó.
Aztán pl js specifikus, hogyha valaki nem használ require.js-t, akkor nem szokta szétdarabolni kis modulokra a kódját, mert fél, hogy túl lassú lesz a végeredmény

Mi nem használunk require.js-t, hanem teljesen más technológiát használunk, és nem is a JS kód, ami sokszor lassú, hanem a böngésző saját API-jai. Rengeteg kisebb modulra van a kód feldarabolva, több száz "osztályról" van szó.
70

Próbáltam megtalálni milyen

SecretName · 2013. Dec. 20. (P), 09.26
Próbáltam megtalálni milyen termékről van szó, de nem találtam.
72

Keresés

Poetro · 2013. Dec. 20. (P), 11.16
Gondoltam rákeresel az itteni nevemre, megtudod a valódit, arra rákeresve meg kiderül, hogy hol dolgozom, onnan meg megvan a termék.
122

Igen, mi egy vastag klienst

inf3rno · 2013. Dec. 24. (K), 15.59
Igen, mi egy vastag klienst implementálunk, és a szerver mindent kiszámol, ami a megjelenítéshez szükséges, de a teljes megjelenítés, és annak logikája kliens oldalon számítódik ki. Ha valaki kíváncsi, pár kereséssel megtudhatja, milyen termékről van szó.


A vastag klienst úgy értettem, hogy a kliens szorosan van csatolva az alkalmazáshoz, és nem is futhatna más jellegű alkalmazással. Majd egy cikkben ezt ki fogom fejteni kicsit jobban, most nem szeretnék részletekbe menni. A lényeg, hogy a kliens oldalon nem jó gyakorlat a szerver oldali kódot duplikálni, mert minden kód duplikáció rontja az alkalmazás karbantarthatóságát, és emellett még feleslegesen bonyolítja a kliens oldali kódot.
126

Igen

Poetro · 2013. Dec. 24. (K), 20.06
A vastag klienst úgy értettem, hogy a kliens szorosan van csatolva az alkalmazáshoz, és nem is futhatna más jellegű alkalmazással.

Ez így van, mivel az egyik szolgálja ki az adatot, a másik meg megjeleníti. A kettő két különböző dolgot valósít meg, de attól még a csatolás szoros.
A lényeg, hogy a kliens oldalon nem jó gyakorlat a szerver oldali kódot duplikálni, mert minden kód duplikáció rontja az alkalmazás karbantarthatóságát, és emellett még feleslegesen bonyolítja a kliens oldali kódot.

A szerver oldali kód nincs duplikálva, mert más dolgot valósít meg az egyik, és mást a másik, de ettől még a kliens bonyolult, ahogy a szerver oldal is, csak más bonyolult az egyikben, mint a másikban.
127

Hát a szoros csatolás miatt

inf3rno · 2013. Dec. 24. (K), 20.13
Hát a szoros csatolás miatt előfordulhat a kód duplikálás, de ha nem is duplikáljátok a kódot, akkor is ismernie kell a kliensnek valamilyen szinten az alkalmazás logikát ahhoz, hogy működni tudjon. Laza csatolással sokkal egyszerűbb klienseket lehet írni. Dolgozom egy prototípuson ezzel kapcsolatban, ha készen lesz, akkor mindenképp lesz itt cikk róla...
71

Bocs, de ekkora ökörségeket

SecretName · 2013. Dec. 20. (P), 09.27
Bocs, de ekkora ökörségeket már rég olvastam.. ha egyáltalán jól értelmeztem.:)

.. egyrészt a "require.js" nem csodaszer, van vagy 100 másik megoldás, de lehet írni sajátot is.. vagy megoldani másként.
.. aki ilyen moduláris rendszerben nyomja ki a js fájlokat, annak továbbképzésre van szükség, mert az egyik legrosszabb megoldás.. mind js alapon, mind szerver oldalon
sokkal jobb megoldások vannak rá.
.. annak, hogy 7x öröklődés van egy javascript kódban semmi köze, se a kód, se az "alkalmazás" minőségéhez, se a gyorsaságához.. tehát egyáltalán nem vad, vagy hibás dolog, ha nem csak 1x az öröklődés.
73

Lassan a testtel

Hidvégi Gábor · 2013. Dec. 20. (P), 14.52
Bocs, de ekkora ökörségeket már rég olvastam
Kicsit visszavehetnél magadból, mert inf3rno már letett valamit az asztalra a weblaboron, de te még nem sokat, ráadásul nem ez az első agresszív hozzászólásod.

Miután nagy valószínűséggel nem ismered, mi alapján döntött a require.js/moduláris rendszer mellett, miért ítélkezel? Az öröklődések száma prototípusos módnál valóban nem nagyon számít, mert natív, de pl. az eléggé elterjedt (nem natív) object.extend() esetében ez nem így van, mert minél több szint van, annál lassabb lesz az objektum létrehozása.
74

Szintén

Pepita · 2013. Dec. 20. (P), 16.21
inf3rno kapcsán 100% egyetértésem, de
prototípusos módnál valóban nem nagyon számít

Ilyenkor nem annyi db másolat készül a teljes "objektumról", ahány örökítés? Mert akkor memóriában számít, persze függ az "objektum" méretétől is, de mindenképp annyiszorosa, ahány öröklődés. Ha jól gondolom.
Ekkor viszont a "nem nagyon" (ami egyébként is: most igen vagy nem?) már inkább "nagyon".
75

Méretre valószínűleg

Hidvégi Gábor · 2013. Dec. 20. (P), 16.32
Méretre valószínűleg ugyanakkora lesz, viszont az nem mindegy, hogy az új példányt JS vagy natív kóddal állítod elő.
76

Na ne...

Pepita · 2013. Dec. 20. (P), 16.47
Eddig arról volt szó, hogy valódi öröklődés nincs, hanem egy-az-egyben másolás, ha az ős-"objektumon" változtatsz, akkor az nem hat ki a gyermekekre.

Akkor a
Méretre valószínűleg ugyanakkora lesz
pont azt jelenti, amit írtam: annyiszorosa (a teljes méret), ahányszor örökítettél. + amit menet közben adtál még a gyerekekhez. Ha a memóriát ilyen szinten zabálod (netán névteret is "rendesen" foglalsz még hozzá), akkor nyugodtan meg is eheted a natív kódot, mert már el....tad. A kérdésem erre irányult, de kb már meg is válaszoltam, de nem 100-as, hogy jól.
77

Prototípusos öröklődésnél épp

bamegakapa · 2013. Dec. 20. (P), 17.54
Prototípusos öröklődésnél épp hogy kihat az ős változtatása a gyermekekre. Nem másolás történik, hanem prototípuslánc épül fel. Ha lekérsz valamit a gyerekről, és azon nincs rajta, addig megy majd a mászkálás a prototípusláncon felfelé, amíg valamelyik ősön nem lesz meg, amit kértél. Ha egyiken sincs meg, akkor ugye undefined az eredmény.

A 34-esben írt példám is ezt érzékelteti.

Már ha jól értem, amit írsz.
81

Jól érted, köszönöm,

Pepita · 2013. Dec. 20. (P), 23.56
én kevertem össze.
Akkor ezen a vonalon nem sok "érdekes" történik, Gábornak is igaza van.
Jobban kell figyeljek, ill. van restanciám JS-ből (mondjuk ezt tudtam is :)).

Köszönöm a helyre tételt.
78

Pont, hogy nincs

SecretName · 2013. Dec. 20. (P), 19.00
Pont, hogy nincs igazad.

Olvass már utána lécci a Javascript öröklődésnek, mert pont, hogy nem lesz annyi
szorosa a "osztály/objektum" "mérete" ahányszor örökítettél, épp ez a prototype lényege. Az "csak" egy osztott tároló, "csak" "delegálódik" a gyerekek felé.
83

El vagy tévedve

bamegakapa · 2013. Dec. 21. (Szo), 00.36
Nem érzem úgy, hogy bármit érdemben hozzátettél volna a 77-es hozzászólásomhoz a témával kapcsolatban, errefelé meg nem szokás valakit azért rugdosni, mert tévedett.
86

Ígérete szerint

Pepita · 2013. Dec. 21. (Szo), 11.14
többet nem teszi, de nem csak te érzed úgy... A tiédből írt egy másikat, kissé "más" hangnemben. Nem érdemes vele foglalkozni, "úgyse ide jön"...
79

Öröklődésről volt szó, az

SecretName · 2013. Dec. 20. (P), 19.26
Öröklődésről volt szó, az object.extend() bármit is jelentsen
nem számít annak, így nincs is értelme említeni sem vele kapcsolatban
az "öröklődések száma" kifejezést.

Visszaveszek(?), ha Te meg megtanulsz olvasni és értelmezni.

Ő állította, ".. hogyha valaki nem használ require.js-t, akkor nem szokta szétdarabolni kis modulokra a kódját, mert fél, hogy túl lassú lesz a végeredmény".

A többség nem használ require.js-t, és én csak a többség mundérját védtem, az ilyen, asztalra letett leszólástól, lekicsinyítéstől, általánosítástól.:)

Egyébként nem voltam agresszív.. komoly gond, ha az ökörség szó itt már annak számít.
80

Az erőszak erőszakot szül,

Hidvégi Gábor · 2013. Dec. 20. (P), 20.08
Az erőszak erőszakot szül, mint a példában láthattuk.
82

Öcsém, legalább

Pepita · 2013. Dec. 21. (Szo), 00.09
idézetben idéznél, és pontosan, valamint tényleg utánanézhetnél a helyi szokásoknak és hogy ki mit tett már le az asztalra.

Így csak a hónapos regeddel máris lehúztad magad a retyón, ha te leszel gondban egy kérdéssel, a kutya nem fog neked segíteni.

Te írkálsz itt ökörségeket:
komoly gond, ha az ökörség szó itt már annak számít.
(Látod: így kell idézni. :))

Nem a szó, hanem az egész megnyilvánulásod, tudod, láttunk itt már néhány napig hozzád hasonló ifjú mindentudókat... Ebben a szakmában is, mint minden másikban, a legfontosabb helyes megközelítés a magamban kételkedés és az alázat. Így lehet tudást szerezni, mások fikázásával pedig inkább a parlamentben lehet kétes érdemekhez jutni, de itt semmiképp.
Ugyanazt a szerinted tévedést meg lehet ám mondani normálisan is.

Ha ennyire ász vagy, hol voltál idáig?

Megjegyzem - példa a szakmai alázatra -, hogy én csaknem 2 évig csak olvastam a WL-t, nem is regeltem... Figyeltem, hogy mit csinálnak a "nagyok". És nézd vissza a "történetem" (követő), igen sokat kérdeztem eleinte, és nem válaszoltam - mert féltem, hogy nem tudok eleget hozzá. Csak mikor már a sokadik olyan választ olvastam, amit én is írtam volna.
Szóval lehet így is, meg titánkodni, ahogy próbálsz, de ezzel az utóbbival semmire sem mész. Itt.
84

A részemről az utolsó

SecretName · 2013. Dec. 21. (Szo), 10.14
A részemről az utolsó hozzászólásom az oldalon bármihez is..

.. köszönöm, hogy aggódsz, de ritkán vagyok gondban és nem a weblabor az a hely, ahová "gondjaimmal" fordulnék.

.. nem tudtam, hogy ez a hely itt egy beltenyészet, asztalokkal, "szokásokkal", ahol sokan erkölcscsősznek érzik magukat, akik csak azt nem veszik észre, hogy saját magukat is minősítik mások látatlanban való minősítésével.. köszönöm, hogy leifjúzol és letitánozol.. de egyik sem vagyok.. mint ahogy agresszív sem attól, hogy az "leökörségezek" valamit.. egy alapvető tévedést.. smile-val.

.. A "tényleg utánanézhetnél" kicsit nehéz értelmezni, hogy gondoltad?:) Az oldalon nem találtam használati feltételeket, szabályokat, etikai kódexet. De, elfogadom, ha az ökör szó itt már kiveri a biztosítékot.. és ha versbe foglalom, vagy metaforával írom le?:)) Így jobb: szarvas hiba?:)

Részemről ennyi..

Egyébként ifjú, agresszív titánként:), ez a cikk már csak arra is tökéletes volt, hogy felfedjen pár szarvas hibát:), mind egyesek ismeretében, mind a teszt kérdésekben.
85

Helyes, köszi!

Pepita · 2013. Dec. 21. (Szo), 11.11
A részemről az utolsó hozzászólásom az oldalon bármihez is..
Azt hiszem ezt immár sokunk nevében mondhatom: köszönöm szépen, Isten tartsa meg jó szokásod!
Komolyan.
A többi rész kommentálásával már nem is fáradnék...
88

Bár van, amiben igazad van,

bamegakapa · 2013. Dec. 21. (Szo), 12.59
Bár van, amiben igazad van, de majd higgadtabban ránézve te is rájössz, hogy nem az ökör szóval volt a baj (nekem legalábbis nem). Egyszerűen rosszul vagy nem tudatosan használod a szavakat és mondatokat, kivéve ha célod volt egy kis viharkeltés, ez esetben viszont ügyesen csináltad. Szerintem felesleges megsértődnöd, mint ahogy a többieknek is persze.
87

Azért ez épp az, amit ő

bamegakapa · 2013. Dec. 21. (Szo), 12.47
Azért ez épp az, amit ő csinált. Nem mondom, hogy nincs hasznos mondanivaló benne, de ezekre az odamondásokra sincs semmi szükség szerintem.
99

Nem, távolról sem ugyanaz

Pepita · 2013. Dec. 21. (Szo), 22.00
Lehet, hogy kicsit túl "odamondtam", de benne van az igazság, és némi példaérték is. Mondjuk megelőzendő a többi ilyet. Szerintem. Persze tiszteletben tartom a te véleményed is.
123

Bocs, de ekkora ökörségeket

inf3rno · 2013. Dec. 24. (K), 16.00
Bocs, de ekkora ökörségeket már rég olvastam..


Megbocsájtok!
55

Nehéz megfelelő álláspontot

inf3rno · 2013. Dec. 18. (Sze), 23.30
Nehéz megfelelő álláspontot találni. A nyelvi elem valamelyest segítene a helyzeten, pl nekem egy Function.prototype.extend is bőven elég lenne, viszont nem ez a problémám.

A helyzet az, hogy nyelvi elem ide vagy oda, a js-ben ettől függetlenül többféle öröklési minta lesz míg világ a világ ellentétben az olyan nyelvekkel, amikben van osztály, és általában csak egy extends van mellé. Nem véletlenül kezdtek el néhány éve sokan azon agyalni js-ben, hogy hogyan érdemes megoldani az öröklődést, és nem véletlenül született egy csomó cikk róla. Más nyelvekre az ilyesmi egyáltalán nem jellemző...

Én átfogalmaznám a kérdést úgy, hogy "Melyik a leggyakrabban használt öröklési minta javascriptben?", vagy "Milyen öröklési mintákat ismersz javascriptben?".
61

A "Functional pattern" egy

SecretName · 2013. Dec. 19. (Cs), 09.12
A "Functional pattern" egy gányolás Douglas Crockford-tól.

Több ok miatt nem beszélhetünk öröklődésről..

.. a legfontosabb, hogy prototype alapú "öröklődéskor" nem írod felől a szülő
"osztály" metódusát és meg tudod hívni bármelyik gyerekéből, ennél felülírod ( nem véletlen, hogy a példákban sem is írja felül a szülő függvényeit ).

.. a másik, ami ebből következik, hogy a példákban különálló "objektumok" jönnek létre, különálló változókkal és függvényekkel. Azaz nem örökölnek semmit a szülőtől, hiába adnál neki egy új függvényt azt nem örökölné egyik "gyereke" sem.

Azonkívül egyébként tök jó ki bug és leak-halmaz a "that" miatt.

A kérdésre tehát egy jó válasz adható.. minden más gányolás.
66

Szerintem nem kellene

Endyl · 2013. Dec. 19. (Cs), 12.02
Szerintem nem kellene átfogalmazni az öröklődésre vonatkozó kérdést, lévén a "Melyik a leggyakrabban használt öröklési minta javascriptben?", vagy a "Milyen öröklési mintákat ismersz javascriptben?" kérdések teljesen másra vonatkoznak, mint az eredeti "Hogyan működik az öröklődés JavaScriptben?" kérdés. A JavaScript alapvetően csak a prototípusos öröklődést ismeri, pont. A többi öröklési mintát ezt felhasználva próbálják meg implementálni több-kevesebb sikerrel (sok próbálkozás tűnik inkább a nyelv megerőszakolásának, vagy gányolásnak, amik csak több bughoz vezetnek - vagy legalábbis félreértés miatti programozói hibához, ha az illető nincs tisztában azzal, hogy a klasszikus minta mögött valójában prototípusos öröklődés munkálkodik; ezért is lehet fontos ezt az elméleti tudást felmérni egy összetett projektben való részvételhez).

Szerintem a class kulcsszó (és társai) nem a legszerencsésebb választás, hiszen ez ugyanúgy csak a prototípusos mintát fogja elfedni egy tömörebb szintakszissal, és aki tényleges osztályokkal rendelkező nyelv felől érkezik a JS-hez, azt igencsak összezavarhatja. Sokkal tisztább lenne bevezetni kulcsszavakat, amik a prototípusos minta sajátjai lennének, de nyilván macerás új foglalt szavakat bevezetni.

Egyébként volt már erről korábban blogmark, ami szerintem szépen összefoglalja és fejtegeti a témát.
124

Sokkal tisztább lenne

inf3rno · 2013. Dec. 24. (K), 16.05
Sokkal tisztább lenne bevezetni kulcsszavakat, amik a prototípusos minta sajátjai lennének, de nyilván macerás új foglalt szavakat bevezetni.


Ebben egyetértek. Jobb lett volna már eleve úgy indulni, hogy

var User = new Prototype({...});
var Customer = User.extends({...})
var Customer = new Prototype({
    inherits: User,
    ...
})
vagy bármi hasonló...

A class kulcsszó valóban nem helytálló egy osztály nélküli nyelvben, nem is igazán értem, hogy miért reserved word.
38

Ez az egész dolog már ott

Poetro · 2013. Dec. 18. (Sze), 10.36
Ez az egész dolog már ott elhalt, hogy js-ben nincsenek osztályok és metódusok, azok nélkül meg nem lehet öröklődésről beszélni. Ugyanígy nincsenek interface-ek, azok nélkül meg nincs sok értelme polimorfizmusról beszélni.

Miért ne lehetne öröklődésről beszélni. Vannak más nyelvek is, amikben van öröklődés, és nincsennek benne interfacek és osztályok. Metódusok igenis vannak JS-ben, ugyanis egy objektum azon tulajdonságait, amik függvények, metódusnak hívjuk. A JS ezen kívül támogatja az összes OOP követelményt:
  • Dynamic dispatch - az objektum dönti el, milyen kód fut le, amikor meghívják egy metódusát (pl prototípus láncon való végiglépkedés.)
  • Encapsulation - a működés el van rejtve, valamint az állapotáról az objektum gondoskodik.
  • Subtype polymorphism - léteznek altípusok, és azok módosított viselkedést, tulajdonságokat mutathatnak a szülőhöz képes, és ahol a szülő használható, ott a gyerek is.
  • Object inheritance (or delegation) - létezik öröklődés, mégpedig a specifikáció szerint ez a prototípus alapú öröklődés.
  • Open recursion - az objektum hivatkozhat saját magára, JS esetén a this kulcsszóval.
39

"Azokon a napokon" 1nf3rn0

Hidvégi Gábor · 2013. Dec. 18. (Sze), 11.00
"Azokon a napokon" 1nf3rn0 kötekedős kedvében van, kezeld ennek figyelembe vételével az esetet.
43

ja az tény, hogy tegnap ilyen

inf3rno · 2013. Dec. 18. (Sze), 15.10
ja az tény, hogy tegnap ilyen napom volt :D
45

In object-oriented

inf3rno · 2013. Dec. 18. (Sze), 15.19
In object-oriented programming, a method is a subroutine (or procedure) associated with a class.

Method (computer programming)

Ami innentől lényeges, hogy js-ben vajon vannak e class-ek, vagy nincsenek. Szerintem nincsenek, én legalábbis a konstruktor függvényeket nem tekintem osztályoknak, de ezt csak érzésre mondom, lehet, hogy tévedek benne.

Ádámmal beszéltünk múltkor az encapsulation-ről, azóta leülepedett, de még mindig nem teljesen tiszta a kép ezzel kapcsolatban. Jelenleg az ragadt meg, hogy class-hez kell encapsulation, és a ppp része ennek, de újra el kellene olvasnom az egészet, hogy kitisztuljon a kép.
47

A function that is associated

Poetro · 2013. Dec. 18. (Sze), 17.11
A function that is associated with an object via a property is a method.

ECMAScript Language Specification - 4.2 Language Overview
51

Innentől kezdve elkezdhetünk

inf3rno · 2013. Dec. 18. (Sze), 22.54
Innentől kezdve elkezdhetünk js specifikus szótárakat gyártani az ECMAScript specifikáció alapján... :-)

Prototype-based programming is a style of object-oriented programming in which behaviour reuse (known as inheritance) is performed via a process of cloning existing objects that serve as prototypes. This model can also be known as prototypal, prototype-oriented, classless, or instance-based programming.

Prototype-based programming

In object-oriented programming, a method is a subroutine (or procedure) associated with a class.

Method (computer programming)

Nekem nem nehéz innentől összerakni, hogyha osztályok nincsenek, akkor metódusok sincsenek, tökmindegy, hogy erről mit mond az ECMAScript specifikáció...

Másrészt viszont:

In object-oriented programming (OOP), inheritance is when an object or class is based on another object or class, using the same implementation; it is a mechanism for code reuse.

Inheritance (object-oriented programming)

Szóval az öröklődés nem csak osztályok között értelmezett, hanem objektumok között is, szóval lehetséges prototype based nyelven is örököltetni.

Classical Inheritance in JavaScript Ebből nagyjából kiderül, hogy inheritance alatt a classical inheritance-re gondoltam, viszont úgy néz ki, hogy ez egy tágabb fogalom, ami több részre tagolódik a classical inheritance-re, a prototypal inheritance-re, és még sok más eltérő megoldásra. Szóval ja, bár osztályok nincsenek, öröklődés mégis van js alatt.

Polimorfizmus is van, de sajnos nehezen használható (debuggolható) interface-ek nélkül. A go-jéhoz hasonlító interface implementáció jót tenne a nyelvnek. Meg lehet oldani, csak baromi lassú, mert a Function.prototype.toString-el lehet csak kinyerni a paraméter listát, a típusokat meg alapból valahogy külön kellene megadni. Szóval sajna js-nek is megvannak a maga korlátai.

Amit továbbra is fenntartok, hogy js-ben nem csak prototípusos öröklődés van/megoldható, ezért a kérdés és a válasz pontatlan. Bár ez szőrszálhasogatás, de ha már ennyire elméleti szakembert kerestek...
52

Nem feltétlenül tartom jó

bamegakapa · 2013. Dec. 18. (Sze), 23.03
Nem feltétlenül tartom jó iránynak, hogy a Wikipédia szóhasználatát fogadjuk el döntőnek egy ilyen kérdésben. A metódus van annyira tágan értelmezett (és sok mindenre használt) fogalom az informatikában, hogy bőven elviselje, hogy objektumoknak akkor is lehessenek metódusai, ha előtte nem egy osztályban definiáltuk azokat.

Ami a Classical Inheritance-et illeti, az valóban egy örököltetési minta, ahogy te fogalmaztál. Egy olyan minta, ami a Javascriptben natívan jelenlévő prototípusos öröklődésre épül (mint több más örököltetési minta, persze nem mindegyik).
53

Nem feltétlenül tartom jó

inf3rno · 2013. Dec. 18. (Sze), 23.12
Nem feltétlenül tartom jó iránynak, hogy a Wikipédia szóhasználatát fogadjuk el döntőnek egy ilyen kérdésben. A metódus van annyira tágan értelmezett (és sok mindenre használt) fogalom az informatikában, hogy bőven elviselje, hogy objektumoknak akkor is lehessenek metódusai, ha előtte nem egy osztályban definiáltuk azokat.


Ehhez nem tudok hozzászólni, folytattunk már itt elméleti vitákat ilyen kérdésekről oo, class, encapsulation, polymorphism témában, és arra jutottunk, vagy legalábbis én arra jutottam, hogy össze kellene hozni egy közös szótárat, amiben definiálunk egy-egy fogalmat a megfelelő hivatkozásokkal. Jelenleg nekem erre semmi időm nincsen, és arra sem, hogy tudományos hivatkozásokat keressek. Amit tisztán látok, hogyha nincs közös nevezéktan, akkor az ilyen elméleti kérdéseket mindenki máshogy fogja érteni, a gyakorlati kérdések viszont ezzel szemben szótártól függetlenül teljesen egyértelműek. Aztán persze az is lehet, hogy a probléma csak velem van, mert én gyakorlati úton tanultam meg a js-t, és csak később kezdtem el elmélettel foglalkozni, így elképzelhető, hogy nincsenek meg a megfelelő elméleti alapjaim. :-)
60

Ezzel egyet tudok érteni. És

bamegakapa · 2013. Dec. 19. (Cs), 07.03
Ezzel egyet tudok érteni. És az elmélet nekem sem erõs oldalam :).
13

A primitív típusok (number,

MadBence · 2013. Dec. 17. (K), 18.30
A primitív típusok (number, string, boolean, undefined, null) érték szerint, az objektumok (azaz minden más) pedig referencia szerint.

Hohó, ez nem igaz, minden érték szerint adódik át, szigorúan pass-by-value (hasonlóan a Java-hoz), referencia szerint nem is lehet semmit átadni. Természetesen az objektumokra csak referenciával lehet hivatkozni ettől még.
Csak hogy világos legyen:

var foo = { bar: 1 };
function baz(qux) {
  qux = { woof: 2 };
}
baz(foo);
console.log(foo); // foo értéke nem változik meg, hiszen nem referencia szerint lett átadva.
Referencia szerinti átadás példa:
#include<iostream>
void foo(int &bar) {
  bar = 2;
}
int main() {
  int baz = 1;
  foo(baz);
  std::cout<<baz<<std::endl; // 2, hiszen referencia szerint adtuk át.
}
Nagyon szép stackoverflow válasz, ami eloszlatja a kételyeket:
Java[Script] is always pass-by-value. The difficult thing can be to understand that Java passes objects as references and those references are passed by value.
16

Jogos

bamegakapa · 2013. Dec. 17. (K), 18.38
Hehe, elég figyelmetlenül olvasok, hogy nem szúrtam ki. Király összefoglalás viszont. Lehetne a következő blogposzt ;).
15

+1, én is csak néztem bután,

inf3rno · 2013. Dec. 17. (K), 18.38
+1, én is csak néztem bután, amikor referencia szerinti átadásról volt szó, de aztán átsiklottam felette, PHP-ben az "&"-el lehet referencia szerint átadni, és szinte sosem használja senki, mert kényelmetlen, mindenki érték szerint ad át ott is.

Azt hiszem ez elég jól bizonyítja, hogy mennyire értelmetlenek ezek a kérdések, és a gyakorlat szempontjából mennyire jelentéktelenek. Elég magas labda ez most, nehéz megállni, hogy ne kezdjem cikizni Poetro-t. :D :D (csak hát az élet az ilyesmit mindig visszaadja)
23

PHP-ben nem igaz!

Pepita · 2013. Dec. 17. (K), 21.55
PHP-ben az "&"-el lehet referencia szerint átadni, és szinte sosem használja senki, mert kényelmetlen, mindenki érték szerint ad át ott is.

Rendben, én senki vagyok :), viszont pár kB adat felett simán referenciát adok át PHP-ben, és egy bonyolultabb funkció megvalósítása során ezzel MB-okat spórolok RAM-ban, ami egyben futásidő-csökkenést is jelent. Nagy forgalom esetén ez nagyon nem elhanyagolható, és nekem egyáltalán nem "kényelmetlen". Itt a PHP-részben igen elhamarkodottan ítéltél.
24

Lehet, hogy csak városi

inf3rno · 2013. Dec. 17. (K), 21.59
Lehet, hogy csak városi legenda, de elvileg php-ben van valami extra feature ezzel kapcsolatban, hogyha nagy mennyiségű adattal dolgozol, akkor a másolás nem igényel különösebb erőforrást egészen addig, amíg nem próbálsz beleírni a másolatba. Mondjuk én ennek nem néztem utána, csak mások mindig emlegetik.
29

Remélem legenda

Pepita · 2013. Dec. 17. (K), 22.44
Ha ez így van, akkor minden egyes változókkal kapcsolatos művelet (mármint ami más változótól is kapott értéket) min. dupla futásidejű, mert benne van egy plusz körülményes ellenőrzés. Ekkor viszont a PHP sokkal gagyibb nyelv, mint gondoltam. Elszomorítana, én sem néztem utána, adott méret felett én eleve referenciát adok, ha módomban áll. Persze a mai napig van, hogy fel kell lapozzam a manual-t, hogy most hova is tegyem az & jelet... :)

Ha viszont saját MD-HTML átalakítókban gondolkozol, igen javaslom, hogy te is szokj rá a referenciákra, minek egyen az alkalmazásod dupla RAM-ot, ha nem kell?
30

copy-on-write

darevish · 2013. Dec. 17. (K), 23.43
Es mar tobbszor volt rola szo itt a weblaboron is. Itt egy iras rola
32

A linkelt írásban

Pepita · 2013. Dec. 18. (Sze), 00.40
főleg fv-hívások vannak, illetve paraméter átadás. Az kissé más szitu, mint az $a = $b; $a =& $b;. Ha itt is volt szó róla, linkelhetnéd azt is, hátha közelebbi, bár egy JS-blogot nem akarnék szétoffolni ezért.
Esetleg akár új témaként vagy blogban leírhatnád, hogy is van ez pontosan, szerintem nem csak engem érdekelne.
35

En se offolnek, de

darevish · 2013. Dec. 18. (Sze), 02.28
muszaj lesz, mert mar igy is tulleptem az evre tervezett hozzaszolasszamot, az uj tema meg mar nagyon meresz lenne :). A valasz kb. arra vonatkozott, hogy nem urban legend a cucc, tenyleg letezik ilyen, es copy-on-write a neve. Annyi az egesz, hogy amikor azt mondod, hogy

$a = 'valami';
$b = $a;
akkor az nem 2*$a-nyi teruletet fog fogalni, mert szimplan inkrementalodik $a referenciaszamlaloja es $b is ugyanarra az ertekre fog mutatni, tehat nem sporolsz memoriat, ha referenciat hasznalsz.

Viszont ha ezutan modositod $b-t, akkor $a nem valtozik, tehat ott mar le kellett, hogy masolodjon.

Ja, es igy hirtelen ez ugrik be pl, hogy itt volt emlitve
56

Köszi, így már érthető

Pepita · 2013. Dec. 18. (Sze), 23.54
Az okot viszont nem értem, hogy ez miért jó, kvázi helyettem megelőlegezi a referenciát, amíg megteheti. Ezzel memóriát spórolhat, mindaddig, amíg nem változtatok $b-n. Viszont folyamatosan "figyelnie kell" $b-t, ami procihasználatból lesz jóval több. Amit nyert a réven, bukta a vámon - szerintem.
Ha mindez rám van bízva, akkor lehet jól spórolni, természetesen érteni is kell hozzá.
Ismét egy PHP tulajdonság, amit én nem tartok kifejezetten jó ötletnek...
59

Ez nem teljesen világos

MadBence · 2013. Dec. 19. (Cs), 00.26
Ez nem teljesen világos nekem... Miért kéne folyamatosan "figyelnie"? A PHP tudja, hogy a $b az micsoda (le kell-e másolni ha módosítjuk), ez az optimalizáció kvázi ingyen van.
62

Rossz kifejezés

Pepita · 2013. Dec. 19. (Cs), 09.57
Bocsi, nem folyamatosan, hanem a memóriacímre hivatkozáskor. És ha az írás (itt máris egy plusz feltétel), akkor ellenőrizni, hogy honnan jött a kérés ($a vagy $b, mégegy feltétel) és szükség esetén új memóriaterület foglalása, adatok átmásolása, és csak azután a módosítás. + megfelelő helyekre elmenteni az állapotot, hogy következő íráskor már lehessen tudni, hogy van másolat.
Ezt szerintem jobb lenne egyetlen egyszer, a változó deklarálásakor megtenni.
Nekem simán beleférne a PHP-be, hogy nekem kell deklarálnom a változót, sőt, a típusosság is. Ez szemlélet kérdése, de így inkább lehetne OOP nyelv. És lényegesen gyorsabb lenne.
64

Most konkrétan egy bit

BlaZe · 2013. Dec. 19. (Cs), 10.42
Most konkrétan egy bit ellenőrzését és beállítását tartod lassúnak? Az összes többi ugyanaz, mint lenne enélkül a logika nélkül. Egyébként az ellenőrzés is csak írásnál fog megtörténni. Olvasásnál miért kéne?
67

Azt hiszem,

Pepita · 2013. Dec. 19. (Cs), 14.20
itt már szándékosan nem akarod érteni, amit mondok, ezzel be is fejeztem az offolást, ez egy JS blog, nem PHP.
68

Tévedsz

Hidvégi Gábor · 2013. Dec. 19. (Cs), 15.13
Blaze nem olyan, ezért kezeskedem. A copy-on-write egy hasznos dolog, érdemes utánajárni.
69

OK, bocsánat,

Pepita · 2013. Dec. 19. (Cs), 19.58
Blaze, elnézést kérek, de én akkor sem értek egyet a copy-on-write-al, és itt nem kívánom tovább vitatni, lévén - ismét jelzem - js a témakör.
128

Kiemeltem. temak/119974

inf3rno · 2013. Dec. 24. (K), 23.29
Kiemeltem. temak/119974
17

Referencia szerint

Poetro · 2013. Dec. 17. (K), 18.58
A referencia szerintet úgy értettem, ahogy Java-ban is van, azaz, ha módosítod a kapott elem tulajdonságait, az a hívott fél esetében is látszani fog. Azaz valójában az objektum referenciájának értéke adódik át (mivel máshogy nem is lehet objektumokra hivatkozni).
var myArray = [];
function pushItem(arr, value) {
  arr.push(value);
}
function addItem(arr, value) {
  arr[arr.length] = value;
}
pushItem(myArray, 1);
console.log(myArray); // [1]
addItem(myArray, 2)
console.log(myArray); // [1, 2]

function updateBaz(obj, value) {
  obj.baz = value;
}
myObj = {baz: "foo"};
updateBaz(myObj, "bar");
console.log(myObj) // {baz: "bar"} 
18

Pontosan :), csak nevezzük

MadBence · 2013. Dec. 17. (K), 19.06
Pontosan :), csak nevezzük nevén a gyereket. Gondolom az eredeti kérdés azt akarja megtudni a kedves versenyzőtől, hogy függvényhívásnál lemásolódik-e az egész objektum szőröstül-bőröstül (lásd C struct), vagy a referenciája adódik át (érték szerint! :D), a többi igaziból csak szőrszálhasogatás.
Csak ha már egyszer korrekt kérdés - korrekt válasz poszt, akkor legyenek tényleg korrektek a válaszok.
20

új kreálódik

zzrek · 2013. Dec. 17. (K), 20.19
A függvényen belül amikor kiadod a qux={...} parancsot, akkor nem arról van szó, hogy a kifejezés jobboldalán kreálódik egy objektum, aminek a címét jelenti ezentúl a qux, a régi címet (qux-ot)tartalmazó rész pedig felülíródik ill. eldobásra kerül?
Mert ha így van, akkor mégiscsak a referencia adódott át, csak épp nem használtuk semmire, hanem rögtön ugyanazt a nevet (qux) egy másik objektum referenciájaként definiáltuk. (?)

var foo = { bar: 1 };  
function baz(qux) {  
  qux.bar=2;  
}  
baz(foo);  
console.log(foo.bar); // 2, vagyis mégiscsak valami referenciaszerű lett átadva
21

Olyasmi :), az objektumok

MadBence · 2013. Dec. 17. (K), 20.50
Olyasmi :), az objektumok referenciák, a referenciák pedig érték szerint vannak átadva :)

Vegyünk egy kevésbé bonyolult példát, azon talán jobban látszik a lényeg:
var foo = { bar: 1 };
foo = { bar: 2 }; // a foo által korábban hivatkozott objektumot nem módosítottuk, pusztán a foo már nem rá "mutat", azaz elveszett a referenciánk, majd a gc szépen összeszedi
foo.bar = 3; // a foo által "mutatott" objektum ({ bar: 2 }) módosult
Leginkább a pointerekhez lehet hasonlítani ezt a működést:
#include<iostream>
struct F { int bar; F(int b):bar(b){} };
int main() {
  F f1(1);
  F f2(2);
  F *g = &f1; // előző példa első sora
  g = &f2; // előző példa második sora, g máshova fog mutatni!
  g->bar = 3; // 3. sor
  std::cout<<f1.bar<<std::endl; // 1
  std::cout<<f2.bar<<std::endl; // 3
 return 0;
}
Referenciákkal mást tapasztalunk: (sok köze nincs a JS-hez)
#include<iostream>
struct F { int bar; F(int b):bar(b){} };
int main() {
  F f1(1);
  F f2(2);
  F &g = f1;
  g = f2; // f1-be bemásoljuk ami f2-ben van
  g.bar = 3; // f1.bar = 3
  std::cout<<f1.bar<<std::endl; // 3
  std::cout<<f2.bar<<std::endl; // 2
 return 0;
}
89

Értelmetlen

zakzag · 2013. Dec. 21. (Szo), 15.33
Ha azt is érték szerinti átadásnak nevezed, ha a referencia értékét adod át, akkor nincs értelme az ilyen fajta megkülönböztetésnek, hiszen nincs olyan "átadás" ami ne valami értéket adna át (vagy ne adna át valami értéket) - mert az nem átadás hanem _semmi_.
91

Már korábban leírtam, hogy mi

MadBence · 2013. Dec. 21. (Szo), 15.46
Már korábban leírtam, hogy mi a különbség az érték ill. referencia szerinti átadás között.

var a = 1;
function inc(b) {
 b = b+1;
}
inc(a);
Ha a értéke megváltozik, akkor referencia szerint adtuk át, ha nem, akkor érték szerint. JavaScriptben csak érték szerint tudsz átadni értéket (ellentétben pl a C++-szal, ahol referencia szerint is át tudod adni). A JS referenciafogalma leginkább a pointereknek feleltethető meg.
92

szerintem nem csak érték szerint lehet

zzrek · 2013. Dec. 21. (Szo), 17.57

var a = [1];  
function inc(b,c) {  
 b[c] = b[c]+1;  
}  
inc(a,0); 
console.log(a[0]) //2
Lám, megváltozott.

Nem nevezném értéknek, ami az első paraméterben átadásra kerül.
Szerintem a javascriptben senkit nem érdekel, hogy az ilyen paraméterátadást "referenciának" vagy "pointernek" nevezzük. Ez már nem félreérthető, ha referenciának nevezzük.
93

Nem teljesen értem ennek mi

MadBence · 2013. Dec. 21. (Szo), 18.38
Nem teljesen értem ennek mi köze van a paraméterátadáshoz, hiszen b-hez hozzá sem nyúltál: a b által mutatott objektum c tagját írtad fölül, ami azt mutatja, hogy az objektum maga valóban nem másolódott le (ennek viszont semmi köze a paraméterátadáshoz)

Valószínűleg az itt lévők többsége pontosan tudja, hogy Poetro kérdése mire vonatkozott, a választ hogy kell érteni, illetve tisztában van azzal, hogy JS-ben hogy működik a paraméterek átadása. Viszont nem kellene azt terjeszteni, hogy a JS pass-by-reference objektumok esetében (hiszen nem). Objektumokra csak referenciával lehet hivatkozni, és ezek a referenciák függvényhíváskor lemásolódnak (tehát pass-by-value).
97

Poetro-t idézném

zzrek · 2013. Dec. 21. (Szo), 21.51
17-es hozzászólás:
A referencia szerintet úgy értettem, ahogy Java-ban is van, azaz, ha módosítod a kapott elem tulajdonságait, az a hívott fél esetében is látszani fog. Azaz valójában az objektum referenciájának értéke adódik át (mivel máshogy nem is lehet objektumokra hivatkozni).

Az objektum referencia "értéke", amire utalsz, az sohasem jelenik (és nem jelenhet) meg a JS-ben, és senkit sem érdekel. Nem lehet rá máshogyan az objektumra hivatkozni, ezért értelmetlen arról beszélni, hogy ez a sohasem látható érték épp megkettőződik-e függvényhíváskor, vagy sem. Az viszont fontos, hogy ilyenkor az objektum összes adata nem helyi értékként kerül kezelésre egy függvény belsejében, hanem "kimutat" az objektum eredeti elemeire. Pedig lehetne másképp is, például az egész objektum lemásolásra kerülhetne (mint szerializáláskor). Tehát erre a kettősségre kell rákérdezni, ezt kell tudni: egy akármilyen hosszú string paraméterként átadva megkettőződik a memóriában és "nem hat vissza" a változtatása az eredeti változó értékére, míg egy egészen kicsi objektum esetében sem történik ilyen másolás, és ezt kell ismernie a JS programozóknak.
Ha azt mondanánk, hogy az objektum by-pass-value, az sokkal megtévesztőbb lenne, mert akkor azzal úgy tűnne, hogy ezt a másolást, megkettőzést, és az ezzel járó "visszahatás hiányát" hangsúlyoznánk.

... b-hez hozzá sem nyúltál...

A "b"-t a függvény paraméterlistájában definiáltam, mindegy, hogy hozzányúltam-e, vagy sem. A "b" semmiképp nem nevezhető értéknek, mert nem használom értékként. A "b"-ben lévő értékhez nem is tudok hozzányúlni, és nem is akarok.
Ha nem nevezhető értéknek, akkor pedig a "referencia" elnevezés szerintem megfelelő ebben a kontextusban.
102

Én értem, hogy megtévesztő,

MadBence · 2013. Dec. 21. (Szo), 22.19
Én értem, hogy megtévesztő, de ettől még pass-by-value :), a 18-as hsz-ben már én is leírtam, hogy értem mi akart lenni a kérdés tárgya (az objektumokra referenciával lehet csak hivatkozni, azaz nem másolódnak le értékadásnál).

A szakirodalom a referencia szerinti átadáson (pass-by-reference) nem a JS-ben is meglévő viselkedést érti, így a további vita szerintem értelmetlen.
105

értelmetlen valóban

zzrek · 2013. Dec. 22. (V), 13.00
Értelmetlen valóban, de akkor hogyan nevezzük? Attól, hogy a referenciát by-pass-value adja át (ami senkit sem érdekel a JS-ben) attól még nem mondhatjuk, hogy érték szerinti átadás történik.
Jó lenne megállapodni, hogy ezt hogyan hívjuk (de amíg nincs ilyen megállapodás, addig szerintem többet mond, ha azt mondjuk, hogy referencia átadása történik, hiszen az is történik, a referencia átadása)
Te hogyan neveznéd ezt? (Tudom, by-pass-value-nak :-) )

(Érdekes és hasznos volt amiket írtál, tetszett, ne érts félre, de szerintem a JS kontextusában értelmetlen azt hangsúlyozni, hogy ez nem referencia átadás)
108

Tényleg jó lenne

Pepita · 2013. Dec. 22. (V), 19.27
Jó lenne megállapodni, hogy ezt hogyan hívjuk
Én nem "szavazok", de kíváncsian várnám az elnevezést, Poetro-tól is, és tőletek is.
109

Hívjuk pass-by-reference-nek.

Hidvégi Gábor · 2013. Dec. 22. (V), 19.28
Hívjuk pass-by-reference-nek.
110

Miért kéne máshogy nevezni,

BlaZe · 2013. Dec. 22. (V), 21.31
Miért kéne máshogy nevezni, mint ahogy hívják? Ez pass-by-value.

Attól, hogy a referenciát by-pass-value adja át (ami senkit sem érdekel a JS-ben) attól még nem mondhatjuk, hogy érték szerinti átadás történik.

Miért ne érdekelne? Neked mindegy, hogy egy meghívott függvény meg tudja változtatni a hívó oldal paraméterben átadott változóinak értékét, vagy sem? A pass-by-reference ugyanis ezt jelentené.
111

Szerintem

Pepita · 2013. Dec. 22. (V), 22.27
itt lehet a lényeg.
113

Hány százalékban teljesült "a lényeg"?

zzrek · 2013. Dec. 23. (H), 14.42
Tehát ez lenne a lényeg:
egy meghívott függvény meg tudja változtatni a hívó oldal paraméterben átadott változóinak értékét, vagy sem?

    var a = [1,2,3,4];    
    function inc(b) {
     for (var j=0;j<b.length;j++) 
     b[j] = b[j]+1;    
    }    
    inc(a,0);   
    console.log(a[0]) //2  
Ha jól látom itt 1+4 érték lett átadva: az "a" változó referenciája, valamit 4 db érték az "a" változón belül. Ebből 4-et meg tudtam változtatni (egyet pedig senki sem akar megváltoztatni a JS-ben, és sohasem hívható elő értékként), tehát 80%-ban nem teljesült a "lényeg" (pass-by-value). (Mint mondtam, a Js-ben nincs pointer vagy referenciakezelésre nyelvi elem, és ezért ez senkit nem is érdekel. A lényeg viszont, hogy így is meg lehet változtatni a hívó oldalban megadott változók értékeit, és ezzel kell tisztában lenni, foglalkozni kell vele, szerintem ez a lényeg)
115

Igen

Pepita · 2013. Dec. 23. (H), 15.52
Szerintem ott a lényeg, hogy hogyan (nem) tudsz "visszanyúlni" az átadott "objektum" egyéb tulajdonságaihoz. Nekem ezért is idézőjeles az objektum js-ben. Egy csomó dolog másképp műxik, mint megszoktam, ezért bevallom: nyűglődök is sokat js-ben.

De már olyan fura elméleti dologban vagyunk, amit kezdek nem átlátni. A fentebb említett nyelvekben a referencia átadásával valóban átadtam az egész objektumot. Itt ezt nem látom tisztán érvényesülni, de lehet, hogy én vagyok vak.

A kódod 6. sorát pedig nem értem: mi akar a második paraméter lenni, a fv-ed nem is csinál vele semmit. Oda csak simán inc(a); kéne, ha minden értékét növelni akarod.
Ha pedig inc(a[0]);-ként hívod, akkor vagy tömböt csinálsz az a[0] értékéből, de inkább hibával elszáll, mert nem tömb az a[0] értéke.
ezzel kell tisztában lenni, foglalkozni kell vele
A kialakult vitában pont ez az, ami egyre inkább összekeveredik nekem, te, vagy bárki más összefoglalhatná végre "hülyék számára is", ezekből az oda-vissza rövid kommentekből leginkább az egyet nem értés jön le, de az igazság (nekem) nem tiszta.
Hát foglalkozzunk vele (akár külön témában).
116

bocs

zzrek · 2013. Dec. 23. (H), 21.23
Bocs a kavarásért, az inc(a,0) -ban a ",0" az előző példából ragadt benn (copypaste hiba), nem szükséges.
Egyébként szőrszálhasogatás folyik, semmi lényeges, szerintem ami fontos azt érted te is.
118

Köszi

Pepita · 2013. Dec. 23. (H), 21.40
Már kezdtem igen hülyének érezni magam - ami ettől még lehetséges... :)
119

Szőrszálhasogatás

BlaZe · 2013. Dec. 23. (H), 23.43
A lényeg viszont, hogy így is meg lehet változtatni a hívó oldalban megadott változók értékeit, és ezzel kell tisztában lenni, foglalkozni kell vele, szerintem ez a lényeg

De nem lehet, pont ezt mondja MadBence is, meg én is. Ezért nem pass-by-reference, hanem pass-by-value. A hívó oldalnak egy referenciája van egy másik valamire, nevezzük objektumnak az egyszerűség kedvéért. Ezt a referenciát másolja le és adja át a hívott kódnak (csak ezt, ami a referencia mögött van, azt nem), és a hívó referenciáját nem tudja megváltoztatni a hívott kód. A referencia mögött lévő objektum egy tulajdonságát lehet megváltoztatni, amihez a hívónak semmi köze nincs azon kívül, hogy ő is használja, így ez a változás hatással lesz rá.

Hogy egy kézzelfoghatóbb példát mondjak: Elviszed a barátnőd fodrászhoz. Más lesz a haja, észreveszed, örülsz (vagy nem), de továbbra is ő a barátnőd. Ez a pass-by-value. A pass-by-reference esetén benne van, hogy a fodrász megtréfál, és onnantól Chubaka lesz a barátnőd :) Még mindig szőrszálhasogatásnak látod a dolgot? :)
120

Kicsit pontosíts!

Pepita · 2013. Dec. 24. (K), 00.01
A linkelt képen melyik a fodrász és melyik a barátnőd?
Ha ezt még helyreteszed, mindent tudni fogok a js referenciaátadásáról.... :)
121

Tisztázzuk

zzrek · 2013. Dec. 24. (K), 00.34
Tisztázzuk: én értem, hogy mi a referencia, a pointer, a pass-by-value stb, programoztam c++ -ban már nagyon régóta (valószínűleg hamarabb ismertem ezeket, mint a jelenlévők többsége). Csak szerintem itt nem ez a lényeg, hanem hogy egy kérdéssel fel kell mérni a jelentkező ismereteit, és erre a kérdésre a JS (nem C++!) körében a "referencia" kifejezés megfelelő. Nem szükséges további magyarázat, ejtsük a témát, köszönöm :-)
112

Rendben

zzrek · 2013. Dec. 23. (H), 14.26
Rendben, valahogy az az érzésem, hogy direkt félre vagyok értve. Hogy ezt tisztázzam, akkor inkább megfordítom a kérdést. Minek neveznéd ezt az átadási formát (alább) ?

    var a = [1];    
    function inc(b,c) {    
     b[c] = b[c]+1;    
    }    
    inc(a,0);   
    console.log(a[0]) //1, vagyis nem 2 
114

Ahogy már korábban is

MadBence · 2013. Dec. 23. (H), 15.10
Ahogy már korábban is mondtam, rossz a példa, hiszen az objektumra mutató referenciát sehol sem bántod.
A JS paraméterátadása leginkább a 3. változatra hasonlít.
C++ példa:
void inc_val(int a) { //pass-by-value
  a = 2;
}
void inc_ref(int& a) { //pass-by-reference
  a = 3;
}
void inc_p(int* a) { //pass-by-value, mert a pointer érték, lemásolódik
  *a = 4;
  a = NULL; // semmi hatása sincs, hiszen lokális változó
}
int main() {
  int a = 1;
  inc_val(a);
  std::cout<<a<<std::endl; // 1
  inc_val(a);
  std::cout<<a<<std::endl; // 3
  inc_p(&a);
  std::cout<<a<<std::endl; // 4
}
117

Á

zzrek · 2013. Dec. 23. (H), 21.25
Á, hagyjuk. De azért köszi.
103

Az objektum referencia

tgr · 2013. Dec. 21. (Szo), 23.00
Az objektum referencia "értéke", amire utalsz, az sohasem jelenik (és nem jelenhet) meg a JS-ben, és senkit sem érdekel.


Dehogynem jelenik meg, [1]===[1] azért lesz hamis, mert [1] értéke nem "1-et tartalmazó tömb", hanem egy referencia egy 1-et tartalmazó tömbre (vö. mondjuk PHP-val, ahol a fenti kifejezés igaz). Hasonlóan, amikor azt mondod, hogy var a = b;, akkor a megkapja b értékét (megintcsak vö. a PHP-vel, ahol az érték ilyenkor nem egy referencia, hanem a tömb elemeinek listája.)
107

Érdekes

zzrek · 2013. Dec. 22. (V), 13.09
Érdekes amit írsz, de szerintem nem azért hamis a [1]===[1] mert a különböző referenciákat hasonlítja össze, hanem azért, mert az objektum egyes elemeit egyenként nem hasonlítja össze. (Vagyis nem technikai, hanem szabványkérdés, hogy ez hogyan történjen, és a JS megalkotásakor úgy döntöttek, hogy ez így legyen. Dönthettek volna másképp is, pl. azt is mondhatták volna, hogy az === operátor esetén igenis végig kell menni az összes elemen rekurzívan és mindent egyenként meg kell vizsgálni, és akkor igaz lenne a kifejezés, annak ellenére, hogy a két oldalon két különböző referencia van)
Összességében nem értek egyet azzal, hogy a referencia ebben az esetben megjelenik a JS-ben, az viszont lehetséges, hogy a motor belső működése "kilátszik". Ettől függetlenül a referencia, mint számérték senkit sem érdekel a JS-ben és ez jó is így.
Ezekután a referencia átadása pont azt kell, hogy jelentse, amit a JS most csinál, vagyis a referencia értékének átadását, és ezt nem célszerű érték szerinti átadásnak nevezni még akkor sem, ha más nyelvekben a by-pass-value kategóriába tartozik (mivel más nyelvekben van ennek jelentősége)
125

var simple = 1;var complex =

inf3rno · 2013. Dec. 24. (K), 16.20

var simple = 1;
var complex = {
    simpleProperty: 1
};
function inc(simpleParam, complexParam){
   ++simpleParam;
   ++complexParam.simpleProperty;
   complexParam = {simpleProperty: 3};
}
inc(simple, complex);

//érték szerinti átadás:
//simple: 1
//complex: {simpleProperty: 2}

//referencia szerinti átadás:
//simple: 2
//complex: {simpleProperty: 3}
A referencia szerinti átadás azt jelenti, hogy ugyanazt a változót fogod írni, csak a paraméter listában megadott néven hivatkozol rá. Az érték szerinti átadás azt jelenti, hogy egy tök új változót hozol létre, és átmásolod abba az átadott változó értékét.
100

Máshol is van

Pepita · 2013. Dec. 21. (Szo), 22.06
ellentétben pl a C++-szal, ahol referencia szerint is át tudod adni

Csak zárójelben jegyzem meg, hogy Delphiben ugyanúgy van rá lehetőség, és ha jól emlékszem Java-ban is, de ezt nagyon rég nem használtam, ebben tévedhetek. Szóval nem egy szokatlan "jelenség" szerintem sem, kár, hogy js-ben nincs rá lehetőség.
104

A Java pass-by-value

BlaZe · 2013. Dec. 22. (V), 01.11
A Java említve volt már, hogy pass-by-value.

http://docs.oracle.com/javase/tutorial/java/javaOO/arguments.html
Primitive arguments, such as an int or a double, are passed into methods by value. This means that any changes to the values of the parameters exist only within the scope of the method.
Reference data type parameters, such as objects, are also passed into methods by value. This means that when the method returns, the passed-in reference still references the same object as before. However, the values of the object's fields can be changed in the method, if they have the proper access level.

Érdemes picit elgondolkodni hogyan hat az encapsulationre, mint az OOP egyik alappillérére a pass-by-reference... A Java ilyen "csúfságokat" nem akar megengedni, ezért referenciákat adunk át pass-by-value. Amúgy a referenciákkal kapcsolatos másik félreértésből eredeztetett "szivatós" Java interjúkérdés, hogy mit lép a Java, ha egy finalként deklarált objektum-on valamilyen mutator metódust hívsz. Meglepően gyakran mondják azt, hogy ezt nem teheted meg, azt gondolva, hogy a final immutable-é teszi az objektumot. Pedig a final csak annyit jelent (a java kód szintjén), hogy az adott referenciát nem módosíthatod a scope-on belül sem (metódus, objektum), míg a nem finalként deklarált referenciát igen, de a pass-by-value miatt ez a módosítás csak az adott scope-on belül fog megtörténni.

Többen írták már, hogy a referencia, pointer átadása nem pass-by-reference. Bővebben itt
26

Amit eddig senki nem vett észre

Pepita · 2013. Dec. 17. (K), 22.15
Először is min. +100 WL-pont vagy akármi Poetro-nak, csak azért, mert egy munkáltató képviselőjeként megpróbált a munkavállalók számára segítséget nyújtani. Ezt szerintem legfeljebb Gábor vette észre, de senki sem jelezte, pedig szerintem le a kalappal, ilyet nem látunk minden nap.
Épp azt látni sok helyen, amit Virág és inf3rno pedz: ha már munkáltatót képvisel valaki, akkor "nagyobbnak képzeli magát".

Hát Poetrora ez biztosan nem igaz, különben nem hozta volna létre ezt a bejegyzést sem, és ezért már önmagában szerintem "pontokat érdemel".

A másik, hogy az itt adott válaszokból - mint látható is! - ő maga is tanul, ezek szerint (és persze főnökei szerint :( ) nyilván változtat is az interjúztatásán.

Részemről biztos, hogy a kérdések legalább felére én visszakérdeznék, de nem merem azt mondani, hogy ez ezt vagy azt mindjárt elárul rólam (inf3rno, ez általánosítás).
De azt sem merném állítani, hogy ez jó így. Poetro-t és kommunikációját ismerve (laza, vidám) én azt mondom, hogy indulásnak jók ezek a kérdések, nyilván utána kell pontosítani rajta, ill. rávezetni, de ez nem gond, pont így lehet sokat megtudni elsőre a "vizsgázóról". Poetro nyugodtan felteheti ezeket a kérdéseket, ő messze nem az a "mumus", akire Virág (és részben inf3rno) gondol.

És valóban az alapokra megy, így első olvasatra be is sz....tam, gondolkodni kellett. Az a kérdés jó, amin gondolkodni kell.
Ha az a gondod, hogy mire is gondol a kérdező, kérdezz vissza - szerintem.

Mindezt, mint saját véleményemet írtam, és azzal, hogy magamat csak "gyenge-haladó" kategóriába sorolnám js-ből, bár lehet, hogy a "középhaladó" helyesebb, csak az önkritika...

A lényeg: már a témafelvetés becsülendő, és ismét sokat tanultam Poetro (és a töbiek) révén.
36

Így van

Hidvégi Gábor · 2013. Dec. 18. (Sze), 09.24
Egyetértek, és szerintem is ez egy nagyon fontos és jó bejegyzés, abszolút segítő szándékkal.

Ezt szerintem legfeljebb Gábor vette észre
Kedves tőled, de szerintem másnak is feltűnt a bevezető utolsó mondatából:
Ezeket a kérdéseket és válaszokat próbáltam összegyűjteni, hátha mások tanulni tudnak belőle.
58

Feltűnt?

Pepita · 2013. Dec. 19. (Cs), 00.14
Ahhoz képest sok volt a "kötekedés", értsd jól, nem jut eszembe jobb szó rá. Tehát nemigen értékelte szinte senki, pedig fontos, máris másképp kérdezel / állítasz, ha ezt szem előtt tartod.
37

Köszi

Poetro · 2013. Dec. 18. (Sze), 10.20
A másik, hogy az itt adott válaszokból - mint látható is! - ő maga is tanul, ezek szerint (és persze főnökei szerint :( ) nyilván változtat is az interjúztatásán.

Igen, köszönök szépen minden hozzászólást, önös érdekek is fűződnek ezen post létrehozásához. Meg akartam tudni mások hogyan vélekednek a kérdésekről, illetve hogy mit lenne érdemes változtatni.
indulásnak jók ezek a kérdések, nyilván utána kell pontosítani rajta, ill. rávezetni, de ez nem gond, pont így lehet sokat megtudni elsőre a "vizsgázóról"

Igen, próbálom rávezetni őket, példákat adok, ha nem tiszták elsőre a kérdések. Egyébként a telefonos interjó alatt a fentieken felül még vagy 30 kérdést felteszek az OOP, JS és CSS témaköréből, szóval nem ennyire szűkek a kérdések, inkább csak a legbonzolultabbakat, problémásabbakat szerettem volna felhozni.
44

Tetszik, hogy kivárod, amíg

inf3rno · 2013. Dec. 18. (Sze), 15.16
Tetszik, hogy kivárod, amíg mindenki kibontja a véleményét, aztán csak a végén foglalsz állást. Én nem ismerem személyesen Poetro-t, csak általánosságban írtam, hogy mit gondolok az ilyen jellegű kérésekről. Plusz tegnap kötekedős hangulatban voltam, valószínűleg mert elmaradt a hétfői edzésem. :-)
57

Igazából nem direkt vártam,

Pepita · 2013. Dec. 19. (Cs), 00.09
mire bekapcsolódtam ott volt a többségé, viszont végigolvastam mindet a komolyabb válasz előtt, így összeszedettebb lett, amit hiányoltam / észre vettem.
Poetro-val azt hiszem egyszer találkoztam személyesen (WL sörözés), de azt hiszem mindketten vagyunk olyan nyitottak, hogy valamennyire meg is ismertük egymást. És hát az itteni tapasztalatokból is meg lehet magát az embert is ismerni.

Szerintem amennyire "kötekedős" voltál, az simán még belefér (tök jó, hogy te tudsz engem moderálni, nem fordítva :)), serkentette az egészséges vitát.

Összességében én ezt a bejegyzést bekeretezve elküldeném sok, akár nem IT-s cégnek is (főleg HR-eseknek), hogy lám-lám: így is lehet.

Poetro szerintem nagyon okosan és tervszerűen halad a célja felé, ráadásul nem egyedül, egy csapatban, ahol keresztül is kell tudnia vinni az elképzeléseit.

Kezdek vágyni egy Poetro-interjúra, de félek is az eredménytől... :) (Ez mondjuk jó, mert máris, interjú nélkül is tanulásra serkent.)
27

Ezek JS ismereti kérdések, és megfelelőek

ern0 · 2013. Dec. 17. (K), 22.16
Aki ezekre megválaszol, az már dolgozott JS-ben.

Esetleg még lehetne egy kis jQuery:
- mi a különbség a és b között:
a = document.getElementById("foo");
b = $("#foo");
- hogyan kreálsz egy DIV-et jQuery-vel

Ilyen nehézségű kérdésektől még nem lesz a jelentkezőnek kiütése, ti. hogy túl trükkös a kérdés vagy túl sok erőfeszítést igényel a válasz.

A következő lépcső egy jó kis NPP-teszt lehet (Non-Programming Programmer szűrés).
65

Az első kérdésed esetén, ha

SecretName · 2013. Dec. 19. (Cs), 10.53
Az első kérdésed esetén, ha napi szinten kódolsz azt fogod válaszolni,
hogy semmi, mindkét esetben megkapod a kért elemet (én legalábbis ezt mondanám),
mert egy szinten túl észrevétlenül kezeled a különbségeket.
90

egyet nem értésem

zakzag · 2013. Dec. 21. (Szo), 15.43
-et kell kinyilvánítsam az egyik interjú kérdéssel kapcsolatban. A null nem azért van, hogy a programozó _szándékosan_ jelezze hogy nincs értéke a változónak.
Ha nincs értéke, akkor undefined kellene legyen az értéke (tehát végülis van értéke). A null igenis érték, méghozzá null, és azért van, hogy nem létező objektumot reprezentáljon.
Ha ezzel az értékkel hozol létre változót - ami nem objektumot tartalmaz, nem követsz el nagy bajt, de alapvetően hibásan használod a nyelvet.
A különbség - remélem nem mondok újdonságot - a typeof operátornál jön elő aholis typeof null === "object" és nem null a typeof undefined pedig "undefined" ahogy várjuk.
Ezért tér vissza minden DOM metódus null-lal ha nem talál objektumot (.queryAll) és nem undefined. Szerintem.
94

Nem null az

Arnold Layne · 2013. Dec. 21. (Szo), 19.12
Ezért tér vissza minden DOM metódus null-lal ha nem talál objektumot (.queryAll) és nem undefined. Szerintem.

Nekem üres NodeListet ad vissza. Firefox getElementsBy* esetén HTMLCollectiont.
95

OK

zakzag · 2013. Dec. 21. (Szo), 21.10
Ok, azt elrontottam, de minden,ami egy objektumot ad vissza, az null-lal tér vissza (getElementById pl.). Azért a mondandóm lényege nyilván nem ez.
96

Szőrszálhasogatás

Hidvégi Gábor · 2013. Dec. 21. (Szo), 21.31
Bár igazad van, de a lényegen nem változtat, mert a végeredmény az lesz, amit Poetro leírt.
98

igen, szerintem is

zakzag · 2013. Dec. 21. (Szo), 21.55
igen, szerintem is szőrszálhasogatás :)
101

+1

Pepita · 2013. Dec. 21. (Szo), 22.09
Pontosan így van.
106

typeof null === "object"

complex857 · 2013. Dec. 22. (V), 13.00
A typeof null === "object" története valójában egy egyszerű implementációs hiba / felületesség okán következett be majd utána szabványosításkor bennhagytak a nyelvben (ha már szőrszálhasogatunk :P).

Történt ugyanis, hogy az első js implementációban az egyes JS oldali változók C világbeli mutatóit tartalmazó terület alsó pár bitjeiben tárolta tárolta az adott változó típusát (ezek adott architektúrán egy C "long" méretűek így volt hely, előbb jsword majd jsval lesz ebből a longból) és a 0 -ás érték az "object" típust reprezentálta.

A typoeof operátor csak megnézte a mutatott memóriaterület alsó 3 bitjét (JSVAL_IS_OBJECT(v)) ami simán össze "&"-eli a típus bitmaskokkal, és ez alapján döntött.

A JS-ben lévő null értéket C oldalon a 0 szám literál jsval-ba való castolása reprezentálja aminek alsó pár bitje bizony 0 bitekkel van feltöltve (az egész csupa 0 bit) és így illeszkedik object bitmaskjára és typeof már adja is vissza vidáman, hogy "object".

(Itt jegyezném meg, hogy minden szimpátiám a jövő archeológusaié akiknek esetleg forráskód nélkül kell felderíteni valamit :P)

Amennyire én tudom semmiféle "reprezentáljuk azt, hogy..." gondolat nem volt mögötte eredetileg, sőt maga Brendan Eich is ki akarta javítani ezt ES6-ban, de végül nem sikerült:
http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null
(kettőspontot nem eszi meg bbcode url...)
134

"a jövő archeológusai..."

comp · 2014. Jan. 15. (Sze), 02.27
"(Itt jegyezném meg, hogy minden szimpátiám a jövő archeológusaié akiknek esetleg forráskód nélkül kell felderíteni valamit :P)"
OFF: Még szerencse hogy a digitális világ nem marad fent elég hosszan hogy az archeológusok is tanuljanak belőle :-)
129

Esetleg...

atomjani · 2013. Dec. 25. (Sze), 09.06
Elméleti fejtegetésnek jó például a hogyan oldanád meg ezt meg amazt. Esetleg az öröklődéssel hogyan oldaná meg, ha ilyen formára is kíváncsiak vagyunk. Nem kell papíron vagy gépen leprogramozni, egy jó programozó fejben kitalálja, levezeti a dolgokat. Persze ez sem mindig működhet mindig jól.
Én egyébként azért nem megyek ilyen interjúkra, mert nem tudok js nyelven. Én inkább szeretem a dolgokat php-val és css-sel megoldani. Ahol elég ez is, oda se megyek csak azért, mert kezdetleges tudással rendelkezek.
130

kesereg..

EL Tebe · 2014. Jan. 7. (K), 10.43
én talán soha sem fogom ilyen szépen megfogalmazni a fenti válaszokat.. :S mindig is csodáltam azokat, akiknek ez ennyire megy
131

interjú kérdések

comp · 2014. Jan. 14. (K), 13.11
Hasznos kérdések / válaszok, azonban kifejezetten JavaScript-ben az öröklődés helyett inkább érdemes delegálást használni.
132

Delegálás?

Poetro · 2014. Jan. 14. (K), 15.04
Tudnál egy rövid magyarázatot adni, hogy miért érdemesebb delegálást használni? Szerintem az öröklődés és a delegálás nem zárja ki egymást, sőt inkább erősíti.
133

delegálás vs öröklődés

comp · 2014. Jan. 15. (Sze), 01.56
Valóban nem, viszont az öröklődés elsősorban osztályok köré szerveződő nyelvek sajátossága. A prototype tervezési mintát használók természetesen közelebb esnek magához a delegáláshoz, hiszen egyes megvalósítások is erre a tervezési mintára épülnek.

Természetesen az öröklődés és delegálás fizikailag nem zárja ki egymást, mindkettőnek megvan az előnye és a hátránya, de pl. a többszörös öröklés tudtom szerint jelenleg még csak mixinekkel oldható meg JavaScriptben (ha van más megoldás/ötlet, kérlek osszátok meg), polimorfizmus meg egyszerűen nem megoldható (nincs relatív referencia az ős- konstruktorokra, ilyenkor jöhet a this és call(this) ami nehezen áttekinthető/nyomon követhető és kezelhető kódot eredményez).
Az is tény, hogy alap objektumok szuperkonstruktorait sem illik megváltoztatni a prototype chainben és a prototípusok mechanizmusait csak körültekintően lehet módosítani - jobb esetben sehogy, bár itt is a böngésző különbségek adnak lehetőséget egy kis bizonytalanságra :-) (hasOwnProperty vs. hasOwnProperty.call ill. FF __proto__ témakör - ez szintén jó vizsgakérdés lehet mert erősen kerülendő a legtöbb kódban).

Máshogyan megfogalmazva az osztály szintű öröklődés az egy interfész/tervrajz kiegészítése, a prototype viszont egy bizonyos viselkedés delegálása más objektumokra. Látszólag azonosnak tűnő definíciók, de a különbségek összetettebb rendszerek esetében halmozottan jelentkeznek (főleg JavaScriptnél ahol a prototype gyakorlatilag csak egy delegate kapcsolat két objektum között). Ha megpróbáljuk a "class-ikus" öröklődést imitálni JavaScriptben, akkor pont a JS-motorok natív támogatottságú dinamikusságát lehet elveszíteni vele (ezt nem tudom jelenleg másképpen/jobban megfogalmazni).