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