49
-
Komolytalan #49 Én is be tudom írni google-ba hogy JS OOP. Ezen a linken van is róla egész helyre kis tutorial. 2 gond van csak vele:
- rögtön az első bekezdésben próbál mosakodni, hogy miért is OOP
- és valójában nem is az. Mivel ahhoz, hogy OOP legyen a hozzáférési szintek elég konkrétan definiáltak, hogy mik szükségesek: public, protected, private (kulcsszó nyilván lehet más). Ennek nyoma sincs.
Ha valahonnan sikerül előkaparnod egy Turbo Pascal 5.5 könyvet, mondjuk a 80-as 90-es évek fordulójáról, akkor abban korrektebb OOP megvalósítást láthatsz (vagyis ott korrektet láthatsz, JS-nél meg csak részleges próbálkozást). -
Komolytalan #48 "A hozzaferesi jogokrol meg csak annyit, hogy ezek elhagyasa tervezesi dontes volt, ami engem nem zavar."
Pedig ez k.rvára zavaró dolog. Én dolgoztam olyan JAVA szerveren, amelyben a fejlesztője _mindent_ public-ra vett. Ez ugye azzal járt, hogy fogalmam se volt, hogy egy osztály mely propertyje állítható, mely metódusa hívható biztonságosan kívülről (természetesen nem mindegyikre volt ez igaz). Éppen ez az egyik olyan érv, ami miatt én nem igazán hiszek abban, hogy a JS-ben komoly rendszereket lehetne könnyedén fejleszteni - 1 olyan változót elqr az ember, amit nem kéne, aztán keresheti hetekig hogy mitől dőlt össze az egész.
"A static meg nem ertelmezheto egy dinamkus nyelvnel"
A static az az osztály szintű változót jelölné, amely tényleg nem értelmezhető akkor, ha 1 osztály 1 példány. -
Alien_AM #47 Bocsi ha esetleg nem tudsz angolul talaltam magyar leirast is az oroklodesrol:
Objektumorientált JavaScript programozás a felszín alatt
http://weblabor.hu/cikkek/oojsafelszinalatt -
Alien_AM #46 Felesleges idehanynod hogy hany diplomad van mert senki se hiszi el, az inkabb valoszinu hogy meg a kozepiskolat se fejezted be...
Eloszor is ajanlom figyelmedbe, ez egy egeszen jo konyv: (bar ketlem hogy tudsz angolul):
http://www.amazon.com/Object-Oriented-JavaScript-high-quality-applications-libraries/dp/1847194141
Mivel az egesz vilag szerint OOP nyelv csak ugye szerinted nem (es a masik accod vagy jopajtasod szerint se: netperformer), azert beszurok par referenciat:
Object-Oriented Javascript
http://nefariousdesigns.co.uk/object-oriented-javascript.html
Introduction to Object-Oriented JavaScript
https://developer.mozilla.org/en-US/docs/JavaScript/Introduction_to_Object-Oriented_JavaScript
Object Oriented Programming in JavaScript
http://mckoss.com/jscript/object.htm
JavaScript Object-Oriented Programming
http://www.sitepoint.com/oriented-programming-1/
The Basics of Object-Oriented JavaScript
http://net.tutsplus.com/tutorials/javascript-ajax/the-basics-of-object-oriented-javascript/
Create Advanced Web Applications With Object-Oriented Techniques
http://msdn.microsoft.com/en-us/magazine/cc163419.aspx
Understanding JavaScript OOP
http://killdream.github.com/blog/2011/10/understanding-javascript-oop/
OOP in JS, Part 1 : Public/Private Variables and Methods
http://phrogz.net/JS/classes/OOPinJS.html
The Ultimate Guide to Object Oriented Basics of JavaScript
http://www.1stwebdesigner.com/design/object-oriented-basics-javascript/ -
kvp #45 "Ráadásul ahogy látom egy "classnak" 1 példánya van, ami hát legalábbis vicces, ha így van."
Nem jol latod. Egyszeruen csak nem erted a dinamikus kornyezetek mukodeset. A lenyeg, mint a smalltalk eseten az, hogy minden objektum tipus is egyben. A hozzaferesi jogokrol meg csak annyit, hogy ezek elhagyasa tervezesi dontes volt, ami engem nem zavar. A static meg nem ertelmezheto egy dinamkus nyelvnel, csak a statikus tipus ellenorzeses nyelvekben hasznalhato. Hasonlo nem tisztan oop dontes volt c++ eseten a proceduralis c megtartasa vagy java-ban a nativ tipusok. JS eseten a vegrehajto motort probaltak vele egyszerusiteni es gyorsitani. Mondjuk c++-ban sem sokat er a const kulcsszo, mert cast-tal felulirhato. Innentol erdemesebb inkabb a fejlesztok jozan eszere hagyatkozni.
En is joreszt oop-nak nevezheto kornyezetben dolgozom (java, c++), de attol meg nem kedvelem oket annyira. A c++ ujabban mar nem is oop, amiota az stl es a boost hasznalata elterjedt, mivel a template programozas direkt szembemegy az oop elvvel.
Egyebkent meg c-ben is lehet oop kodot irni, csak a fordito nem erolteti ra az emberre a szabalyait. Az elso c++ fordito is c-re forditott. Az oop vagy a template elv nem csak a nyelvtol fugg, hanem az azt alkalmazo progrmozo tudasatol. -
FoodLFG #44 Nem ide tartozik teljesen, csak ha már feljött a Quake és az WebGL.
A WebGL-es kódok esetében nagy a bemeneti perifériák késleltetése, ami a rendszer felépítéséből adódik és amivel nem lehet mit kezdeni.
Akit érdekel a webGL + JS: http://youtu.be/XAqIpGU8ZZk
large-scale, high performance JS-t is megemlíti. Én nem mernék a csajjal vitatkozni... :D
Visszatérve a Quake-re, John Carmack kb háborút hirdetett a különböző késleltetésekkel szemben. A mostani QuakeConon a beszéde nagy részében ezzel fogalakozott kb minden szinten.
Szóval hivatalos webGL kódot ne várjunk tőlük. De biztos lesz valaki, aki majd átírja a Rage kódját webGLre unalmában, ha majd nyilvánosságra hozzák. :D
http://media.tojicode.com/q3bsp/ :P -
Komolytalan #43 Abban teljesen igazad van, hogy JS-ben nem csináltam nagy projectet (valójában kicsit sem), mivel kézbe kaptam a diplomám (14 éve) csak OOP eszközökkel fejlesztek. Mindezt úgy, hogy főiskolán akkoriban még nem is tanítottak OOP-t, csak procedurális nyelveket (meg nem Neumanni számítógéppel is foglalkoztam akkoriban, annak a nyelve se ez, se az). Szóval mielőtt dolgozni kezdtem volna 8 évig foglalkoztam procedurális nyelvek programozásával (közép+fősuli). Éppen ezért tisztában vagyok azoknak a nyűgjeivel, és a lehetőségeivel. Nem a levegőbe beszélek, amikor azt mondom, hogy nagy projectre OOP nyelv való (vagy mocskos sok pénz+idő, ha procedurálist választunk). Egyébként nagyobb projectek esetén a procedurális nyelveknél is próbálnak OOP felé konvergálni - dinamikus függvényhívás, és társai mind-mind OOP pótlékok. Szóval nem arról van szó, hogy csak OOP-t ismerek - ha valaki megfizetné, tudnék programozni akár Assemblyben is, hisz éveken át az volt a hobbym. Csak ma már erre nem nagyon van kereslet.
Mivel JS-t nem ismerem eléggé, ezért kértem, hogy mutassatok JS-ben példát az öröklődésre, illetve a metódusok/propertyk nyilvánosságára/zártságára, és az absztrakcióra. Mivel OOPhez ezek kellenek. Semmi ilyesmit nem láttam. Evvan. -
#42
Ebben egyet értünk. Alien_AM egy idióta. Ha csak az oop rövidítésének jelentését tudná, akkor már nem mondana ekkora hülyeséget egy script nyelvre xD -
Alien_AM #41 OK latom nincs ertelme vitazni, ha akarod felhuzom a tudasod javaban priviben arra a szintre hogy megertsd, es akkor bebizonyitom neked. Mellesleg pont rad vall hogy magyar egyetemen vegeztel es ezert nem latod at a dolgokat es valoszinu nagyobb projekteket sem csinaltal ebben a nyelvkornyezetben. -
Komolytalan #40 "A js pedig igen is oop."
Nem tudom ezt honnan szeditek, meg hol tanítanak ilyen hülyeségeket, de ha netán egyetemen, akkor már érthető hogy milyen gyenge emberek jelentkeznek manapság fejlesztőnek. -
Komolytalan #39 JAVA téma: A JAVA készítői egyszerűen csak nem akartak belehalni a szépségbe. Csináltak egy Integer típust, aminek van toString() metódusa, de mocsok lassú, mivel a példányosítása az ugye pointerek létrehozásával jár. Meg csináltak egy int típust, ami simán csak 4 byte a memóriában (64 bites rendszeren talán 8 byte?), és emiatt gyors - versenyképes mondjuk egy C++-al is (nem 20x lassabb, hanem 2x, nem 20x memóriát foglal, hanem 2x).
Amit írtál JS kódot abban meg se hozzáférhetőség, se öröklődés nincs. Én nem véletlenül írtam a private/protected/public, illetve static előtagokat. Azok fontosak. Te semmi mást nem csináltál mint egy hash tömbnek adtál függvény típusú propertyket, vagyis nálad minden public. Ráadásul ahogy látom egy "classnak" 1 példánya van, ami hát legalábbis vicces, ha így van.
Az OOP ereje pont a hozzáférhetőségből és az öröklésből adódik - a többi csak hab a tortán. Ezek segítségével egyrészt lezárható a kódok azon része, amihez kívülről nem szabad piszkálni (mert mondjuk még csomó minden mást is meg kéne csinálni, ha mondjuk azt a változót átírjuk), illetve biztosított, hogy ha egy kódhoz már csak egy kicsi hiányzik, akkor se kelljen providenthez fordulni, hanem simán származtathatunk belőle egyet, és a public/protected részeit piszkálva hozzáírhatjuk azt a kicsit, amit mi szeretnénk, az eredeti funkcionalitást megtartva.
Ettől OOP az OOP, ez az amiért 15-20 éve nagyobb projecteknél OOP alapon gondolkozik mindenki. Ez nyilván nem jelenti azt, hogy mondjuk JS-ben ne lehetne sok mindent megírni - ha sok az erőforrás, akkor akár nagyobb alkalmazásokat is - egyszerűen csak ahogy bonyolódik a feladat, a JS úgy válik egyre alkalmatlanabbá a megoldására. -
Alien_AM #38 Igazabol te honnan jottel? A js pedig igen is oop.
Ne egesd mar magad, es foleg ne a tobbi forumozot idiotazd le, mert olvastal egy cikket prog.hu-n.
-
#37
Jól van paraszt! Vedd elő a szifonod azt' futtasd rajta WebGL-ben a quake-t, aztán ordibáld az utcán, hogy miért ilyen lassú a JS. Csak gratulálni tudok neked! Komolyan, honnan jön ez a sok idióta? -
kvp #36 "JAVA int példa nagyon rossz."
Nem a szintaxisrol van szo, hanem arrol, hogy a java belul (a runtime motorban) mashogy kezeli az int-eket es az Integer-eket. Az egyik nativ tipuskent van kezelve, a masik objektumkent. A nativ tipusok lete eleve egy kivetel, mivel tiszta oop nyelven nincs ilyen. Tehat a 2.toString()-nek is mukodnie kellene. Java eseten a nagyobb sebesseg miatt ezt a tudast kisporoltak. Ezert lehet java-ban nagyon egyszeruen proceduralis kodot irni. Az android forrasa tele van jo peldakkal.
A javascript-es kod nagyjabol trivialis: (adatrejtes es statikus valtozok nincsennek, a javascript egy teljesen dinamikus oo nyelv)
var nextId = 1;
var Parent = function(){ this.id = nextId++; };
Parent.prototype.calc = function(v){ return(v*2); };
Parent.prototype.getVal = function(){ return(this.calc(this.id)); };
var Child = function(){};
Child.prototype = new Parent();
Child.prototype.calc = function(v){ return(Parent.prototype.calc(this.id)+1); };
var c = new Child();
var p = new Parent();
document.write('Child='+c.getVal());
document.write('<br>');
document.write('Parent='+p.getVal());
Egyebkent meg szerintem a smalltalk-hoz kepest mindket pelda iszonyat ronda, bar mukodnek... -
Wyck01 #35 Ha valakit érdekel a HTML5 programozás, annak ezt az oldalt ajánlom. Rengeteg példa meg cikk van fent. html5.ugyesen.com -
Komolytalan #34 WebGL-t akkor minek is, ha nem abban akarnak quake-et írni, takonypóc? -
#33
Na vegyél vissza paraszt! Ha egy alkalmazást akarsz futtatni rajta, akkor azt nem JSbe kódolva futtatod... nyilvánvaló. Ha meg JS-ben akarsz quake livolni "irónia on", akkor nyilván nem a szaros telefonoddal kell nekiállnod. Paraszt. -
Komolytalan #32 Nem, viszont szeretném ha a JS elfogadható sebességgel futna rajta, ha már multiplatform megváltónak kiáltják ki, bunkócska. -
#31
Kenyeret pirítani nem akarsz telefonon? :D Paraszt. -
Komolytalan #30 De jó, hogy a sor eleji space-eket levágja ez a fostaliga fórummotor... -
Komolytalan #29 JAVA int példa nagyon rossz. Attól hogy valamiben nem úgy lehet összeadni kettőt meg kettőt, hogy
Integer b=new Integer(2).add(2)
hanem
int b=2+2
attól a nyelv csak használható (sebességű) lesz, de nem veszíti el az OOP mivoltát.
Viszont nézzünk egy apró OOP kódot - ezt hogy valósítanád meg JS-ben? Azért AS3 a kód, mert az AS1 ugyanarra az ECMA-262 szabványra épült (ezelőtt 15 évvel) mint a JS. De írhattam volna JAVA-ban vagy C#-ban is - aki bármely nyelvet ismeri, az láthatja, hogy minimálisak a különbségek: function/var töröl, :int a sor végén helyett int a sor elejére - szóval csupa apróság. Komolyan érdekelne hogy mindez hogy nézne ki JS-ben szerinted. És most légyszi ne 200 sor wikipédiás technoblablát, hanem konkrét kódot prezentálj.
Parent.as:
package {
public class Base {
private static var nextId:int=1;
protected var id:int;
public function Base() {
id=nextId++;
}
protected function calc( value:int ):int {
return 2*value;
}
public function get value():int {
return calc( id );
}
}
}
Child.as
package {
public class Child extends Base {
override protected function calc( value:int ):int {
return super.calc( value )+1;
}
}
}
A főprogram (Main.as):
package {
import flash.display.MovieClip;
public class Main extends MovieClip {
var c:Child=new Child();
var p:Parent=new Parent();
trace( c.id )
// Fordítási hiba - innen nem látható
trace( c.calc( 1 ) );
// Fordítási hiba - innen nem látható
trace( c.value );
// (2*1)+1=3
trace( p.value );
// (2*2)=4
}
} -
Komolytalan #28 Vagy éppen a mobiltelefonját, valami i7-es procisra, nem? -
#27
Cseréld le a 486-osodat te szerencsétlen :D -
BlackRose #26 :) -
![[HUN]FaTaL](https://media.sg.hu/forum/avatars/10557508481320070594.gif "[HUN]FaTaL")
#25
"Úgy értem sokkal szélesebb a felhasználási köre, mint az sokan hinnék."
Csak lassú, mint a szar. -
nagylzs #24 > Hagyjátok már ezt a hülyeséget. JS a scriptnyelvek közt erősen objektum orientált, mivel objektumokkal kezel mindent. Mi más lenne, procedurális?
Már megírtam: objektum alapú nyelv. (prototype language -nek is hívják). De nem szükséges érzelmi töltést társítani hozzá. Attól még hogy nem tiszta OOP, nem "rossz". Sőt. A JavaScript az egyetlen olyan nyelv, ami platformtól függetlenül vékony kliens gépeken izolált környezetben tud futni. Mert tényleg az összes platformon fut (ahol van böngésző), és tényleg izolált/biztonságos környezetben fut. Ebben nincs vetélytársa.
Mellesleg a JavaScript eléggé funkcionális nyelv is, ezen kívül imperatív és reflektív. Ha valakit ennyire érdekel akkor olvasson el erről egy könyvet, és miután megismert legalább 15 nyelvet, meg a lehetséges osztályozási szempontokat, akkor egyrészt rá fog jönni hogy nagyon ritkán lehet egy nyelvre tisztán rámondani hogy ez pontosan egy adott osztályba tartozik. (De ez nem is fontos.) Másrészt rá fog jönni hogy az OOP nem mindig egyenlő a "jó" fogalmával, és a "nem OOP" sem egyenlő a "rossz" fogalmával. Az éppen aktuális problémától függ hogy mit érdemes rá használni.
A HTML5 pedig igenis jó! Mert böngésző mindenhol van, és mindenhol lesz is. A népszerű böngészők úgyis támogatni fogják. A vékony kliensek / cloud alkalmazások fejlesztésénél továbbra is ez lesz az elsődleges kliens platform. És ebbe az irányba halad a világ, úgyhogy nem lehet megkerülni. Az már igaz, hogy egy "kicsit" lassan halad a szabványosítás, de ezt a részét nem érdemes kívülállóként bírálni. Mert az nem segít. Ha valakit ennyire zavar akkor jelentkezzen ingyenmunkára a W3C-nél. -
#23
Hagyjátok már ezt a hülyeséget. JS a scriptnyelvek közt erősen objektum orientált, mivel objektumokkal kezel mindent. Mi más lenne, procedurális? Na mennyetek a francba xD Persze hogy nem OOP, mert nem programnyelv, de alábecsülni viszont nem érdemes, mert egy két alap funkció hiányától eltekintve szinte mindent meglehet vele valósítani. Úgy értem sokkal szélesebb a felhasználási köre, mint az sokan hinnék.
Egyébként bevallom őszintén betegnek tekintek mindenkit, aki az OOP-vel dobálózik, mert kit érdekel, ha pl egy nyelven OOP-vel fejlesztesz vagy nem? Őszintén? A lényeg a moduláris fejlesztés, azt meg olyan módszerrel meg adatstruktúrába kivitelezed amilyennel akarod. -
kvp #22 "a JS nem OOP"
Mindenesetre objektum orientaltabb mint a c++. Egyebkent ilyen alapon a java sem az, mivel kezeli a c-bol atvett proceduralis megkozelitest es vannak benne nativ tipusok is, amik nem objektumok. (pl. az int nem objektum, az Integer igen, mindketto megtalalhato a java-ban)
Egyebkent nem kell objektumorientaltnak lennie egy nyelvnek ahhoz, hogy mukodjon. Tipikus pelda a c++-os template-ek esete, amik sok mindenek, de nem objektumok es kifejezetten megtorik az objektumorientaltsagot. (pl. template container-ekbol nem lehet szarmaztatni, raadasul szandekosan lettek ilyenek)
A javascript egyebkent nem olyan rossz nyelv. A html-bol szarmazo objektum faval pedig egesz jol hasznalhato egyszerubb feladatokra. Persze van jobb, pl. a nativ java, ami a legtobb uzleti rendszert es az osszes android-os keszuleket hajtja. Ott is megtalalhato az objektumfa, csak html helyett xml alapu, viszont ugyanugy egy bongeszo motor rendereli. (az android osszes gui-ja gyakorlatilag egy-egy bongeszo ablakban fut) Mellekhataskent felbontasfuggetlenek az alkalmazasok. Tehat azt amit az iphone eseten 3 kepernyomerettel nem tudnak rendesen kezelni, azt az android x+sok kepernyofelbontassal is jol kezeli, alapbol. (by design)
Az oop-vel kapcsolatban egy megjegyzes: Szerintem a smalltalk a legtisztabb oop nyelv, ott minden objektum peldany egyben sajat maga prototipusa is. Tehat egy objektum kepes magabol csinalni egy uj peldanyt, amit utanna szabadon fejleszthetunk. Ettol meg a szulo objektum marad es mellette egy leszarmaztatott objektumma valik. Tehat egy peldanyra ragaszthatunk egy uj valtozot vagy metodust es ezzel mar le is szarmaztattuk es hasznalhatjuk uj peldany letrehozasara. Sokkal egyszerubb es dinamikusabb mint a legtobb csak statikus tipusokat kezelo nyelv (pl. c++). A java ilyen szempontbol a ketto kozott van, mert van statikus tipus kezeles de lehet dinamikusan is kezelni (csak az bonyolult). Az android pl. mindkettot hasznalja meg a gui-ban is. (klasszikus eset: haromfelekeppen lehet egy gombra esemenykezelot rakni, egy statikus, egy dinamikus es egy runtime reflexiv modon, a harmadikat a legegyszerubb hasznalni es a legbonyolultabb volt a rendszer iroinak mogerakni a support kodot)
"JAVA szerver oldalra való, ott jól is érzi magát. Esetleg desktop kliensnek is alkalmas, ha nem zavar senkit a 3x memória fogyasztás, és 10x sebesség deficit ami mondjuk egy natívhoz képest szokott lenni."
Ezert is jo a jit-es forditott java. Az oracle fele verzio jit-elve csak 2x lassabb, mig a google fele verzio mar egyaltalan nem lassabb, mivel eleve nativ gepikodra forditanak. (arm vagy x86-os utasitasokra) A vicces az, hogy a ket rendszer atjarhato, de az oracle jogi okok miatt nem engedi.
Egyebkent bongeszobe szerintem a legjobb az android support lenne. Tehat ha az android-os alkalmazasok kepesek lennenek bongeszoben futni (akar html oldalba agyazva is), akkor nagyjabol hasznalhato lenne a technologia. Az android fele java api sokkal konnyebben hasznalhato es fejlettebb mint az oracle fele desktop java, raadasul hordozhato is. Mint ahogy android alatt egy java-s kod eleri a html oldalak objektum modelljet, ugy egy bongeszoben is a html oldalak alatt lehetne javascript helyett java. Tehat java programnyelv, de html-es gui-val. Android alatt meg a hozzaferesi jogok kezeleset is megoldottak, tehat egy adott alkalmazas (vagy oldal) kerhet es kaphat egyedi jogokat, viszont a felhasznalok dontik el, hogy mit engednek es mit nem. (pl. egy jatek tolem nem fog cimlista hozzaferest vagy hivas inditasi jogot kapni, de webkamera es audio felvetel jogot sem) -
Komolytalan #21 És akkor már nem bukott meg? Ezek a banki szoftverek tizenX éve készültek, nem cserélik le őket egyik napról a másikra. Más kérdés, hogy van aki pont a JAVA-s ebank miatt váltott számlavezető bankot, mivel az internetet is használó böngészőben már tiltólistán van (tudom, azóta javították, de van újabb hiba), 2 böngészőt meg azért használni, mert egyikkel bankol, másikkal meg böngész az egyszerűen kényelmetlen.
JAVA szerver oldalra való, ott jól is érzi magát. Esetleg desktop kliensnek is alkalmas, ha nem zavar senkit a 3x memória fogyasztás, és 10x sebesség deficit ami mondjuk egy natívhoz képest szokott lenni. -
Komolytalan #20 A lényegen nem változtat a dolog: a JS nem OOP. -
nagylzs #19 > Az meg hogy a html5 hozzáférjen a HDD-hez - erre mondják vidéken, hogy az b.szna be. Egyébként a java applet pont ilyen volt (na jó, kellett hozzá egy hamisított tanúsítvány is), és ez volt az egyik oka, hogy megbukott.
A java applet nem bukott meg. Tovább él JNLB (a la "java web start") formájában, és egész komoly cégek épülnek rá. Pl. banki rendszerek is. -
nagylzs #18 > OOP eleve ott kezdődik, hogy típusos a nyelv. Anélkül nemhogy több, hanem pontosan nulla OOP kritériumnak felelhet meg.
A típusosság és az osztályok megléte két különböző dolog.
Típusosság szempontjából vannak erősen típusos nyelvek, nem típusos nyelvek és gyengén típusos nyelvek (pl. objective c). Vannak keverékek és átmenetek is. Pl. object pascal nagyjából szigorúan típusos, de a szám típusú értékeket tudja keverni. Vagy van úgynevezett "duck-typing" ami azt mondja hogy "minden ami hápog az kacsa" (pl. Python).
Az "objektum orientáltság" feltétele az osztályok megléte és az öröklődés. Más kritériumok: egységbe zárás, és (jobb esetben) polimorfizmus. Ezeknek eleget tevő nyelvek objektum orientáltak.
Az már igaz, hogy több a típusos (és gyengén típusos) objektum orientált nyelv. De létezik nem típusos OOP nyelv is.
A JavaScript az konkrétan egyik kategóriába sem tartozik. A JavaScript az egy úgynevezett "objektum alapú" nyelv. Azért nem objektum orientált, mert hiányoznak belőle az osztályok. (Vannak benne beépített prototípusok, de valójában azok sem osztályok hanem objektumok.) Nincs benne rendes ("nagy könyv szerinti") öröklődés sem. Csak objektumok vannak, viszont azok megvalósítják az egységbe zárást, és (kicsit nyögve nyelősen) a polimorfizmust is.
Érdekes dolog például a smalltalk esete. A SmallTalk-ban vannak osztályok, de az osztályok is objektumok, és azoknak is van osztálya ami szintén objektum... Itt az a döntő, hogy létezik egy "o objektum A osztály példánya" reláció. Tehát mivel a nyelv definiálja az "osztály" fogalmát mint olyan, ezért objektum orientáltnak mondható.
A JavaScript nem definiál osztályokat, csak prototype-okat, de azok is csak objektumok.
További módokon is lehet oszályozni nyelveket. Például: tisztán objektum orientált: csak objektumok vannak benne. A SmallTalk ilyen. Vegyes/kevert nyelv: van benne más programozási eszköz is, nem csak objektum. Pl. Pascal vagy C++ ilyen (van benne eljárás és függvény is).
Szóval mielőtt ilyen elhamarkodott kijelentésekkel összezavarsz másokat, legalább nézz utána. -
#17
A böngészőfüggetlenség költői túlzás volt -
#16
Melóhelyen volt szerencsém HTML5-ben canvasos, javascript OOP (ha valakinek úgy tetszik hash tömbös) online bögészős albumszerkesztő szoftveren dolgozni és kifejezetten pozitívak a tapasztalataim. Könnyű debuggolni, felbontás, böngésző és platfom független. Elismerem hogy tesztelni kell minden böngésző és eszköz alatt, lehetnek eltérőségek amik néhány sorral orvosolhatóak, de legalább nem kell újraírni az egészet. Akinek nem tetszik használjon flasht, javat, silverlightot vagy amit akar -
Komolytalan #15 Attól hogy egy nyelvben a hash tömböt elnevezzük Objectnek, attól még nem lesz OOP. OOP eleve ott kezdődik, hogy típusos a nyelv. Anélkül nemhogy több, hanem pontosan nulla OOP kritériumnak felelhet meg.
Az meg hogy a html5 hozzáférjen a HDD-hez - erre mondják vidéken, hogy az b.szna be. Egyébként a java applet pont ilyen volt (na jó, kellett hozzá egy hamisított tanúsítvány is), és ez volt az egyik oka, hogy megbukott. -
#14
"hogy hozzáférjen a teljes HDDhez"
Adj egy spárgát... FELKÖTÖM MAGAM!
-
FoodLFG #13 javascript ? Lehet, hogy nem felel meg több OOP kritériumnak. pl nincs benne öröklődés (valamennyire áthidalható). De attól még zsírosan objektumokra épül. Én nem merném rá azt mondani, hogy nem OOP.
A HTML5-ben egyébként az a legnagyobb hiba, hogy nem engedték hogy hozzáférjen a teljes HDDhez. Pedig biztonsági szempontból meg lehetett volna oldani...
Jó lenne ha egy ilyen mögé jobban odaállna a google. A Chrome már így is majdnem egy komplett virtuális gép. Érdemes megnézni hogy miket építettek már V8 javascript engine-jükre. Pl nodejs. Jobban kéne neki ezt a desktop alkalmazás vonalat nyomni a HTML5-től függetlenül is. -
Komolytalan #12 FB elnöke éppen ma nyilatkozta, hogy a FB legnagyobb hibája volt a html5-ös kliens erőltetése mobil eszközön. Az hogy egy leíró nyelv, amelynek bizonyos részeit egy interpretált nem OOP scriptnyelv baszkurálja az minden, csak nem előremutató. Meg persze nem is böngészőfüggetlen, mert a fele böngészőgyártó a W3C mögé állt, fele meg a WHATWG mögé, szóval lóf.sz lesz ebből, nem egységes szabvány. -
Komolytalan #11 Mindenesetre nem 17 évente fejlesztenek rajta annyit, hogy verziószámot merjenek váltani (html 4.01 ha jól emlékszem 1999-es szabvány). -
bunny #10 A fő gond, hogy a w3c kb úgy működik, mint egy sóhivatal, és a böngészőgyártók megint ráuntak a tökölésre - mellesleg jogosan. Ha a W3C kicsit normálisabb sebességgel dolgozna már rég nem ezen rágódnánk, nem kellene 3 sok ugyanahoz hogy minden böngészőn jó legyen, stb. Vicc ez az egész "hivatal" dolog és nem csak itthon.