Re: Extension for writing concise, expressive code

jcoglan
Sat, 22 Sep 2007 12:32:47 -0000

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"
<godf...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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 <jcog...-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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