And using : http://gfx.neohub.com/benchmark/creator.html
Firefox: slower by alot using constructor
IE : faster by alot using constructor
return ('hi'.constructor == String);
vs
return (typeof 'hi' == 'string');
IE: faster by alot using constructor
Firefox : mixed (sometimes slower sometimes fas
If you run it more than once you get different results. Reguardless of
this benchmark (I got it to show .constructor was faster consistently
more times, IE)
Its a method of detecting a string that will fix the issue.
--~--~-~--~~~---~--~~
You received this message
I'm actually getting faster results in Firefox for typeof in that
particular case.
On Jun 22, 8:55 am, jdalton <[EMAIL PROTECTED]> wrote:
> I don't see the harm in adding the second condition "element
> instanceof String"
> you could use :
>
> if(element && element.constructor == String)
>
> This
On 6/22/07, Tobie Langel <[EMAIL PROTECTED]> wrote:
>
>
> I'm actually getting faster results in Firefox for typeof in that
> particular case.
Me too. Try it for yourself:
http://gfx.neohub.com/benchmark/creator.html
--~--~-~--~~~---~--~~
You received this message
On 6/22/07, jdalton <[EMAIL PROTECTED]> wrote:
>
>
> Also I don't buy the "it hasn't been fixed since the beginning, so why
> fix it now?" argument.
Well, if in almost 2 years we have a first report about it only now, then it
sounds like a big edge case to me.
--~--~-~--~~---
I don't see the harm in adding the second condition "element
instanceof String"
you could use :
if(element && element.constructor == String)
This works for both "foo" and new String("foo");
I find that it is faster than using typeOf.
I have made very JavaScript heavy applications and noticed
On 6/22/07, Tobie Langel <[EMAIL PROTECTED]> wrote:
>
>
> > The String function/constructor is maybe useful for other things [...]
>
> Like what exactly !?
Like when casting something to string when toString is not sufficient. I
don't know when that may be.
I was just stating this: although this
> The String function/constructor is maybe useful for other things [...]
Like what exactly !?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to prototype-
On 6/22/07, Miha Zimin <[EMAIL PROTECTED]> wrote:
>
>
> Or it isn't good idea. What do you think?
Leave it as it is. The String function/constructor is maybe useful for other
things, but seldom for handling element IDs before passing them to the $
function. The current check is enough - it was en
Hi guys. I'm new in prototypejs and script.aculo.
But, lets consider Andrew Dupont's example again:
var f = new String("foo");
alert($(f)) //-> foo
alert(document.getElementById('foo')) //-> [object HTMLElement]
It has cause:
"When String( ) is used as a constructor with the new operator, it
r
On Jun 21, 2:35 pm, sed <[EMAIL PROTECTED]> wrote:
> I'm not sure why this worked before, it must be related to the html/
> script being generated into the div from the ajax.updater rather than
> just being on the page.
Nope. It's sillier than that. Let's say you've got an element with an
ID of
Interesting problem here and I don't think it's a prototype bug, but I
corrected the issue.
Here is what was happening if anyone's interested Here is a short
explanation:
Ajax Call generates some html into a div with this function inside:
GetNextField = function() {return('thenextfield');};
In
This is very very unlikely. I use bracket notation with and without
prototype on many scripts that work cross browser. Check which other
libraries you are including, and make sure it is not a problem or
missing attribute of the object you are working with.
On Jun 21, 8:41 am, sed <[EMAIL PROTECTE
On 6/21/07, sed <[EMAIL PROTECTED]> wrote:
>
>
> I've posted this question to ruby on rails, but figured people here
> would be more likely to know the answer.
>
> Using bracket notation in javascript seems to stop workiing when
> prototype is included.
I'm not using the notation, but if Prototyp
14 matches
Mail list logo
