method method

[Jens Müller]

In JS:TGP, Crockford defines a method called method:

"Throughout the book, a method method is used to define new methods.
This is its definition:

Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
};

It will be explained in Chapter 4."

So far, so good.

Then, in Chapter 4 in the section "Augmenting Types" he goes on:

"For example, by augmenting Function.prototype, we can make a method
available to all functions:

Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
};

By augmenting Function.prototype with a method method, we no longer have
to type the name of the prototype property. That bit of ugliness can now
be hidden."

Then in the section "Module" he uses it to augment String.

String.method('deentityfy', function () { ... return function () {
....}; }; ());


and then uses it as follows:

document.writeln('<">',deentityfy());


To what exactly is deentityfy added (and why is method available there),
and how exactly does it happen that deentityfy on a String literal gets
called?

- Jens

 

[Thomas 'PointedEars' Lahn]

"For example, by augmenting Function.prototype, we can make a method
available to all functions:

Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
};

By augmenting Function.prototype with a method method, we no longer have
to type the name of the prototype property. That bit of ugliness can now
be hidden."

Then in the section "Module" he uses it to augment String.

String.method('deentityfy', function () { ... return function () {
...}; }; ());


and then uses it as follows:

document.writeln('<">',deentityfy());


To what exactly is deentityfy added (and why is method available there),
and how exactly does it happen that deentityfy on a String literal gets
called?

There is a typo: the comma before deentityfy() needs to be a dot, making
deentityfy() a call to a method of a String instance that is being created
implicitly from the primitive string value when the property access syntax
is being evaluated (called a "hull object" ["Hüll-Objekt"] by Georg Maaß in
de.comp.lang.javascript around 2000 CE, AFAIK one of the first ones to
describe and utilize that feature of ECMAScript implementations).

The method deentityfy() is being added to the value that String.prototype
refers to before, which is (WLOG) the prototype object of all String
instances (the object next in their prototype chain). This could be
represented in a graph as follows:

 

[Jens Müller]

Am 30.06.2011 02:17, schrieb Thomas 'PointedEars' Lahn:

"For example, by augmenting Function.prototype, we can make a method
available to all functions:

Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
};

By augmenting Function.prototype with a method method, we no longer have
to type the name of the prototype property. That bit of ugliness can now
be hidden."

Then in the section "Module" he uses it to augment String.

String.method('deentityfy', function () { ... return function () {
...}; }; ());


and then uses it as follows:

document.writeln('<">',deentityfy());


To what exactly is deentityfy added (and why is method available there),
and how exactly does it happen that deentityfy on a String literal gets
called?

There is a typo: the comma before deentityfy() needs to be a dot,

Yes, sorry.

making
deentityfy() a call to a method of a String instance that is being created
implicitly from the primitive string value when the property access syntax
is being evaluated (called a "hull object" ["Hüll-Objekt"] by Georg Maaß in
de.comp.lang.javascript around 2000 CE, AFAIK one of the first ones to
describe and utilize that feature of ECMAScript implementations).

The method deentityfy() is being added to the value that String.prototype
refers to before,

Yes. But how? Why does String.method exist, when method has been added
to _Function_.prototype?

OK, I think I got it. String is a function object, that's why
Function.prototype.method is available as String.method. Right?

After that, method() is used to add methods to "proper" functions, not
constructors. For example, he defines a curry() method. There it is
immediately apparent that by adding it to Function.prototype, you can
now call curry on any function.

If I understand correctly, String() is constructor, that's why it
creates objects that have String.prototype as prototype. IMO, this would
have deserved a sentence of explanation from Crockford, especially since
he discourages the constructor invocation pattern, and that is, AFAIK,
the only place where he mentions that

"If a function is invoked with the _new_ prefix, then a new object
will be created with a hidden link to the value of the function's
_prototype_ member, and _this_ will be bound to that new object."

The implicit creation of a String instance from the primitive
string value, which is not explained, adds to the confusion.

Thanks for your explanation though.

- Jens

which is (WLOG) the prototype object of all String
instances (the object next in their prototype chain). This could be
represented in a graph as follows:

.
.
.
[object Object]<-------Object.prototype
.
/_\
|
|
|
[object String]<-------String.prototype
.
/_\
|
|
|
[object String]

(Legend: ---|> inheritance,<---- reference)

 

[Jens Müller]

Am 30.06.2011 03:49, schrieb Stefan Weiss:

There is a typo: the comma before deentityfy() needs to be a dot, making
deentityfy() a call to a method of a String instance that is being created
implicitly from the primitive string value when the property access syntax
is being evaluated (called a "hull object" ["Hüll-Objekt"] by Georg Maaß in
de.comp.lang.javascript around 2000 CE, AFAIK one of the first ones to
describe and utilize that feature of ECMAScript implementations).

The concept of automatic conversion from primitive values to temporary
objects was adopted from Java, where it's called Autoboxing (and
Unboxing, for the reverse). The term Hüllobjekt is a very plastic and
appropriate translation; it can also be found in several German
Java-related texts. It's quite possible that Georg Maaß was one of the
first to use it in a JS context.

The only problem I have with the term is that Hülle also means closure.

- Jens

 

[Thomas 'PointedEars' Lahn]

Am 30.06.2011 02:17, schrieb Thomas 'PointedEars' Lahn:

[Crockford's Function.prototype.method()]
Then in the section "Module" he uses it to augment String.

String.method('deentityfy', function () { ... return function () {
...}; }; ());


and then uses it as follows:

document.writeln('&lt;&quot;&gt;',deentityfy());


To what exactly is deentityfy added (and why is method available there),
and how exactly does it happen that deentityfy on a String literal gets
called?

There is a typo: the comma before deentityfy() needs to be a dot,

Yes, sorry.

Ah, so the typo is not in the book as I assumed.

[…]
The method deentityfy() is being added to the value that String.prototype
refers to before,

Yes. But how? Why does String.method exist, when method has been added
to _Function_.prototype?

OK, I think I got it. String is a function object, that's why
Function.prototype.method is available as String.method. Right?

Yes, although I prefer the term "Function instance" (or "Function object",
if need be, but that is ambiguous) instead of "function object" here as it
corresponds directly with the ECMAScript Language Specification [ES5],
section 15.3.5.

After that, method() is used to add methods to "proper" functions, not
constructors.

No. If you read the source code of the method() method carefully –

Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
};

– you will observe that there is the following statement:

this.prototype[name] = func;

Meaning that a property that has the value of the argument `name' as name
(sic!) is being created (or overwritten, or overridden as you will see
shortly) on the object that the `prototype' property of the object referred
to by `this' refers to:

,-------------------.
this--->| [object Function] |
|___________________| ,--------------------.
| + prototype ------|--->| [object Function]¹ |
`-------------------' |____________________|
| … |
`--------------------'

______
¹ That native prototype objects have the same [[Class]] as their
associated constructors can be confusing, but is correct nevertheless
([ES5], section 15).

`this' is a context-sensitive keyword (ibid., section 7.6.1.1); it refers to
the "this value" (ibid., 13.2.2). The "this value" is provided by the
caller (ibid., 13.2.1). In this case, it is a reference to the object that
the method was called of.

As you noted correctly, `String' is a reference to a Function instance
(ibid., section 15). That is so because it is a constructor *as* *well*
(ibid., 4.3.4 and 15.5.2). Function instances inherit from the Function
prototype object (ibid., 15.3.3) through the prototype chain; the same
mechanism that applies to String instances (as I explained in my previous
posting):

 

[Thomas 'PointedEars' Lahn]

There is a typo: the comma before deentityfy() needs to be a dot, making
deentityfy() a call to a method of a String instance that is being
created implicitly from the primitive string value when the property
access syntax is being evaluated (called a "hull object" ["Hüll-Objekt"]
by Georg Maaß in de.comp.lang.javascript around 2000 CE, AFAIK one of the
first ones to describe and utilize that feature of ECMAScript
implementations).

The concept of automatic conversion from primitive values to temporary
objects was adopted from Java, where it's called Autoboxing (and
Unboxing, for the reverse). The term Hüllobjekt is a very plastic and
appropriate translation; it can also be found in several German
Java-related texts. It's quite possible that Georg Maaß was one of the
first to use it in a JS context.

You are mistaken. Autoboxing was not introduced to the Java language before
J2SE 5.0 (2004-09-30) [1]. ECMAScript implementations had the feature I
described since the very beginning (1996-03) [2]. If anything was adopted
here, it was the other way around.

Further, autoboxing/unboxing requires you to declare and use a variable in
Java; since ECMAScript implementations (except those of Edition 4) by
contrast are loosely typed, you do not need to do that: "a".charCodeAt(0),
Math.PI.toString().replace(".", ","), and behold, (42.23).toString(11).

[...] Crockford's method() method is poorly named. Methods should be
using verbs in their names/identifiers, like defineMethod().

I agree 100%. Not only is it poorly named, it's as useful as a hole in
the head.

I would not go that far.

"deentitify" isn't much better, as names go.

Full ACK.

IMHO, Crockford deserves credit for a number of things, not least among
them the JSON format and the idea of a JS linter,

The idea of a linter is commendable, however JSlint imposes too many of
Crockford's misguided notions of how script code should be written for my
taste (among them, to use `window' as substitute container for global
variables).

but it's getting more and more frustrating to watch the blind hero worship
of his fans. Some of his recommendations and actions are plainly
detrimental to his followers. I'm going to stop now, before this becomes a
Crockford rant.

Full ACK.

_____
[1]
<http://download.oracle.com/javase/1.5.0/docs/guide/language/autoboxing.html>
[2] <http://e-pla.net/documents/manuals/javascript-1.0/builtin.html>

 

[Thomas 'PointedEars' Lahn]

Am 30.06.2011 02:17, schrieb Thomas 'PointedEars' Lahn:

Jens Müller wrote:

Function.prototype.method = function (name, func) {
this.prototype[name] = func;
return this;
}; [..]
The method deentityfy() is being added to the value that
String.prototype refers to before,

Yes. But how? Why does String.method exist, when method has been added
to _Function_.prototype?

OK, I think I got it. String is a function object, that's why
Function.prototype.method is available as String.method. Right?

Yes, that's correct.

After that, method() is used to add methods to "proper" functions, not
constructors.

It's available on _all_ functions, constructor or not.

If I understand correctly, String() is constructor, that's why it
creates objects that have String.prototype as prototype.

It can be a constructor, but it doesn't have to be. Whether a function
is a constructor or not depends _only_ on how it is called.

That is one way to look at it. However, you *cannot* use an object as a
constructor that does not implement [[Construct]].

There's no way to tell if a function is a constructor or not by just
looking at its definition.

If the definition includes the formal specification, then there is.

I've been using JS for a long time now, and I've never accidentally
forgotten "new" when it was required.

The key word here is "required".

Never heard of anyone else who did, either, except for Douglas Crockford.
In short: use "new" when appropriate, but don't be afraid of it. This is
not a common cause of errors.

Depends. Try

typeof new String("foo")

vs.

typeof "foo"

and be surprised, especially when you come from Java. Even more "weird":

var b = new Boolean(false);

if (b)
{
/* will always be executed because object references type-convert to
true */
}

If that is what Crockford is referring to, then he is correct, of course.

If you're really paranoid about it, you can write your constructors in a
way that they will always return an object, even when called without the
"new" operator. Some people write their code like that, some don't. It's
a matter of preference.

Not only that. It is an underrated fact that constructors can be factories;
they can *return* references to objects that do not have that constructor as
constructor.


PointedEars

 

[Lasse Reichstein Nielsen]

The concept of automatic conversion from primitive values to temporary
objects was adopted from Java, where it's called Autoboxing (and
Unboxing, for the reverse).

Historically, I doubt that was where it was adopted from.
Autoboxing was introduced in Java 5, released in 2004.
The automatic wrapper object creation in JavaScript has been there since
.... I guess version 1.0 (1995), but definitly since ECMAScript 1.0 in
1997.



/L

 

[Thomas 'PointedEars' Lahn]

Historically, I doubt that was where it was adopted from.
Autoboxing was introduced in Java 5, released in 2004.
The automatic wrapper object creation in JavaScript has been there since
... I guess version 1.0 (1995), but definitly since ECMAScript 1.0 in
1997.

JavaScript 1.0 was introduced with Netscape Navigator 2.0 (1996-03),
otherwise you are correct.


PointedEars

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

JavaScript 1.0 was introduced with Netscape Navigator 2.0 (1996-03),
otherwise you are correct.

True. I think I was mislead by a list of JavaScript versions that was
based on the December 1995 beta release, but it wasn't properly
JavaScript version 1.0 before the Nescape 2.0 release.

/L

 

[John G Harris]

If that is what Crockford is referring to, then he is correct, of course.

<snip>

He is referring to the fact that if you mean to write
var a = new Thing();
and mistakenly write
var a = Thing();
instead then you won't get a new object.

He then says that it was a mistake to allow constructors to be called as
ordinary functions. He doesn't mention the example in Netscape's
documentation where this is the proper thing to do. (Well, it would
spoil his thesis if he allowed himself to notice it).

In other words he is incorrect, of course.

John

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

<snip>

He is referring to the fact that if you mean to write
var a = new Thing();
and mistakenly write
var a = Thing();
instead then you won't get a new object.

He then says that it was a mistake to allow constructors to be called as
ordinary functions. He doesn't mention the example in Netscape's
documentation where this is the proper thing to do. (Well, it would
spoil his thesis if he allowed himself to notice it).

In other words he is incorrect, of course.

ACK, thanks. I am sorry to say, I am less and less convinced that this book
is even worth reading (much less buying). Crockford appears to have lost
it.


PointedEars

 

[Elegie]

On 01/07/2011 21:09, Thomas 'PointedEars' Lahn wrote :

Hello Thomas,

ACK, thanks. I am sorry to say, I am less and less convinced that this book
is even worth reading (much less buying). Crockford appears to have lost
it.

I have not read Mr. Crockford's book, so cannot tell much about it.
Still, this makes me think of "The Little Schemer", Fourth Edition, by
Daniel P. Friedman and Matthias Felleisen.

Mr. Crockford has praised this book quite a lot, and lots of his
research was focused on implementing ideas seen in the book. After all,
javascript is a functional language (apart from the tail-recursion
thing), so the patterns described for Scheme should also work for
javascript.

I happened to have read that book last year. If you do not know about it
yet, then I would like to suggest you add it on your to-read list. Apart
from the Scheme language (which I have little interest in at the
moment), the book teaches how to think recursively, gives you the basics
about functional programming, using a Q&A approach which is as enjoyable
as it is effective.

After reading it, I realized I had made some interesting progress in
many programming languages, and also - a nice bonus! - in constructing
regular expressions (which should not be that unexpected, given the
nature of regular expressions).

Kind regards,
Elegie.

 

[Elegie]

On 02/07/2011 00:19, Stefan Weiss wrote :

Hello Stefan,

All in all, The Good Parts is an interesting book. At the time it was
published, it certainly made a big impression on a lot of JS
programmers. IMHO, the general code quality on the web has improvement
because of it. I enjoyed reading the book, and I've recommended it to
some of my colleagues, but I wish everybody would stop taking it so
seriously (and that definitely includes its author).

Thank you for your well-constructed comments about Mr. Crockford's book.
You have definitely raised my interest (all the more you have clearly
balanced what you liked or not about the book), and I may give it a try
soon.

Yes, I read that one, too. It's a wonderful way to teach. The Little
Schemer simply can't be read and understood without doing every single
exercise (mentally). You never get any explanations about a new concept
before you are quizzed about it. Things like this -

Q: Write the function lat? using some, but not necessarily all, of
the following functions:
car cdr cons null? atom? and eq?

A: You were not expected to be able to do this yet, because you are
still missing some ingredients. Go on to the next question.
Good luck.

- are great fun, because they make you review everything you've learned
before you give up and decide that you can't answer the question.
I remember when I read the book, I kept going "one more, then I'll turn
off the light"... "okay, just one more"... "okay, maybe one last"...
Like solving puzzles instead of reading a text book.

I had a similar experience. I mostly read it while commuting (except for
the last part, especially the Y combinator, for which I needed to
concentrate at home), and I admit to have missed my station many times,
as I was building the algorithms in my head and would not pay attention
to my surroundings

That was really satisfying, not only because of the progress I made, or
simply the fun I had, but also because I tested first-hand how creative
people could be when teaching, especially with a printed media which
does not allow user interactions (impossible to calibrate the teaching
with the student response).

Cheers,
Elegie.

 

[John G Harris]

I've read it, it's a decent book. It's not so crammed full of errors as
the occasional reviews and comments in this group would make you
believe, but neither is it the Bible.

<snip>

Oh yes it is. Some of his statements are seriously misleading, and it
appears that he hasn't a clue how inheritance works in main-stream OO
languages.

car cdr cons

<snip>

Oh Gawd! Keywords named for hardware registers in an obsolete computer.

John

 

[Michael Haufe (&quot;TNO&quot;)]

  <snip : about Scheme>>     car cdr cons

  <snip>

Oh Gawd! Keywords named for hardware registers in an obsolete computer.

cons not included