On Dec 26, 2010, at 4:12 AM, Dmitry A. Soshnikov wrote:
> 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.
Very clear explanation :). yes indeed everything you say is correct.
>
>>
>> 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.
yes agree completely :)
>
>>>
>>> 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.
Yes you are correct, it does not look nice. the risk here is that someone
replaces the value of A to another thing and give you another method that you
were not expecting. (never happened to me but possible).
what i generally do when in risk of having this problem is set B.superClass = A
at declaration time. Like ES uses the value not the variable, the later change
to the value of A would not matter.
A = function(){};
A.prototype.methodName = function(){
console.log('from A')
};
B = function(){};
B.superClass = A;
B.prototype = new A();
B.prototype.constructor = B;
B.prototype.methodName = function(){
console.log('from B')
this.constructor.superClass.prototype.methodName.call(this);
};
(new B()).methodName();
now this.constructor.superClass.... its longer but its consistent and i like it
because it maintains very clearly the ES style and does not need to implement a
new dsl.
>
>> 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.
Before ES5 this was the only way to achieve it. without a dsl tha internally
all of them use some way to achieve the same. but i dont think we have a
conflict with this matter i agree with you.
>
> 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]
--
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]
