For background, you might (if you haven't already) want to check out
these two threads from this group on this topic:
This short one:
And this _rather_ more comprehensive one:
tj / crowder software / com
On Mar 25, 12:32 pm, Robert Kieffer <bro...@gmail.com> wrote:
> On Mar 24, 3:32 pm, Tobie Langel <tobie.lan...@gmail.com> wrote:
> > Unfortunately, a number of environments do not support eval and
> > decompiling function isn't part of any specification to date (nor
> > planned in the near future).
> > Best,
> > Tobie
> Hey Tobie, those objections are well and good, but they can be
> addressed (see below). I was hoping for feedback at a bit higher
> level, on the overall idea. For example, does spinning off the native
> APIs into a separate library make sense? Is there merit to the
> resulting APIs (e.g. Does qip.String.endsWith(aString, substring)
> "work" for you?) What happens to the code if the APIs are made
> optional? ... that sort of thing.
> As for your specific comments...
> By "decompiling" I assume you mean Function#toString()? It may not be
> spec'ed, but that horse has already left the barn. Prototype (both
> stable and trunk) breaks on any platform where it's not supported -
> see Function#argumentNames().
> As for eval(), that was simply a convenience to keep the sample code
> compact, readable. Removing that dependency is trivial - we need only
> do a bit more parsing of the function source, and use "new Function()"
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at