[Prototype-core] Re: Thoughts on Namespacing Native APIs
On Mar 25, 1:32 pm, Robert Kieffer 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
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 wrote: > On Mar 24, 3:32 pm, Tobie Langel 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 24, 3:32 pm, Tobie Langel 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
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 -~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts??
On Dec 23, 8:39 pm, Simon Thomas <[EMAIL PROTECTED]> wrote:
> Just after some feedback really, any reason not to do it like this? or
> any glaringly obvious bad practices??
It depends. Some would consider it bad practice to add methods
directly to the global scope, but that applies far more to libraries
than it does to one's own code. (After all, you know what's best for
your environment.) We define the methods on Object because we'd rather
play it safe and minimize possible conflict with global methods. We
don't define them on Object.prototype because that *is* bad practice
[1].
If you want to "import" the isFoo methods into window, you can do it
like this:
for (var m in Object)
if (m.startsWith("is")) window[m] = Object[m];
No need to rewrite the logic.
Cheers,
Andrew
[1] http://erik.eae.net/archives/2005/06/06/22.13.54
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
No one probably cares but me about this - but there were a few issues
with the previous code...here is some that works, and is suitable for
placing in an extension.js file:
var prev = {};
["insert","remove","replace","update","wrap"].each(function(s){prev[s]
= Element[s]});
var add = {
insert: function(element, insertions){
var fireEs = [];
if (Object.isString(insertions) || Object.isNumber(insertions)
||
Object.isElement(insertions) || (insertions &&
(insertions.toElement || insertions.toHTML)))
insertions = {bottom:insertions};
for (position in insertions) {
position = position.toLowerCase();
if (position == "before" || position == "after")
{
fireEs.push($(element.parentNode));
}
else
{
fireEs.push(element);
}
}
var retVal = prev.insert(element, insertions);
fireEs.each(function(e){
e.fire("nodeadded");
e.fire("domchanged");
});
return retVal;
},
remove: function(element){
var fireE = $(element.parentNode), retVal =
prev.remove(element);
fireE.fire("noderemoved");
fireE.fire("domchanged");
return retVal;
},
replace: function(element, content){
var fireE = $(element.parentNode), retVal =
prev.replace(element,
content);
fireE.fire("noderemoved");
fireE.fire("nodeadded");
fireE.fire("domchanged");
return retVal;
},
update: function(element, content){
var retVal = prev.update(element, content);
element.fire("domchanged");
return retVal;
},
wrap: function(element, wrapper, attributes){
var fireE = $(element.parentNode);
var retVal = prev.wrap(element, wrapper, attributes);
fireE.fire("nodeadded");
fireE.fire("domchanged");
return retVal;
}
}
Element.addMethods(add);
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
No one probably cares but me about this - but there were a few issues
with the previous code...here is some that works, and is suitable for
placing in an extension.js file:
var prev = {};
["insert","remove","replace","update","wrap"].each(function(s){prev[s]
= Element[s]});
var add = {
insert: function(element, insertions){
var fireEs = [];
if (Object.isString(insertions) || Object.isNumber(insertions)
||
Object.isElement(insertions) || (insertions &&
(insertions.toElement || insertions.toHTML)))
insertions = {bottom:insertions};
for (position in insertions) {
position = position.toLowerCase();
if (position == "before" || position == "after")
{
fireEs.push($(element.parentNode));
}
else
{
fireEs.push(element);
}
}
var retVal = prev.insert(element, insertions);
fireEs.each(function(e){
e.fire("nodeadded");
e.fire("domchanged");
});
return retVal;
},
remove: function(element){
var fireE = $(element.parentNode), retVal =
prev.remove(element);
fireE.fire("noderemoved");
fireE.fire("domchanged");
return retVal;
},
replace: function(element, content){
var fireE = $(element.parentNode), retVal =
prev.replace(element,
content);
fireE.fire("noderemoved");
fireE.fire("nodeadded");
fireE.fire("domchanged");
return retVal;
},
update: function(element, content){
var retVal = prev.update(element, content);
element.fire("domchanged");
return retVal;
},
wrap: function(element, wrapper, attributes){
var fireE = $(element.parentNode);
var retVal = prev.wrap(element, wrapper, attributes);
fireE.fire("nodeadded");
fireE.fire("domchanged");
return retVal;
}
}
Element.addMethods(add);
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
> var oldInsert = Element.insert;
> Element.insert = function(...) {... fireYourCustomEvent() ...
> oldInsert(...)};
Just for reference, the way that I got this to work in Prototype 1.6
was (hopefully this accounts for all cases):
var prev = {};
["insert","remove","replace","update","wrap"].each(function(s){prev[s]
= Element[s]});
var add = {
insert: function(){
var args = $A(arguments), element = $(args.shift()), insertions
=
args[0], fireEs = [];
if (Object.isString(insertions) || Object.isNumber(insertions)
||
Object.isElement(insertions) || (insertions &&
(insertions.toElement || insertions.toHTML)))
insertions = {bottom:insertions};
for (position in insertions) {
position = position.toLowerCase();
if (position == "before" || position == "after")
{
fireEs.push($(element.parentNode));
}
else
{
fireEs.push(element);
}
}
var retVal = prev.insert(element, args);
fireEs.each(function(e){
fireE.fire("nodeadded");
fireE.fire("domchanged");
});
},
remove: function(){
var args = $A(arguments), element = $(args.shift()), fireE = $
(element.parentNode);
var retVal = prev.remove(element, args);
fireE.fire("noderemoved");
fireE.fire("domchanged");
return retVal;
},
replace: function(){
var args = $A(arguments), element = $(args.shift()), fireE = $
(element.parentNode);
var retVal = prev.replace(element, args);
fireE.fire("noderemoved");
fireE.fire("nodeadded");
fireE.fire("domchanged");
return retVal;
},
update: function(){
var args = $A(arguments), element = $(args.shift());
var retVal = prev.update(element, args);
element.fire("domchanged");
return retVal;
},
wrap: function(){
var args = $A(arguments), element = $(args.shift()), fireE = $
(element.parentNode);
var retVal = prev.wrap(element, args);
fireE.fire("nodeadded");
fireE.fire("domchanged");
return retVal;
}
}
Element.addMethods(add);
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
> I vote an emphatic No - this would be overhead within proto-core, which
> should remain as _baseline_ as possible (that's my rant and I'm sticking to
> it - proto is a baseline - don't bloat it... please!).
I see that point - and that was the type of discussion that I wanted
to spawn. I agree that the core should not be bloated at all...but
exactly *what* should be in core or not?
> var oldInsert = Element.insert;
> Element.insert = function(...) {... fireYourCustomEvent() ...
> oldInsert(...)};
This is actually a pretty easy way to do that. I don't have a problem
at all implementing this sort of thing outside of the prototype core.
I was just originally thinking that it would help to move Prototype
more towards its goal of creating a level-playing field of sorts - a
core library that irons out all the little cross-browser quirks that
exist (and mutation events are one of those...that was my original
thinking).
Thanks for the comments!
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
On 9/25/07, Ryan Gahl <[EMAIL PROTECTED]> wrote:
>
>
> var oldInsert = Element.insert;
> Element.insert = function(...) {... fireYourCustomEvent() ...
> oldInsert(...)};
We hear what you are saying. I don't know all the things Sam had in mind,
but I'm pretty sure he wasn't going to slow down Prototype for everyone just
for the 5% early adopters who would actually use the mutation events.
Sam and Thomas have some tricks up their sleeve regarding future versions of
Prototype, script.aculo.us and modularization. Just wait and see ...
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
I vote an emphatic No - this would be overhead within proto-core, which
should remain as _baseline_ as possible (that's my rant and I'm sticking to
it - proto is a baseline - don't bloat it... please!). What people need to
get in the habit of doing is loading an "extensions.js" file (or something)
after proto (or lib-of-choice)... and do whatever overriding/wrapping there.
Your case in point...
var oldInsert = Element.insert;
Element.insert = function(...) {... fireYourCustomEvent() ...
oldInsert(...)};
On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
> I had an interesting thought while testing out version 1.6 RC - I
> thought I'd solicit some opinions (and possibly make a suggestion).
>
> There is not a very reliable cross-browser way to implement the DOM
> mutation events - (such as DOMNodeInserted, DOMNodeRemoved,
> DOMAttrModified, etc). However, using custom events, it should be
> possible to register listeners for equivalents and send those events
> in prototype calls, such as Element.insert, etc.
>
> That would allow for some pretty powerful dynamic things - that can
> observe DOM change events. 1.6 already "spoofs" one of those events
> in the "contentloaded" event...it would be pretty cool to add a bit
> more support for others as well...
>
> What are peoples' thoughts on this? Or would it better be implemented
> outside of prototype (I can't think of a way to piggyback on the
> already-existing functions without writing wrapper functions and
> extending thingspossible, but it seems a bit cleaner to support it
> natively within prototype itself.
>
>
> >
>
--
Ryan Gahl
Manager, Senior Software Engineer
Nth Penguin, LLC
http://www.nthpenguin.com
--
Architect
WebWidgetry.com / MashupStudio.com
Future Home of the World's First Complete Web Platform
--
Inquire: 1-262-951-6727
Blog: http://www.someElement.com
LinkedIn Profile: http://www.linkedin.com/in/ryangahl
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/prototype-core?hl=en
-~--~~~~--~~--~--~---
[Prototype-core] Re: Thoughts about 1.6
On 9/25/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > That would allow for some pretty powerful dynamic things - that can > observe DOM change events. 1.6 already "spoofs" one of those events > in the "contentloaded" event...it would be pretty cool to add a bit > more support for others as well... > > What are peoples' thoughts on this? This is exactly what we've been working toward on the way to Prototype 2.0. I think we'll be implementing first synthetic mutation events even in 1.6.xversions; we still have to see how the new event system holds up. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~--~~~~--~~--~--~---
