On Dec 25, 2010, at 9:24 PM, Michael Haufe (TNO) wrote:
> On Dec 25, 6:19 pm, fernando trasvina <[email protected]> wrote:
>> On Dec 24, 2010, at 8:22 PM, Michael Haufe (TNO) wrote:
>>
>>> On Dec 24, 5:46 pm, fernando trasvina <[email protected]> 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, and this is not in
>>>> conflict in any way with the Object.create method
>>
>>> I don't see where he points that out.
>>
>> watch his conferences specially crockford on javascript and you will see
>> what he thinks and the examples he uses around object.create
>
> I know very well what he thinks, both good and ill on the topic and
> yes, Object.create does act differently in its approach and the
> results.
>
>>>> 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.
>>
>>> I don't see how Object.create wins you much in this regard alone over
>>> a constructor. it breaks the instanceof relationship, which means you
>>> have to check for the existence of a members manually, or by using the
>>> isPrototypeOf method which could be shadowed.
>>
>> You dont get the constructor function when creating the inheritance
>
> Nor do you get a robust hierarchy that can be checked easily which was
> my point. Object.create is only good for copying interfaces, not for
> any form of enforceability.
i agree on this too so no further comments
>
>>>> 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
>>
>>> What does a super call have to do with proto? Calling a method of a
>>> parent and augmenting it for the more specific instance isn't
>>> something never needed.
>>
>> super is implemented in all languages as a way to call the object parent
>> class method implementation, so super is not needed in javascript did you
>> check the examples provided previously?
>
> This is just simply false. First you say super is not needed because
> proto can't be mutated then you say its not needed because its already
> implemented...
yes it is implemented but marked already as deprecated and not supported on
es5 so you should avoid that even though right now it is possible
>
>>>> you should follow the language idioms and not invent new ones because you
>>>> don't understand something or because you don't like it,
>>
>>> Since when was there an idiom? Inheritance isn't even consistent in
>>> the language.
>>
>> ohh it is consistent is always achieved by creating a new instance of Object
>> and pointing its proto attribute to the inherited object (check the ecma
>> documentation)
>
>>>> neither because you are trying to port the idioms from other languages.
>>>> well that is my point of view.
>>
>>> At no point in this discussion have I advocated porting some other
>>> language's inheritance model.
>>
>> when trying to implement super
>
> And yet just a few lines ago you said super was already implemented in
> all languages. Hard to reply to a point when a consistent one isn't
> presented. You seem to be trying to imply something about my position
> but I can't quite figure out what it is due to the English barrier.
super is implemented on many other languages but not in javascript yet
you can search around and there are many implementations of super around.
but it is not supported on the language, there is no (that i know of)
any serious proposal to integrate this on the language yet. i would say that on
es5 there is no mutable proto
so you should always know super, if no there is getPrototypeOf(object)
to get to the prototype and run the method in the current context, but with
complex hierarchies this may get
in to too much recursion.
in concrete my point is, do not implement super, use direct call, all
implementations i have seen so far get into performance issues.
>
> --
> 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]
