Quick update: I'm working on allowing you to use operators as well, so
you can do stuff like...
// Find numbers divisible by 3...
$R(1,10).reject(['%', 3])
// -> [3, 6, 9]
// Other crazy stuff
someRandomJunk.findAll({'instanceof': Number, '>=': 4})
I've not released it yet, but source code is here:
http://svn.jcoglan.com/reiterate/trunk.
My guess is that the code required to make that happen is big enough
to make it a questionable candidate for the core, but I'll see what
others think.
James
On Sep 22, 9:54 am, "Nicolás Sanguinetti" <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
