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