@Rick: Rock on! That's the spirit!
@Tobie: *blech* to ES5's enumerable stuff not having $break or similar functionality. I've just read the forEach section of the draft spec from a while back, and I'm not seeing a discussion of exception handling. I haven't delved deep, though -- do you know offhand how exceptions in the callback function are handled? E.g, can one implement one's own $break handling, or are exceptions eaten? Re setInterval and setTimeout, how do you see implementing #delay or similar without using them? Or do you not see it, e.g., a pure LANG version of Prototype wouldn't have Function#defer. -- T.J. Crowder tj / crowder software / com On Aug 27, 6:08 pm, Rick Waldron <waldron.r...@gmail.com> wrote: > @TJ > > Re: @Rick: All of this discussion probably seems like nit-picking your > idea to death. In fact, I think it indicates that there's a lot of > support and appreciation for your idea, and we're all (well, nearly > all, there's a dissenter) just trying to make it fit in, and make it > as cool as the idea warrants. > > I love it! How else are we going to make a good idea into an awesome idea? > Such is why i brought it to the group - I'm just pleased that it wasn't > discarded. I'm excited to see the process of it's evolution and hope it > continues to do so and eventually to see Function#repeat() make its way into > Prototype - but only the best possible version of the method! > > > > On Thu, Aug 27, 2009 at 11:13 AM, Robert Kieffer <bro...@gmail.com> wrote: > > @TJ... > > > Your goals sound about right. Implicit in there, I think, is "make it easy > > to deprecate PE at some later date". At least, that's how I read it. :) > > > Re: #2 - Why not just use bind() to provide context? I've never been a > > fan of overloading arguments with multiple interpretations. 'Gets too > > confusing, and makes the implementation that much uglier. > > > Re: #4 - I feel the ability to self-stop is more important than being able > > to repeat() functions that aren't designed for it. I _really_ feel that > > making the self-stop behavior an optional add-on feature of PE is a bad > > idea. self-stop is an elegant pattern (IMHO) so forcing users to go through > > the awkward PE API to get at it doesn't make sense. Also, it makes > > deprecating PE harder. > > > ***Hmm...*** How about this as a solution: Instead of having a function > > return false to stop, have it "throw $break"! I think that addresses your > > concern, and is consistent with how Prototype does this sort of thing > > elsewhere (in Enumerable). --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
