Hi --

On Tue, 24 Aug 2004, Mauricio FernáÏdez wrote:

> On Tue, Aug 24, 2004 at 07:49:19PM +0900, David A. Black wrote:
> > If you're trying to fight back against Ruby's need for an explicit
> > receiver in assignment-style method calls, I think you've won a bit of
> > a Pyrrhic victory.  That looks like a bunch of assignments to local
> > variables; I wouldn't want to have to train my eye to find the word
> > "with" and then figure out that Ruby's normal assignment behavior was
> > temporarily suspended.  That's a heavy price to pay for avoiding a few
> > occurrences of the word 'self' (or 'some_obj', etc.).
> 
> For the matter, if you want you can keep
> 
> my_obj.with do
>   @x = 0
>   @y = 10
>   @width = 100
>   @height = 100
> end
> 
> while making it 'accessor-safe'. One only has to create a throw-away
> object to capture the values and inject them into the accessors.
> 
> Now, you might argue that this could be tricky for the untrained eye
> because what looks like a normal assignment to instance variables is
> transformed into a method call, and I'd rather agree.

I would argue also that it's tricky for the trained eye :-)

> So the problem is not as much what can be done in Ruby, as what we want
> to take a "being Ruby" or simple/obvious enough, or not contradicting
> the "normal rules". 
> 
> Whether we can take all the features/techniques used in the stdlib as
> a reference for what's Ruby and what isn't, and therefore declare the
> things not there as un-Ruby, is an open issue.  Of course, only matz
> can really tell what is Ruby and what isn't.

I take Ruby as a message from Matz as to what is Ruby :-) And if you
write something in Ruby, then what you've written is a Ruby program --
so if Ruby contains the seeds of its own alteration, then so be it.

But I don't think the case we're talking about really has to get that
philosophical.  I'm thinking more in practical terms, that having "x =
10" occasionally be a method call, when it (normally, by default, in
"current Ruby", whatever) isn't, would be confusing and awkward, with
no gain.  

> I think the above might not be interesting for general usage, but in
> some cases it could be useful (for instance when one disguises Ruby as
> a domain specific language, in which case there is no concern about the
> "Ruby nature" of the resulting language)

Definitely.  I think Ruby can and should be used for all sorts of
things, including domain-specific languages.  In such a case there's a
clarity of context and expectation which is very different from just
having a method or two in Ruby inside of whose code blocks the rules
of assignment are rewritten.  


David

-- 
David A. Black
dblack / wobblini.net