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

Reply via email to