window is our friend (and no eval needed)
...
String.prototype[method] = window[method].methodize();
...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to p
But actually, I'm not a fan of exploiting native prototypes.
Other than that, would it really make a big difference?
encodeURI('foo bar'); and 'foo bar'.encodeURI();
look pretty much alike to me.
Best,
kangax
--~--~-~--~~~---~--~~
You received this message be
> Then the question is, why do it for the Math functions but not the
> String functions?
AFAIK, because the Math ones were needed for script.aculo.us code.
Best,
Tobie
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Group
Thanks for the fix ;)
Then the question is, why do it for the Math functions but not the
String functions?
On Jan 18, 1:34 pm, kangax <[EMAIL PROTECTED]> wrote:
> But actually, I'm not a fan of exploiting native prototypes.
> Other than that, would it really make a big difference?
>
> encodeURI(
I noticed a few days ago that Prototype adds some of the math
functions as methods to the Number object, but doesn't do the same
thing for strings. Is there a reason the same thing hasn't been done
for strings?
It wouldn't take too much...
$w('encodeURIComponent decodeURIComponent decodeURI enco
On Jan 18, 2008, at 2:30 PM, Nycto wrote:
> Then the question is, why do it for the Math functions but not the
> String functions?
I agree with this question. One difference, of course, is that the
Math functions are namespaced and a PITA to type over and over. Still,
where it is possible to
