> I like the "imports" idea. I think adding custom prefixes is a bit
> much though.
> (or maybe its just the method name that bothers me)

If we're going to continue enhancing some host objects (String,
Functino) and not others (Element, Array), I'd suggest we drop the
idea of custom prefixes anyway since only some of them would be
affected -- and that would be *really* confusing.

I do wonder if a Prototype-wide prefix for functions added to host
objects might be a good idea, though, so we don't have the issue of
name conflicts.  Even just throwing a $ on the front would help, e.g.
"handler = myNiftyFunction.$bind(this)".  For me it's worth drawing
the distinction between standard stuff and Prototype stuff.  That
won't be a popular sentiment, but esp. for newbies making a clear
distinction may be quite helpful.  In cases where Prototype is
supplying a missing function because the host environment doesn't
provide it (such as the new Array stuff), obviously we wouldn't prefix
that as the whole point is to not worry about whether the host
environment provides the function.
T.J. Crowder
tj / crowder software / com

On Aug 18, 4:27 pm, John-David Dalton <[EMAIL PROTECTED]>
> If a cache is to be used it can be uniquely marked via the same
> approach as elements in the event system
> element._prototypeWrapperId = [arguments.callee.id++];
> the id is unique and doesn't transfer if you clone the node.
> var instance = Prototype.Element.cache[ element._prototypeWrapperId ];
> if (instance) return instance;
> This would work well with this patch (allowing Class.create to return
> a value).http://dev.rubyonrails.org/ticket/11481
> Some host objects may not allow the addition of custom properties
> though, and in
> those cases they wouldn't get cached.
> I like having a common property for the wrapped object (+1 for the
> suggestion):
> var el = new Prototype.Element(element);
> el.raw, or el.obj, or el.wrapped, or el.source.
> I kinda dig el.source
> We don't have to worry to much about naming conflicts because this is
> a property of the wrapper instance and
> not of the Element host object.
> I like the "imports" idea. I think adding custom prefixes is a bit
> much though.
> (or maybe its just the method name that bothers me)
> Checking if the object you are dealing with is extended is as easy as
> if (element instanceof Prototype.Element)
> There has been reports of Prototype loosing the properties assigned to
> String static object when dealing with Flash's externalInterface
> (flash/js communication)
> I think using a wrapper is pretty painless and we can see this via:
> var text = $.str(text);
> text.strip();
> I also like Kangax's idea to use $A for wrapping arrays, it feels like
> the natural choice.
> var arr = [1,2,'bob'];
> $A(arr).each(function(n) { ..});
> As a bonus I think we should follow jQuery's lead and allow
> $$(selector).hide() or something. If $$ is a selector wrapper, I would
> want to be able to do
> $$(selector).hide() instead of $$(...).invoke('hide') or instead of  $$
> ('#input')[0].getValue() -> $$(...).getValue();
> - JDD
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 

Reply via email to