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.
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?
>
> 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 not for showing the way to inherit.
besides this is the way ecma reccomends to inherint (decorate actually).
>
>> 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]
--
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]
