I love this :)
Specially the hashes for findAll, writing function(r) { return
r.something == someOtherThing } gets tiring fast, and AR's conditions
hash was possibly one of the sexiest pieces of codes added to rails in
the last few months.
I'm not so sure about the chained.string.calls though, but it's
probably more of an aesthetic disagreement than anything else.
I'll test this out and give you my +1 if I find it doesn't break anything
-Nicolas
On 9/21/07, jcoglan <[EMAIL PROTECTED]> wrote:
>
> > My only suggestion would be to require an explicit call #toFunction() so
> > that it would be more obvious that it is an iterator function
>
> Part of the rationale for this is that I'd like to avoid the cruft
> associated with writing 'function(foo) { return ...' all the time, so
> I'd like to hide the conversion to a function behind the scenes.
> Especially in the case of hashes - you shouldn't extend
> Object.prototype so you'd need to write $H({hasClassName:
> 'foo'}).toFunction() rather than just {hasClassName: 'foo'}, and this
> isn't really a great saving over using regular functions. This is
> another reason why this isn't possible:
>
> > someDivs.findAll(['hasClassName', 'myClass']);
> > following invoke's philosophy it should be simply:
> > someDivs.findAll('hasClassName', 'myClass');
>
> In 1.6.0, the second argument is the context to bind the iterator to,
> so I want to keep the first argument only for making iterator
> functions. How do we know whether that second argument should be a
> context for the iterator or an argument for it? Really, Arrays are
> only in there because they can be neater to use for functions with
> more than one argument. I'd tend to favour using a hash for this
> example.
>
> someDivs.findAll({hasClassName: 'myClass'})
>
> 'invoke' definately has its place and can be really neat, but I wanted
> to improve the readability of all the other Enumerable methods.
>
> Regarding CSS selectors: yes they are very useful, but my collection
> of DOM nodes may consist of some array pieced together from lots of
> different sources. Their properties may have changed, they may no
> longer be in the document, etc. Hence needing useful array methods to
> work with them. Also, I wasn't just thinking of DOM nodes while
> writing this, I was thinking of just plain JavaScript as a language -
> objects, properties, methods etc and how good it would be to improve
> things like 'findAll' and 'sortBy'. There's no end to how complicated
> your own objects can get. Also, Prototype is moving towards having
> more interesting language features - stuff like Function#curry and the
> like.
>
> One last thing regarding these:
>
> > someCollection.map(Element.Methods.getWidth)
> > //or
> > someCollection.collect(function(el){return el.getStyle('opacity')})
>
> Yes, they will work, but neither is particularly elegant or intuitive.
> Especially the first one, which exposes Prototype's 'internal'
> implementation of a function rather than directly accessing an
> object's own properties. Maybe I've been spoiled by Ruby, but I'd
> rather do this:
>
> someCollection.map('getWidth')
> //or
> someCollection.collect({getStyle: 'opacity'})
>
> I do appreciate the input though, so thanks for chiming in.
>
> Best,
> James
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Spinoffs" 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/rubyonrails-spinoffs?hl=en
-~----------~----~----~----~------~----~------~--~---
