Dmitry - some great points there. A couple of differences between JavaScript's prototypical inheritance and classical inheritance: First, prototype assignment is dynamic which means custom types and inheritance can be modified at runtimes. Second true classes do not form part of the object model, whilst in JavaScript, everything including custom types are objects (except primitives blah blah blah). I find the second point can lead to obfuscation of custom types in JavaScript and thus requires more careful organization and documentation.
I'm not wild about JavaScript frameworks defining their own class objects. It seems like a lot of overhead to replicate Java/C++ (etc.) style concepts where actually prototypical type definition is both lean and fairly easy to grasp (once we unload all the stuff we learned from other languages). Angus On Dec 25, 11:51 am, "Dmitry A. Soshnikov" <[email protected]> wrote: > On 25.12.2010 2:46, fernando trasvina wrote: > > [...] > > > What crockford is trying to point is that you should not think as the > > new operator as the classical use of new > > you should think of it as the prototype pattern, > > Yes, but actually, there is no a big difference between "classical new" > and "prototypal new" (if I can use such a naming). > > In many languages, `new` is just a syntax construct to generate a new > object. Usually, not just an object, but the object of a some > /classification/. Again, absence or presence of the "class" concept in > the languages, does not affect the ability of the language to /create/ > and /classify/ objects. > > What is a big difference in that how do you call the /sugar/ for > /creation/ and /classification/ of your objects? Again, you may sugar it > in a special syntax construct and to name it "class". Or you may use the > simplest form of the generation -- just a function which creates and > returns an object and sets the classification tag (to be able > distinguish somehow these object from other with the similar properties). > > > and this is not in conflict in any way with the Object.create method > > > Object.create is good for creating inheritance hierarchies > > new is good for creating instances that need an initializer function in > > this case known as constructor function. > > Again, the main difference of the classical and prototypal models in the > /classified/ (classical) and /unclassified/ (prototypal) concepts. And > all the other differences are not so essential. It's very easy choice > (regardless in which system you program): > > 1. If you don't need to classify your object(s) (and the whole > inheritance hierarchic in case you nave more than one object in it) -- > use /unclassified/ pattern (e.g. Object.create). > > Indeed, why do you need a class if you just want to use a complex object > with some properties and reuse the code (inherit) from another object? > Of course prototypal (unclassified) approach is the way. > > 2. If you need classified objects -- use /classified/ pattern. In > ECMAScript in the simplest way it's achieved via using a /constructors/ > (you may use your own factory though). > > Really, why do you should use unclassified approach if you decide that > /these 100 objects/ are needed to be /grouped/ (classified) by some > /sign/? The simplest example again, is a UI button component. > > > with the case of super you don't need it because you cannot (even when > > there are implementations that provide a way to do it) mutate the proto > > attribute of an object, so you always know what object you come from. so > > > A<- B (B inherits from A) just call A.methodName from B.methodName > > A = function(){} > > A.prototype.methodName = function(){ > > //code > > }; > > > B = function(){} > > B.prototype = new A(); // many techniques here to avoid constructor > > function being executed if you want to > > B.prototype.constructor = B; > > B.prototype.methodName = function(){ > > //your code > > A.prototype.call(this[, ArgumentList]); > > }; > > Having written several such classifications you may want to encapsulate > them in some sugar (a meta-constructor e.g. which creates other > constructors and sets correctly needed inheritance hierarchy regardless > concrete -- A, B, etc, names). > > > you should follow the language idioms and not invent new ones because you > > don't understand something or because you don't like it, neither because > > you are trying to port the idioms from other languages. > > well that is my point of view. > > P.S.: > > That's funny, but with JavaScript a one strange thing is happened in its > historical way. First (long time ago), programmers (which didn't read > the common OOP theory, but just learned the wide-spread C++ > implementation with classes) couldn't get quickly the concept of > "prototypes" as an /alternative/ OOP paradigm, and as a result named > prototypal approach as "not enough serious". > > Then who understood the prototypes did IMO (!) a one big mistake. They > also (as the first group who didn't clarify OOP in general) for some > reason started to ennoble the prototypal approach as something > privileged (what can understand only esoteric programmers and of course > not those stupid C-programmers limited with a class-based paradigm). In > fact, there was (is) /nothing/ complex in this alternative technique, > but from that era the massive "classes are not needed!", "don't use > classes", etc are started on many forums and groups on JS. > Unfortunately, denying classes these programmers also couldn't (and some > cannot until now) get fact that the "class" is not about the syntactic > sugar in the language for creation objects, it's about the ability to > /classify/ (and how it's made -- with a sugar for that or not -- does > not matter much). > > Of course the main idea was to let programmers easier and quicker to > understand how prototypes work (i.e. there are only prototypes, don't > think in class paradigm), but as a side-effect, repeat, unfortunately, > the concept of a "class" was unfairly named as non-needed. However, it > can sound funny, but this concept is used in JS itself to classify the > objects ;) > > Again, ECMAScript is a prototype-based language. But being such a > language, it has sugar for /classified generation/ of objects (and > classified programming) wit using constructors. Moreover, as I said, ES > itself classifies its objects with [[Class]] classification tag (every > object has this internal property). At the same time, it has tools for > unclassified programming (Object.create, etc). > > So, classes are not bad and moreover, it's not about languages. It's > about ideology -- to classify or not to classify. And only you decide > what is better for you current system. And it's great that JS allows > both of approaches (in contrast with languages where you cannot create > an object until define its class). So I don't see a big reason (if you > need a classified system) why you should avoid them and avoid even > thinking it the paradigm of classes. OTOH, if you need unclassified > usage of objects, ES has all tools for that. > > P.S.[2]: there is another modern pure prototype-based language which is > used today for scripting games -- Lua. I recommend it also to play. > There's no even (in contrast with JS) sugar for classified programming, > you should use simple functions with returning objects and if you want > sets classification tags your self and set the inheritance (prototype) > link also manually. > > P.S.:[3] to see how this sugar with constructors may be further sugared > for classified programming see CoffeeScript's > implementation:http://jashkenas.github.com/coffee-script/#classes > > Again, Python's classes are also just a sugar. Python is very similar to > ECMAScript. But we hear that Python is a class-based and JS is a > prototype-based? Why? > > Dmitry. > Dmitry. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
