[Prototype-core] Re: Thoughts on Namespacing Native APIs
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() instead. --~--~-~--~~~---~--~~ 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 email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts on Namespacing Native APIs
Hi Robert, 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: http://groups.google.com/group/prototype-core/browse_thread/thread/d38f2123aa64eb0e/ac612b72cc060943 And this _rather_ more comprehensive one: http://groups.google.com/group/prototype-core/browse_thread/thread/16d0517ecc605a00/c9cfe041c1da19de FWIW, -- T.J. Crowder 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() instead. --~--~-~--~~~---~--~~ 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 email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts on Namespacing Native APIs
On Mar 25, 1:32 pm, Robert Kieffer bro...@gmail.com wrote:
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.
I'm working on a couple of things remotely related to this. More on
this asap. That said, native object extensions is there to stay: it's
one of Prototype's biggest appeal (for example, that's the main reason
Prototype was included in Palm Mojo Application Framework).
Furthermore, namespacing issues, both for the global object and native
objects' prototypes, can be handled by sandboxing third party code
with Caja--which we'll fully support in the near future--with added
security as a bonus.
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().
For one, I'm a strong partisan of modifying our Class API (see a dummy
implementation proposal here: http://gist.github.com/43064) to remove
dependency on function decompiling.
Secondly, some platforms actually return sufficient information for
Function#argumentNames to work, while not truly decompiling the
function. That's the case of Caja, for example:
(function(foo, bar) { alert(foo + ' ' + bar) }).toString();
// - function(foo, bar} { [cajoled code] }
Last but not least, your solution won't be able to handle context
properly (which, btw, is one of the reasons function decompilation
isn't specified in ES).
Try this in your original pastie, for example (a bit contrived, but
you get the point):
var clear = (function() {
var ZERO = 0;
function clear(_this) {
_this.length = ZERO;
return _this;
}
return clear;
})();
// ... do the magick eval tricks
[1, 2, 3].clear();
// - ReferenceError: ZERO is not defined
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()
instead.
Platforms which do not support eval obviously support neither new
Function, nor passing a string to setTimeout or setInterval, nor
dynamic script injection.
To summarize, if implementing this was trivial, I would have been done
a long time ago. Unfortunately, it's not!
Over the next few weeks, we'll be concentrating our efforts on
completing the documentation, releasing 1.6.1 and migrating to a
library-agnostic test harness which I'm currently busy working on.
The idea is to get the source code as clean and solid as possible for
Prototype 1.7 (Caja support) and 2.0 development. We can certainly
look at options to remove dependencies between different parts of
Prototype by then. (For example, I would love to see the ajax module
standalone).
Hope this clarifies my point.
Of course, if you're available to help out on our current issues,
you're more than welcomed to do so!
Best,
Tobie
--~--~-~--~~~---~--~~
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 email to
prototype-core-unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts on Namespacing Native APIs
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 --~--~-~--~~~---~--~~ 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 email to prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
