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.
