Re: shortcut for add unless nil ?

On 25.03.2011 20:06, serialhex wrote:
> ..personally i think it would be nice to be able to define new operators
> (like the aforementioned +?) that way when a situation like this comes up,
> one can simply:
>
> op_def +?  # maybe? i'm assuming it'd have special syntax...
>    # stuff
> end
>
> and get on with life, making your code cleaner&  simpler.  IDK how well this
> would work or its potential ramifications, but i think it fits into the
> 'flavor' of ruby to be able to do such things (i mean, you can define/change
> damn near *everything else* in the language, why not operators?)

Because that would completely break parsing.  Whenever an operator 
definition would be seen the whole source would need reparsing - or at 
least part of it.  It would be tricky to determine which part.  Think of 
situations like this:

def foo
   x +? y
end

op_def +?(a,b)
   p a, b
   a + b
end

Now, Ruby would have bailed out with a syntax error already before it 
could read the new operator definition.  If you defer error reporting to 
a later point in time then execution would become much more complex 
because parsing would have to occur chunk wise.  And the whole thing 
will likely get slower as well.

If you try something like prescanning all sources for operator 
definitions before parsing the code then this is not possible because 
you can easily construct 'require' and 'load' statements which do not 
have a String constant argument but whose argument is constructed at 
runtime.  So now you have a chicken egg issue: you need to parse the 
code in order to be able to execute it but you also need to execute the 
code in order to be able to parse it...

And then of course there are issues of readability.  In general I'd say, 
too much flexibility can rather harm than do good.  It's the right 
balance which is most productive.  And IMHO Matz has done a wonderful 
job at this.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/