Re: syntax sugar: treating an object like a method

On 5/18/05, Eric Mahurin <[e-mail]> wrote:
> --- "David A. Black" <[e-mail]> wrote:
>> I'm not sure what the canonical definition of syntactic sugar is,
>> but I don't think that I think this is exactly that. Anyway....
> In my book, syntactic sugar is when you have a more
> concise/readable syntax that is equivalent to a more fundamental
> (and longer) syntax. So by that definition, all of the operators
> that equate to methods are syntactic sugar. I think this thing I'm
> talking is similar to adding another operator.

Yes. It's adding the #() operator, which is evil.

>> Forgetting .new is a weak reason for making it optional. It would
>> be hard to argue that calling MyClass.new to create a new MyClass
>> object is arcane or hard to get the hang of.
> I know it is weak. But, it did seem to prod me to develop this
> idea a little more - because the vast majority of time the only
> thing you do with a class is call new.

Very weak. And speak only for your own development. I use classes in
different ways for different projects.

>>> * (str) = value : this could default to "replace" for any
>>> objects that respond to it (or if you use evil.rb - "become") *
>>> (mutable) += value : now the real += can be implemented for
>> += is already the real +=. It's not the C or Perl +=, but it's
>> the real Ruby +=.
> Correct. "real" was the wrong word. How about "in-place"? A
> normal += in Ruby creates a new object whereas this one
> modifies an object in-place.

The case where you will need this is the very case that makes the ++
operator inappropriate and impossible in Ruby -- numeric values.

If you need to append to something in place, make a method that does
exactly that.

  str = "foo"
  str << "bar"

  puts str 	# -> "foobar"

If you need a counter:

  class Counter
    def initialize(start = 0)
      @counter = start
    end

    def inc
      @counter += 1
    end

    attr_reader :counter
  end

  lines = Counter.new(0)
  3.times { lines.inc }
  puts lines.counter # -> 3

I'd much rather see the replacement concept explicitly specified as
making #replace a "standard" method that can (potentially) do a
bitwise copy of the object. This would also mean having #__replace__
in the same way that we have #__send__ and #__id__.

This is *clear*. Your proposal is not.

> Why do some of you think that everything I suggest has to do
> with references?

Because nearly everything you bring up has a reference-like mention
in it. This part is your own fault.

> The initial reason I was wanting this was in my BNF like classes
> thing (specify syntax in Ruby directly rather than in some other
> language - yacc/lex). Right now I have things like this:
> 
> int = (("0".."9")*(1..+1.0/0)).qualify { |m| m.to_s.to_i }
> 
> I use operator overloading quite a bit in this to create these
> Syntax (renaming it to Grammar) objects. In the example above,
> int now is used to match anywhere from 1 to an infinite number
> of digits and the resulting parse tree (an array of digit
> characters) is converted to an integer. In the above, it would
> have been nice not to have to put the .qualify in there and
> have it look like this:
> 
> int = (("0".."9")*(1..+1.0/0)) { |m| m.to_s.to_i }
> 
> That is where the idea originated. Nothing to do with
> references.

Sorry, but ick. I don't get where you even remotely think that not
having "qualify" is more intuitive or cleaner than having it. I'd
have to have some way of knowing and looking up that the "default
operator" is #qualify in this case. Talk about impossible to
maintain code.

>> I fear that's the slippery slope to what people call "write-only
>> code".
> You could argue that. That is what Java designers said. And that
> is why they didn't allow operator overloading. I think operator is
> a good thing, but someone can easily abuse it and make write-only
> code. I think what I'm suggesting here is like adding more
> operators.

Definable operators are a good thing. The () operator is not.
Therefore, this suggestion is not. (There are several operators that
are bad ideas in C++, which is why the Java designers prohibited
them. Specifically operator&, conversion operators, operator+=, and
a few others. This doesn't invalidate the whole idea, but it does
indicate that there are really dumb operators to overload.)

-austin
-- 
Austin Ziegler * [e-mail]
               * Alternate: [e-mail]