On Tuesday 25 November 2003 05:47 pm, Sean E Russell wrote:
> I know what you mean.  I tend to want to scope things up when using irb;
> that bites me all the time.  However, @ resolves ambiguity:
>
> If we don't have @, then:
>
> class Foo
> 	a = "blah"
> 	def bar
> 		a = 1 + 1
> 	end
> end
>
> What would "a" be?  In this trivial case, it may not be a problem.  But in
> a large class, with a lot of methods, the odds of overriding some instance
> variable has a great potential to introduce bugs. 

Honestly, I have always felt funny about

  @a = a      (Get shivers just looking at it.)

And I avoid it like the plague for everything execept assignments in def 
initialize. You are no doubt correct though, name clashing would have to be 
considered on a larger scale, though we generally already do so, since many 
instance variables are attr methods. In which case local varaible gets 
precedence. To avoid?

  self.a

For an instance variable? That would mean a was a method. And I would say, in 
a way, it is: It is the attribute reader/writer "method" for the instance 
variable. This would mean you'd no longer need to do attr_accessor, 
attr_reader, etc. You might think that this means you could no longer define 
alternate accessor methods OF THE SAME NAME, but with the addition of method 
wrapping this problem is solved. Plus, you can still use specialized names 
for such methods. It also means that internal class code accesses instance 
variables in the same manner as external code. Like defining an accessor and 
using self.a/self.a= everywhere. In fact there was discussion of this, way 
back when, over whether internal code should always use accessors. Of course, 
we must also take into consideration access control. This is easily solved 
using the same means used for regular methods: public, protected, private. 

You also get the upside of getting programmers to use slightly longer more 
descriptive names to avoid the local clash. I use rather long names, myself, 
for everything except the occasional iterator var. Obviosly the down side is 
that the @ is no longer there to immediately give away that it is an instance 
variable rather then a local varible, but we already deal with this in 
connection wih methods and local vars. Actually one of the neat things this 
allows, is to treat @ as simple sugar, such that @a is same as self.a.

> Also, how would you
> declare an instance variable in a method?
>
> def Foo
> 	def bar
> 		a = "Foo"  # I want "a" to be an instance variable
> 		b = "Bar"  # I don't want "b" to be an instance variable
> 	end
> end

Again,

  self.a  = "Foo"

BTW: If your interested in wraps, I've work up a detailed RCR candidate at:

  http://www.rubygarden.org/ruby?AspectOrientedRuby

Sure would appreciate it if others took a gander.

-t0

P.S. I can see David's stomach turning now. I imagine he feels this dosen't 
belong here. We'll okay. I certainly don't wish to offend David. But I feel 
there's somewhat of a disconnect between our mailing lists. This subject 
matter dosen't seem to fit well anywhere. On the regular list it tends to be 
ignored, here accused of impertinence, and obviously it does not belong on 
dev. So perhaps we need another list? ruby-muse? ruby-tech? Either that, or 
we should allow such disccusions here to compliment the more specific "code 
works".

Thoughts?