Prev: get or post?
Next: appendChild that fails in Safari, but succeeds in FF, Camino
From: Scott Sauyet on 25 Jan 2010 20:20
On Jan 25, 4:59 pm, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
> Scott Sauyet wrote:
>> Thomas 'PointedEars' Lahn wrote:
[ much relevant discussion deleted ... see earlier messages ]
>>> There is no good reason why the approach above it should not work with
>>> this code.  [ ... ]
>
>> I guess it depends upon what you mean by "work".  But perhaps I wasn't
>> being clear.  I believe that for the object derived from this:
>
>>     {"firstName": "Scott", "lastName": "Sauyet"}
>
>> the fullName function will return "Scott Sauyet (undefined)", which
>> may or may not be acceptable.
>
> Yes, but I think it goes without saying that a function should only be
> transferred for use as a method if it fits the purpose at hand.  That
> includes that all the properties of the calling object that the method
> reads from when called are there on the calling object, and that all the
> properties of the calling object that the method writes to when called are
> not read-only or otherwise used on the calling object.

If you are going to use that technique, obviously you have to live
with these limitations. But the OP was looking to copy the entire
Person.prototype to the new Object, which I took to mean that these
Objects should be substitutable for an object created from Person.

The technique I suggested is more general. But it could well be
overkill, and if there are performance concerns, then copying the
function references is likely the best bet.

>>> [Constructor-based approaches] are also a lot less runtime-efficient.
>
> What factors contribute to this?
>
> Mostly object creation and method calls, as compared to operations.  We can
> also safely assume that if the prototype method is called it takes slightly
> longer for it to be looked up in the prototype chain of the instance.
>
> That is not to say these approaches you suggested are nonsense; they are
> just not as efficient, and they might easily be overkill here.

Thank you. I really need to learn more about performance concerns in
the various ES implementations.

-- Scott
From: Thomas 'PointedEars' Lahn on 25 Jan 2010 22:48
Scott Sauyet wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Scott Sauyet wrote:
>>> This could then take advantage of the reviver parameter to JSON.parse
>>> wherever it's avaialable.
>>
>> I have just read about the `reviver' _argument_, thanks for the hint:
>>
>> <http://msdn.microsoft.com/en-us/library/cc836466%28VS.85%29.aspx>
>>
<https://developer.mozilla.org/En/Using_JSON_in_Firefox#Converting_objects_into_JSON>
>>
>> However, AIUI, `Person' as you define it above cannot be used for that
>> argument.
>>
>> First of all, according to the MSDN Library the reviver function is
>> "called for each member of the [deserialized] object in post-order"; one
>> would need to make sure that it only operates on those "members" that
>> hold person data.
>
> Well, you'd have to return the original value for Strings, Numbers,
> etc. But there is a pattern that I've seen a few places ...
> searching, searching, ah yes... such as JSON.org [1]:
>
> | myData = JSON.parse(text, function (key, value) {
> | var type;
> | if (value && typeof value === 'object') {
> | type = value.type;
> | if (typeof type === 'string' &&
> | typeof window[type] === 'function') {
> | return new (window[type])(value);

OMG. Apparently Crockford is getting serious with his "window for Global
Object to avoid implied globals" nonsense he babbled months ago.

Avoid this pattern at all costs; `window' refers to a host object, _not_
the built-in Global Object. Refer to the built-in Global Object by `this'
where possible (as specified and documented), by user-defined
variable/property where necessary.

> | }
> | }
> | return value;
> | });
>
> You could use this by adding "type":
>
> var people = [{type: "Person", first: "Thomas", last: "Lahn"}];

Possible. However, we do not need any reference to the constructor then
(irresponsibly by `window[type]' or responsibly by refToGlobal[type]), for
we have the identifier of the constructor already.

In addition, this only works with constructors that are properties of the
Global Object; if we lose the needless reference check, it can work with
other constructors, too (applying eval() if necessary).

>> Second, `this' does not always refer to the passed object in the reviver
>> function; in JavaScript 1.8.1,
>>
>> JSON.parse('{"foo": {"bar": "baz"}}',
>> function(k, v) {
>> console.log("debug:", this.foo, k, v);
>> return v;
>> });
>>
>> displays:
>>
>> | debug: undefined bar baz
>> | debug: Object { bar="baz"} foo Object { bar="baz"}
>> | debug: undefined Object { foo=Object}
>
> Okay, I didn't realize this, but I'm not sure it matters. I hadn't
> thought of using "this" inside the function.

You suggested to pass a reference to the constructor to JSON.parse().
In case you did not notice, the constructor uses `this' a lot.


PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
From: Jorge on 26 Jan 2010 04:33
On Jan 26, 4:48 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de>
wrote:
>
> OMG.  Apparently Crockford is getting serious with his "window for Global
> Object to avoid implied globals" nonsense he babbled months ago.
>
> Avoid this pattern at all costs; `window' refers to a host object, _not_
> the built-in Global Object.  Refer to the built-in Global Object by `this'
> where possible (as specified and documented), by user-defined
> variable/property where necessary.

window *is* already -in any decent browser- an alias of the global
object(1):

window= globalObject;

An alias -btw- not any worse than your suggested:

var global= globalObject;

So why do you insist -quixotically- in aliasing it a second time when
the browser already provides a proper alias ?. ISTM that you're the
one babbling -again-. You seem to have trouble getting this (and the
closures, too).

(1)for all intents and purposes, and leaving aside multiple -
perceived- globalObjects, frames and child windows.
--
Jorge.
From: Matthias Reuter on 26 Jan 2010 06:43
Jorge wrote:

> window *is* already -in any decent browser- an alias of the global
> object(1):

I was wondering about that passage in ECMA-262, Section 10.1.5:

"[...] for example, in the HTML document object model the window property
of the global object is
the global object itself."

That matches what you're saying and contradicts what several others are
saying. The question is, is this normative to the DOM or descriptive (e.g.
for the time it was written)?

Matt
From: Richard Cornford on 26 Jan 2010 06:51
On Jan 26, 11:43 am, "Matthias Reuter" <frontendg...(a)web.de> wrote:
> Jorge wrote:
>> window *is* already -in any decent browser- an alias of the
>> global object(1):
>
> I was wondering about that passage in ECMA-262, Section 10.1.5:
>
> "[...] for example, in the HTML document object model the window
> property of the global object is the global object itself."
>
> That matches what you're saying and contradicts what several
> others are saying. The question is, is this normative to the
> DOM or descriptive (e.g. for the time it was written)?

It is descriptive (and only an example).

Richard.
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: get or post?
Next: appendChild that fails in Safari, but succeeds in FF, Camino