On 26.12.2010 3:51, fernando trasvina wrote:
On Dec 25, 2010, at 1:51 PM, Dmitry A. Soshnikov 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).
Actually when you run new ConstructorFunction() you get the
function being executed
When you run Object.create ObjectPrototype no function gets executed
This is the main difference.
No, excuse me, you didn't understand the question (my fault seems). I
meant -- what is the difference between of using different sugars for
exactly classified programming. I.e. whether you use `class A ... end`,
or `function A ... end`? I.e. why do you think JS doesn't support
classes? How do you describe what "class" is at all (not in JS, but in
general)?
And regarding unclassified programming with Object.create -- I see you
mention a some technical difference ("function is executed, function is
not executed"). Yes, this is fair. Though as I said (and think) that the
main difference is exactly ideological: in classified approach (i.e. a
linear chain of inheritance, ability to group objects by some
classification tag, make checks on this tag, etc) and unclassified
(inheritance chain is unclassified, but /chaotic/ -- that is, "inherit
from what I want", no classification tag is needed).
And from this viewpoint, JS supports both approaches -- prototypal and
classical. Actually, what every (prototype-) delegation-based language
does. As I mentioned, with prototype-based language it's easy to program
in class-based paradigm if needed. But not a vice-versa.
so when you "inherit" from an object you can obtain 2 different
objects depending on what the Constructor function object does
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).
I would say that this does not depends on your approach rather should
be on what you need, do you need to initialize your new object or no?
Yes, also true. If you don't chain prototypes with using constructors,
then a single constructor is just an /initialiser/ as you fairly notice.
But what I mean, is exactly building a hierarchic linear inheritance
chain which is specified. In contrast with unspecified approach with
Object.create if needed. Because if you talk about a single initialiser
you may do it also for Object.create just surrounding it in a function.
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).
this example was to point that there is no need to implement super
when you know where you are "inheriting" from
But isn't it convenient not to couple with exact names of variables? In
this case you may just use a some standard name (e.g. `super` or
`parent` or whatever you want -- but /standard/) to refer a parent
object in the hierarchy.
not for showing the way to inherit. besides this is the way ecma
reccomends to inherint (decorate actually).
ECMA you mean examples in docs on the official site or the spec? If the
later, I didn't see this recommendation. Though, of course it's a
wide-spread known way.
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]
