By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,014 Members | 1,020 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,014 IT Pros & Developers. It's quick & easy.

Use of "new" deprecated

P: n/a
In the Yahoo Interface Blog, Douglas Crockford wrote about javascript:

"So the rule is simple: The only time we should use the new operator is to
invoke a pseudoclassical Constructor function. When calling a Constructor
function, the use of new is mandatory."

http://yuiblog.com/blog/2006/11/13/j...hardly-new-ya/
Nov 14 '06 #1
Share this Question
Share on Google+
7 Replies


P: n/a
VK
"So the rule is simple: The only time we should use the new operator is to
invoke a pseudoclassical Constructor function. When calling a Constructor
function, the use of new is mandatory."
http://yuiblog.com/blog/2006/11/13/j...hardly-new-ya/
So I guess we have to say bye-bye to date/time operations in JavaScript
:-)

But leaving out the author's polemic excitement which takes hin
overboard in some passages: I may agree that a code having both
Something.prototype.method = function(){...
and
new Something()
as a bit like a person trying to speak French and German at once.
JavaScript is flexible anough to be whatever one wants it to be: but it
is not a reason to produce hermaphrodites :-)

Nov 14 '06 #2

P: n/a
VK wrote:
<snip>
... I may agree that a code having both
Something.prototype.method = function(){...
and
new Something()
as a bit like a person trying to speak French and German
at once.
<snip>

Your failure to comprehend the role of prototypes in javascript has
been painfully obvious for some time. The use of constructor functions,
the assignment of values to the properties of those constructor's
prototypes and the creation of objects by applying the - new - operator
to the constructor is the *natural* form of OO work in javascript. So
much so that anything else needs context-related justification and so
should only be the result of an informed decision (thus the person
adopting any alternative form should be able to clearly state why they
are doing it).

That you see doing what is natural and sensible in javascript as being
"trying to speak French and German at once" explains why the 'OO'
examples you post here are so very poor. And your ongoing refusal to
explain when asked why you are doing the perverse things you do in code
is the consequence of your not understanding the langue sufficiently to
see that you should be doing something else.

Richard.

Nov 14 '06 #3

P: n/a
VK
... I may agree that a code having both
Something.prototype.method = function(){...
and
new Something()
as a bit like a person trying to speak French and German
at once.
Your failure to comprehend the role of prototypes in javascript has
been painfully obvious for some time.
As you may notice I don't and I never did conduct some silly
"anti-prototype" and "pro-constructor" campaigns. But in response of
someone's private opinion I'm entitled to express my own private
opinion: without asking first a permission to speak up from Mr.
Cornford
;-)
The use of constructor functions,
the assignment of values to the properties of those constructor's
prototypes and the creation of objects by applying the - new - operator
to the constructor is the *natural* form of OO work in javascript. So
much so that anything else needs context-related justification and so
should only be the result of an informed decision (thus the person
adopting any alternative form should be able to clearly state why they
are doing it).
The quoted blog article is obviously (to me) addressed to Cx/Java
programmers trying their feet in JavaScript. In such context it can be
understandable (though not suggested IMHO) to overstress the
prototypical nature if the JavaScript inheritance.
>From the other side (IMHO again) the whole value of the inheritance in
JavaScript is overly exaggerated. Without encapsulation limits it can
be classy inheritance, prototype inheritance, factory inheritance
(suggested in the blog and for some reason identified by author as a
prototype-only feature). For sake of it: it can be even string-based
inheritance over new Function(string) chains. I never saw the latter
implemented (thanks God :-) but technically possible.

The power of JavaScript is not in some inheritance (screw it at all,
tell me when the last time it was so important to know to you where is
the given object method coming from: from the immediate constructor,
from some object three levels down or from the ground zero object?)

The power of JavaScript is its flexibility and ability to be whatever
you want (up to some reasonable extend of course). An attempt to
squeeze JavaScript into some brickwall borders cannot be supported by
myself.

At the same time I don't see a reason to make JavaScript "everything at
once" in each code segment. But it's again IMHO.

Nov 14 '06 #4

P: n/a
VK wrote:
>>... I may agree that a code having both
Something.prototype.method = function(){...
and
new Something()
as a bit like a person trying to speak French and German
at once.
Your failure to comprehend the role of prototypes in javascript has
been painfully obvious for some time.

As you may notice I don't and I never did conduct some silly
"anti-prototype" and "pro-constructor" campaigns. But in response of
someone's private opinion I'm entitled to express my own private
opinion: without asking first a permission to speak up from Mr.
Cornford
;-)
<snip>

You have never needed my permission to make yourself look like a fool
in public, nor may assistance. Your finding the notion of the two
constructs you cited above being unsuited to each other's company
betrays a fundamental lack of understanding of javascript. While your
opinion is 'informed' by such a deficit of understanding it will remain
worthless.

Richard.

Nov 14 '06 #5

P: n/a
In article <11**********************@k70g2000cwa.googlegroups .com>, VK
<sc**********@yahoo.comwrites
>"So the rule is simple: The only time we should use the new operator is to
invoke a pseudoclassical Constructor function. When calling a Constructor
function, the use of new is mandatory."
http://yuiblog.com/blog/2006/11/13/j...hardly-new-ya/

So I guess we have to say bye-bye to date/time operations in JavaScript
:-)

But leaving out the author's polemic excitement which takes hin
overboard in some passages: I may agree that a code having both
Something.prototype.method = function(){...
and
new Something()
as a bit like a person trying to speak French and German at once.
JavaScript is flexible anough to be whatever one wants it to be: but it
is not a reason to produce hermaphrodites :-)
Are you really saying that you would never use hasOwnProperty because
the function is a property of a prototype object, not a property
attached by you in your constructor ?

John
--
John Harris
Nov 14 '06 #6

P: n/a
VK

John G Harris wrote:
Are you really saying that you would never use hasOwnProperty because
the function is a property of a prototype object, not a property
attached by you in your constructor ?
So far the only use (but very useful one) I've found for hasOwnProperty
is to make my scripts to work being surrounded by ugly written
Object/Array augmenting 3rd part libraries. "Misfortunately" this
execution environment becomes nearly standard recently.

Nov 14 '06 #7

P: n/a
In article <11**********************@e3g2000cwe.googlegroups. com>, VK
<sc**********@yahoo.comwrites
>
John G Harris wrote:
>Are you really saying that you would never use hasOwnProperty because
the function is a property of a prototype object, not a property
attached by you in your constructor ?

So far the only use (but very useful one) I've found for hasOwnProperty
is to make my scripts to work being surrounded by ugly written
Object/Array augmenting 3rd part libraries. "Misfortunately" this
execution environment becomes nearly standard recently.
VK uses hasOwnProperty so he does, indeed,
>speak French and German at once.
John
--
John Harris
Nov 15 '06 #8

This discussion thread is closed

Replies have been disabled for this discussion.