Sometimes the most productive results come from the most dangerous of
tools.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.co
On Sep 11, 11:45 am, Joran wrote:
> The suggestion is not to extend String.prototype with another method,
> but to rename the current String.evalJSON extension to String.toObject.
I understand :)
The problem is that both - `String.prototype` and `String` are built-
in objects and no matter whic
The suggestion is not to extend String.prototype with another method,
but to rename the current String.evalJSON extension to String.toObject.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To
On Sep 11, 8:06 am, Joran wrote:
> Does that rule out String.toObject()?
For compatibility with 3rd party code, but more importantly with
future (standard and non-standard) and unknown implementations, it's
usually a good idea to leave built-in objects alone. Extending them is
only elegant in th
Does that rule out String.toObject()?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-core@googlegroups.com
To unsubscribe from this group, send
Thanks Jim for the great tip and thanks Robert for the words of
caution. It would seem then to be too dangerous to override
Object.prototype.toString.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core"
Overriding Object#toString should not happen in Prototype.
It's impossible to know what assumptions are made about the behavior
of this [fundamental, core] method by Firebug, jQuery, mooTools, or
the countless 3rd party libraries and applications out there.
The impact to Firebug that J.Higson po
On Tuesday 08 September 2009 13:56:14 Joran wrote:
> Dear Tobie
>
> Thank you for your reply. Could I suggest a few more questions?
>
> 1. Does EcmaScript 5 preclude one from modifying
> Object.prototype.toString?
>
> 2. Over-writing Object.prototype.toString does not at first glance
> appear to c
Dear Tobie
Thank you for your reply. Could I suggest a few more questions?
1. Does EcmaScript 5 preclude one from modifying
Object.prototype.toString?
2. Over-writing Object.prototype.toString does not at first glance
appear to cause it to show up in for...in loops in Rhino, Safari or
Firefox.
Hi, Joran.
Thank you for your suggestions.
Unfortunately, there's a number of reasons why they're not practical
and why they will not be implemented in the framework..
1. We have a strict policy of not shadowing standardized properties/
methods of native objects. We're busy right now cleaning u
10 matches
Mail list logo