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
I don't really know whay that happens by my HTML Code validates (so,
there is not a non closed element) but form nodes seems to not work
properly with Element.select methods.
I know that I can use Form.getInputs() method but it does not allow me
to use the selectors of select, as : Form.getUnputs
May I ask you ?
Can I use Hash or vanilla objects for storing [key,value] with
key==='constructor' or key==='prototype' ?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this grou
I'm with kangax on this one. I have never needed this functionality.
Allen Madsen
http://www.allenmadsen.com
On Fri, Sep 11, 2009 at 11:59 AM, James Aimonetti
wrote:
>
> My interest was piqued when reading
> http://www.timdown.co.uk/jshashtable/index.html if that helps further
> discussion of
My interest was piqued when reading
http://www.timdown.co.uk/jshashtable/index.html if that helps further
discussion of including the feature.
kangax wrote:
>
> On Sep 11, 7:08 am, "T.J. Crowder" wrote:
> [...]
>
>> @Jim:
>>
>>
>>> Yep, this is Java-esque but that doesn't *always* equa
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, 7:08 am, "T.J. Crowder" wrote:
[...]
> @Jim:
>
> > Yep, this is Java-esque but that doesn't *always* equal evil!
>
> Hardly ever! I'd say hashCode has a place.
>
> Let's step back and ask the question: What are the use cases for a
> hash keyed by non-string objects? Are they compe
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
@Samuel:
> I've been working on this too and had quite reasonable performance
I like it, _should_ perform a *lot* better than a straight array given
a reasonable distribution of keys. This is similar to what Java's
HashMap does (not that I'm holding it up as a model of high
performance).
@Jim:
On Friday 11 September 2009 10:39:14 Samuel Lebeau wrote:
> Hi,
>
> I think it's indeed a good feature to discuss for 2.0.
> I've been working on this too and had quite reasonable performance
> when using a hash function that avoids collision.
> The simplest implementation consists in storing arra
Hi,
I think it's indeed a good feature to discuss for 2.0.
I've been working on this too and had quite reasonable performance
when using a hash function that avoids collision.
The simplest implementation consists in storing array of [key, value]
tuples indexed by `key.toString()` in a vanilla
12 matches
Mail list logo
