Attempted roadmap of future instance variables

[Weirich_James]

Oh, not that it matters but I got that wrong. Tied for first
with doing nothing. @_ way down at third

I tend to agree with this. Having both protected and private instance
variables is overkill and complicates the language. If private instance
variables are prefered, then make them all that way. It will break
portability, but we expect some of that in moving to Ruby 2.

Besides, leading underscores are /ugly/. Leading underscores prefixed by @
are /very ugly/.

So, here’s my vote to not have two different kinds of instance variables.

···

From: David A. Black [mailto:dblack@wobblini.net]

–
– Jim Weirich / Compuware
– FWP Capture Services
– Phone: 859-386-8855

[Chris_Thomas]

Me too. It’s hard to sell Ruby to others in an organization where
Python is the easy and safe choice. Adding “@_” would definitely be an
argument against Ruby in that context.

Chris

···

On Dec 5, 2003, at 10:31 AM, Weirich, James wrote:

From: David A. Black [mailto:dblack@wobblini.net]

Oh, not that it matters but I got that wrong. Tied for first
with doing nothing. @_ way down at third

I tend to agree with this. Having both protected and private instance
variables is overkill and complicates the language. If private
instance
variables are prefered, then make them all that way. It will break
portability, but we expect some of that in moving to Ruby 2.

Besides, leading underscores are /ugly/. Leading underscores prefixed
by @
are /very ugly/.

So, here’s my vote to not have two different kinds of instance
variables.

[Chad_Fowler]

From: David A. Black [mailto:dblack@wobblini.net]

···

On Sat, 6 Dec 2003, Weirich, James wrote:

> Oh, not that it matters but I got that wrong. Tied for first

> with doing nothing. @_ way down at third

I tend to agree with this. Having both protected and private instance

variables is overkill and complicates the language. If private instance

variables are prefered, then make them all that way. It will break

portability, but we expect some of that in moving to Ruby 2.

Besides, leading underscores are /ugly/. Leading underscores prefixed by @

are /very ugly/.

So, here’s my vote to not have two different kinds of instance variables.

+1 to having either/or private/protected (but not both). And, I also
dislike the @_notation.

Chad

[Laurent_Julliard4 (Laurent Julliard)]

well, not about really selling it, but when I need to explain ruby to
a friend:
“well, you @instance_vars, $global, and local, Easy ain’t it ?
Oh, and, yes, you have @@class_vars.
And, then, you have…”

BTW, pushing ruby is not so important to me.
The real point is that @_ is ugly to me

···

il Sat, 6 Dec 2003 03:48:22 +0900, Chris Thomas chris@m-audio.com ha scritto::

Me too. It’s hard to sell Ruby to others in an organization where
Python is the easy and safe choice. Adding “@_” would definitely be an
argument against Ruby in that context.

[Yukihiro_Matsumoto2 (Yukihiro Matsumoto)]

Hi,

···

In message “Re: Attempted roadmap of future instance variables…” on 03/12/06, Chris Thomas chris@m-audio.com writes:

Me too. It’s hard to sell Ruby to others in an organization where
Python is the easy and safe choice. Adding “@_” would definitely be an
argument against Ruby in that context.

I don’t think so. Python has basically same feature. attributes with
preceding “__” becomes class local in Python.

						matz.

[HAL_9000]

gabriele renzi wrote:

well, not about really selling it, but when I need to explain ruby to
a friend:
“well, you @instance_vars, $global, and local, Easy ain’t it ?
Oh, and, yes, you have @@class_vars.
And, then, you have…”

I see your point. My explanation would be more like:
“In Perl, a prefix indicates type; in Ruby, it indicates
scope. Locals and methods are unprefixed, etc.”

BTW, pushing ruby is not so important to me.

It is to me, though.

The real point is that @_ is ugly to me

Agreed.

Hal

[Christoph]

gabriele renzi wrote:
…

well, not about really selling it, but when I need to explain
ruby to a friend:
"well, you @instance_vars, $global, and local, Easy ain’t it ?
Oh, and, yes, you have @@class_vars.

That the reason why I am in favor of eliminating @@var’s
[ruby-talk:86744] and replacing their role with “class_accessors”.

And, then, you have…"

BTW, pushing ruby is not so important to me.
The real point is that @_ is ugly to me

Actually I’d don’t mind the @_var notation esthetically - in fact
both @@var and $var are more unappealing to me - (I dislike
the latter the most, even €var looks better to me:-)

/Christoph

[David_A_Black3 (David A. Black)]

Hi –

···

On Sat, 6 Dec 2003, Yukihiro Matsumoto wrote:

Hi,

In message “Re: Attempted roadmap of future instance variables…” > on 03/12/06, Chris Thomas chris@m-audio.com writes:

Me too. It’s hard to sell Ruby to others in an organization where
Python is the easy and safe choice. Adding “@_” would definitely be an
argument against Ruby in that context.

I don’t think so. Python has basically same feature. attributes with
preceding “__” becomes class local in Python.

It could still be an argument against Ruby in the sense that it might
take away part of one argument for Ruby, in some people’s minds, in
a situation like that.

(Disclaimer: I don’t actually know anything about the so-called “real
world”.)

David

–
David A. Black
dblack@wobblini.net

[Chris_Thomas]

To be clear, my issue is the proposed syntax, not the class-local
feature itself. I think “@_” is not particularly readable. Also, those
“__” variables are one of the things that I don’t like about Python.

For what it’s worth,
Chris

···

On Dec 6, 2003, at 5:10 AM, Yukihiro Matsumoto wrote:

Hi,

In message “Re: Attempted roadmap of future instance variables…” > on 03/12/06, Chris Thomas chris@m-audio.com writes:

Me too. It’s hard to sell Ruby to others in an organization where
Python is the easy and safe choice. Adding “@_” would definitely be an
argument against Ruby in that context.

I don’t think so. Python has basically same feature. attributes with
preceding “__” becomes class local in Python.

[Jesse_Tov]

David A. Black dblack@wobblini.net:

I don’t think so. Python has basically same feature. attributes with
preceding “__” becomes class local in Python.

It could still be an argument against Ruby in the sense that it might
take away part of one argument for Ruby, in some people’s minds, in
a situation like that.

[If you don’t want to read my rambling about language design and some
rationale, please skip down to my proposal at “TALKING ABOUT RUBY
STARTS HERE.”]

“__” is one of the things that turned me off to Python. It wasn’t
explained in the tutorials I read, so it was confusing. Magic names
seem to be in general confusing to newbies. Two examples:

1. I decided to learn Dylan last week, and I spent quite a while
   wondering if there was some signficance to variable-names-like-this
   or to . It was a while before I found out
   that it’s just convention.

2. A friend of mine spent all night a few weeks ago trying to get
   a Haskell program to compile. He didn’t know that type
   constructors and data constructors have to start with a capital
   letter (well, or a colon).

These lexical rules can be confusing, and Perl-style punctuation

···

On Sat, 6 Dec 2003, Yukihiro Matsumoto wrote:
on names is ugly, but we have good reasons for them. For example, Haskell’s rules remove some funny ambiguities that show up with SML pattern matching. (fun X = 5 – is X a variable or a nullary data constructor? It depends…) Likewise, Perl’s @&$% names make “auto-vivication” work better, if auto-vivication could ever be said
to work well.

However, languages aren’t designed for newbies. Introductory tutorials
should make issues like naming clear, and languages should be designed to
work best for the people actually writing lots of code in them.

TALKING ABOUT RUBY STARTS HERE

I should write about Ruby, in case anyone’s still reading, since I have
a proposal. Ruby’s naming rules exist for a really good reason: To
make it easy to use differently-scoped variables without ever declaring
anything about them. (Unless Matz says differently, I guess.) Adding a
new kind of variable that requires a declaration, as some have suggested,
would be pretty inconsistent. Adding a new prefix (@_a) would be
consistent, but it adds to the confusion. On the other hand, it would
be easy to search for where it breaks old code.

After a lot of discussion about this, it seems clear to me that the point
of instance local variables isn’t about privacy so much as preventing
accidental collisions. That calls for a solution that makes it easy
to access parents’ instance locals, while still differentiating their
namespaces. The proposed use of “namespace” seems a bit syntactically
heavy, though. So, I’m going to propose something analogous to the
case of Foo versus ::Foo:

 @a         instance local
 @::a       parent's instance local
 @Foo::a    ancestor-named-Foo's instance local

It doesn’t add anything new, since :: already exists for similar things.
It’s lightweight and non-restrictive, and seems to blend into the
language pretty well to me. Here’s an example:

class A
  def a=(x)
    @foo = x
  end
end

class B < A
  def b=(x)
    @foo = x
  end
end

class C < B
  def c=(x)
    @foo = x
  end

  def c;
    @foo
  end

  def b;
    @::foo    # could also be @B::foo
  end

  def a
    @A::foo
  end
end

c = C.new
c.a = 1
c.b = 2
c.c = 3

puts(c.a, c.b, c.c)   ==> 1, 2, 3

Jesse

(Please forgive me for delurking in this fashion.)

[HAL_9000]

Jesse Tov wrote:

[snippage]

I should write about Ruby, in case anyone’s still reading, since I have
a proposal. Ruby’s naming rules exist for a really good reason: To
make it easy to use differently-scoped variables without ever declaring
anything about them. (Unless Matz says differently, I guess.) Adding a
new kind of variable that requires a declaration, as some have suggested,
would be pretty inconsistent. Adding a new prefix (@_a) would be
consistent, but it adds to the confusion. On the other hand, it would
be easy to search for where it breaks old code.

After a lot of discussion about this, it seems clear to me that the point
of instance local variables isn’t about privacy so much as preventing
accidental collisions. That calls for a solution that makes it easy
to access parents’ instance locals, while still differentiating their
namespaces. The proposed use of “namespace” seems a bit syntactically
heavy, though. So, I’m going to propose something analogous to the
case of Foo versus ::Foo:

 @a         instance local
 @::a       parent's instance local
 @Foo::a    ancestor-named-Foo's instance local

It doesn’t add anything new, since :: already exists for similar things.
It’s lightweight and non-restrictive, and seems to blend into the
language pretty well to me. Here’s an example:

[snip snip]

At first glance, I think I like this.

(Please forgive me for delurking in this fashion.)

De-lurk more often. You seem to reason well, not to mention spelling
and punctuation.

Of course, someone else may point out why this isn’t good. I certainly
have not thought it through yet.

Hal

[David_A_Black3 (David A. Black)]

Hi –

After a lot of discussion about this, it seems clear to me that the point
of instance local variables isn’t about privacy so much as preventing
accidental collisions. That calls for a solution that makes it easy
to access parents’ instance locals, while still differentiating their
namespaces. The proposed use of “namespace” seems a bit syntactically
heavy, though. So, I’m going to propose something analogous to the
case of Foo versus ::Foo:

 @a         instance local
 @::a       parent's instance local
 @Foo::a    ancestor-named-Foo's instance local

It doesn’t add anything new, since :: already exists for similar things.
It’s lightweight and non-restrictive, and seems to blend into the
language pretty well to me.

You’re right that :: already exists in the language, but I think
there’s a big difference between using, say, A::x or A::X to get at a
class method or constant, and using @A::x to get at an instance
variable that happens to have been used in methods defined in A –
namely, that A::x and A::X are documented. Whoever’s writing the
class definition of A is not going to treat @x (and shouldn’t have to
treat it) like part of the public interface, for purposes of
documentation, version-number adjustment for incompatible releases,
etc.

Here’s an example of breakage under innocent refactoring:

class A
def learn; @speech ||= “Hello”; end
def talk; puts @speech; end
end

class B < A
end

class C < B
def yell; puts @A::speech.uppercase
end

Then we (or some library writer) decides to do this instead:

class Speaker; def learn… def talk… end
class A < Speaker; end

etc.

So now the variable is @Speaker::speech, so the definition of yell
doesn’t work.

One could say: the solution is to study the code you’re inheriting
from. In that case, though, name collision isn’t going to be an
issue. But that, too, really unencapsulates things.

David

···

On Sun, 7 Dec 2003, Jesse Tov wrote:

–
David A. Black
dblack@wobblini.net

[Christoph4 (Christoph)]

Jesse Tov wrote
…

2. A
   It doesn’t add anything new, since :: already exists for similar things.
   It’s lightweight and non-restrictive, and seems to blend into the
   language pretty well to me. Here’s an example:

class A
  def a=(x)
    @foo = x
  end
end

class B < A
  def b=(x)
    @foo = x
  end
end

class C < B
  def c=(x)
    @foo = x
  end

  def c;
    @foo
  end

  def b;
    @::foo    # could also be @B::foo
  end

  def a
    @A::foo
  end
end

c = C.new
c.a = 1
c.b = 2
c.c = 3

puts(c.a, c.b, c.c)   ==> 1, 2, 3

If we go that route we might as well introduce this
(possibly instead) for methods too (there was some
demand for this kind appility in connection with mixins)

class A
def foo
p “A”
end
end
class B <A
end
class C < B
def foo
end
end

C.new.foo # “A”

/Christoph

···

A::foo

[Dan_Doel]

The only thing I can see being a problem is if a class’s mix-in 'parent’
needs to share a variable with a class’s class-inheritance parent. It
would be awkward for them to have to know about each other
since that limits code generality.

This might not be a problem that realistically arises, though. I’m not
really sure.

Other than that, I have to say that I like this proposal more than any
others (other than ‘leave things alone’ maybe).

• Dan

[ts1 (ts)]

class A
    def foo
        p "A"
    end
end
class B <A
end
class C < B
    def foo
        A::foo
    end
end

C.new.foo # "A"

nice, very nice

svg% cat b.rb
#!/usr/bin/ruby
class A
   def self.foo
      p "A"
   end
end
class B <A
end
class C < B
   def foo
   end
end

C.new.foo # "A"
svg%

svg% b.rb
"A"
svg%

Guy Decoux

···

A::foo

[Jesse_Tov]

Dan Doel djd15@po.cwru.edu:

The only thing I can see being a problem is if a class’s mix-in ‘parent’
needs to share a variable with a class’s class-inheritance parent. It
would be awkward for them to have to know about each other
since that limits code generality.

Hm. I’m not sure, but it may not have to be a problem. If @::a refers to
@a in the class-inheritance parent, then it can mean the same thing from
a mixin that is mixed-in at the same level. The mixin parent clearly needs
to know that the class parent exists, even if it doesn’t know what it is;
the class parent doesn’t need to know about the mixin parent. So if they
need to share something, the mixin should go ahead and use the class
parent’s instance variable.

I’m having a hard time making clear what I mean, so consider this. If
you have:

module M
class A
class B < A include M

then @::a used in M refers to A’s @a, since A is the class-parent at the
level where B is included. I’m not sure what happens if we add:

class C < B include M

There’s also the possibility of defining a light syntax such as @:: as
sugar for a heavier namespace syntax. There might be trickier things
that could only be done with the heavier syntax, but the light syntax
would work most of the time.

This might not be a problem that realistically arises, though. I’m not
really sure.

“No one will ever need that” are famous first words.

Jesse

[Christoph4 (Christoph)]

ts wrote
…

nice, very nice

ooops:-)))

svg% cat b.rb
#!/usr/bin/ruby
class A
def self.foo
p “A”
end
end
class B <A
end
class C < B
def foo
A::foo
end
end

okay lets use @, ~ , :local:, whatever
instead of “::” - note I was not really
advocating this.

/Christoph

[ts1 (ts)]

    module M
    class A
    class B < A include M

then @::a used in M refers to A's @a, since A is the class-parent at the
level where B is included. I'm not sure what happens if we add:

    class C < B include M

nothing, ruby never include twice the same module

Guy Decoux