For me, IMHO, of all these 3 I think the first is the nicest looking
this.items.each(this, function(i)
{
alert(this.hello);
});
this.items.each(function(i)
{
alert(this.hello);
}, this);
this.items.each(function(i)
{
alert(this.hello);
}.bind(this));
I just wrote this up in notepad, it kind of expresses the idea for a
central registry though its really buggy at the moment ...
var bases = {}
Object.extend = function(destination, source) {
if (destination.base_id != null)
{
if (bases[destination.base_id] != null)
{
for (var i = 0; i < bases[destination.base_id].length; i++)
{
for (var property in source)
{
bases[destination.base_id][i][property] = source[property];
}
}
}
}
for (var property in source)
{
destination[property] = source[property];
}
if (source.base_id != null)
{
if (bases[source.base_id] == null)
{
bases[source.base_id] = [destination];
}
else
{
bases[source.base_id].push(destination);
}
}
return destination;
};
Test = {
hello: function()
{
alert("hello");
},
base_id: 1
}
Test2 = {}
Object.extend(Test2, Test);
Object.extend(Array, Test2);
Object.extend(Test2, {bob: function() {alert("bob");}});
Array.hello();
// notice bob is "inherited"
Array.bob();
On Feb 8, 7:59 pm, "Jon L." <[EMAIL PROTECTED]> wrote:
> > So, Object.Extend as a side effect would would track the list of
> > classes that were extended in a hash or something like it. And then
> > we could revisit that later.
>
> Interesting idea.
>
> But, afaik, currently impossible within Javascript -- let alone
> Prototype.
> Within Object.extend's scope -- function(destination, source) -- I
> don't think there's any way of retrieving the name of destination, as
> e.g. Object.prototype, to build the array.
>
> Maybe someone else knows a way; but, I'm oblivious to it, atm.
>
> > Sure, but unless I am missing something .. I have to call
> > Object.extend on Array.prototype, Hash.prototype, ObjectRange,
> > Ajax.Responders, Element.ClassNames.prototype to get all of the
> > places,
>
> I never said it'd be enjoyable; only simple.
> Tediousness should be a given.
>
> You've also got to be cautious altering things.
> From what I've seen of the inner-workings, only 2 or 3 each
> definitions actually do anything, themselves (I think all are actually
> named _each).
> And, of course, add to that the native functions that Andrew mentioned
> about.
>
> Anyways...do you really need to redefine all of them now?
> You could just write them as you need them; starting with
> Enumerable.eachOf (or, whatever name you pick for it).
> If nothing else, that'll help spread out the tediousness so, when it
> kicks you in the teeth, it's not quite as brutal. ;)
>
> - Jon L.
>
> On Feb 8, 1:39 am, sambo99 <[EMAIL PROTECTED]> wrote:
>
> > > Last I checked, Object.extend doesn't check if a child is defined
> > > before redefining.
> > > So, that shouldn't be too difficult.
>
> > Sure, but unless I am missing something .. I have to call
> > Object.extend on Array.prototype, Hash.prototype, ObjectRange,
> > Ajax.Responders, Element.ClassNames.prototype to get all of the
> > places,
>
> > Instead imagine if there was a function:
>
> > SuperExtend(Enumerable, functions) that knew about all of these
> > relationships. and would do that for me in one call.
>
> > So, Object.Extend as a side effect would would track the list of
> > classes that were extended in a hash or something like it. And then
> > we could revisit that later.
>
> > > It would make more sense to have a separate function:
> > > each ( function [, binding] )
> > > eachOf ( binding, function ) // or something similar
>
> > > Sound reasonable? Plausible?
>
> > Sure, it sounds plausible, but I am suggesting we do this with all of
> > the functions that accept context as a second param, this could mean
> > that there are just too many functions.
>
> > Imagine, eachOf and rejectOf, partitionOf etc.. etc..
>
> > So I agree this is a bit of a pickle but IMHO I think its worth
> > breaking the regularity rule for this one.
>
> > > Generally speaking, most "suggestions" are posed as questions: "What
> > > do you think about [suggestion]?"
> > > Versus, "this is BS...they're idiots...they should do it this way
> > > cause I think it's better."
> > > At least, that's the tone/attitude I got out of your aforementioned
> > > blog post.
>
> > I'm new to this, and I felt pretty insulted by the suggestion I have
> > not worked in big teams.
>
> > I would like to be perfectly clear here, I love using prototype,
> > without it my last couple of weeks would have been hell.
> > You guys have done a great job with this library.
> > I really just wanted to make a suggestion. Binding is such a hard
> > concept to grasp, and I think making the library more flexible in this
> > area would make peoples life a bit easier.
>
> > Perhaps I should have chosen a different tone ... I'm new to this
> > whole open source thing.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
