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
-~----------~----~----~----~------~----~------~--~---
