private variables 
Author Message
 private variables

"ts"  wrote in
...

Quote:
>  Yes, because you've introduced a new type of variable but this is not a

which means one more set of scoping rules to keep mind?  (Probably
not, but even the prospect makes me shudder;-)

Quote:
>  problem with the implementation (i.e. you'll have the same problem with
>  any implementations)


the only thing that breaks is that previously illegal  code would
suddenly be legal.

/Christoph



Mon, 28 Feb 2005 21:27:05 GMT  
 private variables

C> which means one more set of scoping rules to keep mind?  (Probably
C> not, but even the prospect makes me shudder;-)

 If I've well understood, the variable is accessible only in the class
 where it was defined.



C> the only thing that breaks is that previously illegal  code would
C> suddenly be legal.


12
pigeon%

 Except for obfuscation, I don't think that someone use it :-)

Guy Decoux



Mon, 28 Feb 2005 22:07:22 GMT  
 private variables

Quote:

> which means one more set of scoping rules to keep mind?  (Probably
> not, but even the prospect makes me shudder;-)

Actually, that raises an interesting point.

If we're (somewhat unfortunately, imo) using '_' to denote 'localized',
then should we be using more orthogonally?


  _a   - localized block variable,

       _a = 1

       10.times {|_a| puts _a}

       puts _a  # => 1

If we're going down this route (and I'm wondering if I think we
should), then we can at least make us of the options.

Dave



Mon, 28 Feb 2005 22:17:56 GMT  
 private variables

On Thu, 12 Sep 2002 23:17:03 +0900

Quote:


> > which means one more set of scoping rules to keep mind?  (Probably
> > not, but even the prospect makes me shudder;-)

> Actually, that raises an interesting point.

> If we're (somewhat unfortunately, imo) using '_' to denote 'localized',
> then should we be using more orthogonally?


>   _a   - localized block variable,

>        _a = 1

>        10.times {|_a| puts _a}

>        puts _a  # => 1

> If we're going down this route (and I'm wondering if I think we
> should), then we can at least make us of the options.

How about an attr_private directive?

  class Foo
      attr_accessor :a, :b;
      attr_private  :c
  end

  class Bar < Foo
      attr_accessor :c
  end

  x = Bar.new
  p x.c # Actually using Bar::c, not Foo::c

Seems syntactically cleaner to me. Of course, throwing back to the local block
variable thing, how about

  - default to all local, indicate lookups in previous scopes with ::

        foo.each { |x,::y|

                a = x           # local a modified, value of local x
                ::b = y         # global b now value of global y

        }
?

----------------------------------------------------------------------
| Jim Hranicky, Senior SysAdmin                   UF/CISE Department |
| E314D CSE Building                            Phone (352) 392-1499 |

----------------------------------------------------------------------

"Given a choice between a complex, difficult-to-understand, disconcerting
 explanation and a simplistic, comforting one, many prefer simplistic
 comfort if it's remotely plausible, especially if it involves blaming
 someone else for their problems."
                                                -- Bob Lewis, _Infoworld_

  application_pgp-signature_part
< 1K Download


Mon, 28 Feb 2005 23:21:28 GMT  
 private variables

D>   _a   - localized block variable,
D>        _a = 1
D>        10.times {|_a| puts _a}
D>        puts _a  # => 1

 This is easy

pigeon% ruby -e '_a = 12; 3.times {|_a| puts _a}; puts _a'
0
1
2
12
pigeon%

 :-)

Guy Decoux



Mon, 28 Feb 2005 23:24:51 GMT  
 private variables

"ts" wrote in
...

Quote:
> pigeon% ruby -e '_a = 12; 3.times {|_a| puts _a}; puts _a'
> 0
> 1
> 2
> 12
> pigeon%

>  :-)

Neato! -- Actually I sort of like Dave's idea - it is probably
better then the 1001  incarnations of

  {<a; b |   local z
    i_am_block_local := ...
    etc
    }

/Christoph



Tue, 01 Mar 2005 08:52:01 GMT  
 private variables
Hi,

In message "Re: private variables"

|> Oh, I forget to mention that private instance variables should not be
|> exported by attr_accessor etc., because of the fact these variables
|> are private.  Publicly exported private instance variable is
|> contradicting existence.

|I wonder why. Could you give some concrete reason for it?
|
|I thought, being private for a variable means that it can
|only be acessed by the methods of its class to avoid
|name collisions with instance variables in derived classes.

Yes.  Hence it should not be exported as an attribute method, which
can be seen from everywhere.  Am I missing something?

                                                        matz.



Tue, 01 Mar 2005 11:22:05 GMT  
 private variables

Quote:

> In message "Re: private variables"

> |I thought, being private for a variable means that it can
> |only be acessed by the methods of its class to avoid
> |name collisions with instance variables in derived classes.

> Yes.  Hence it should not be exported as an attribute method, which
> can be seen from everywhere.  Am I missing something?

There is a (narrow) use here, where one might like to have a private
instance variable and share it out with attr_* methods; avoiding
namespace pollution in baseclasses that are to be subclassed alot.
        That is, one wants to use private instance variable to protect one self
vertically in the inheritance tree. (I could see myself using both
attr_writer and attr_reader on private instance variables, while
attr_accessor is less likely.) Along the horizontal, I think that Ruby
provides enough protection.

Now, I don't see losing attr_* for private instance variables a big
loss. But at the same time, I do not see it as a requirement that they
are prohibited. If I was being terribly pragmatic about it, I'd
implement private instance variables any way I could, and not really
care about attr_*. If they still work with private instance variables,
keep them. If they don't work, ignore them.
        Only time I would pour energy and time on them with regards to private
instance variables, is if PoLS might be violated. For example, if the
syntax would allow you to write an attr_* that appears to expose the
variable, but it is actually some other variable that gets accessed.

My 0.02 NOK

--
(\[ Kent Dahl ]/)_    _~_    __[ http://www.stud.ntnu.no/~kentda/ ]___/~
 ))\_student_/((  \__d L b__/  NTNU - graduate engineering - 5. year  )
( \__\_?|?_/__/ ) _)Industrial economics and technological management(
 \____/_?_\____/ (____engineering.discipline_=_Computer::Technology___)



Tue, 01 Mar 2005 14:56:05 GMT  
 private variables
Hi,

In message "Re: private variables"

|There is a (narrow) use here, where one might like to have a private
|instance variable and share it out with attr_* methods; avoiding
|namespace pollution in baseclasses that are to be subclassed alot.

Possible.  But, you know, attr_accessor is just a short form of:

  def foo

  end
  def foo=(val)

  end

So you can export a private instance variable as an attribute by hand,
but not by attr_accessor, etc.

                                                        matz.



Tue, 01 Mar 2005 16:31:00 GMT  
 private variables






X-ML-Name: ruby-talk
X-Mail-Count: 50150
X-MLServer: fml [fml 3.0pl#17]; post only (anyone can post)
X-ML-Info: If you have a question, send e-mail with the body


X-Mailer: Ximian Evolution 1.0.5
Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Precedence: bulk
Lines: 21

Quote:

> Neato! -- Actually I sort of like Dave's idea - it is probably
> better then the 1001  incarnations of

>   {<a; b |   local z
>     i_am_block_local := ...
>     etc
>     }

is that colon there on purpose?

if so, it woulld also  get rid of the ambiguity between local variable
assignment and calling standard writter methods.

just fyi

--
tom sawyer, aka transami



Tue, 01 Mar 2005 21:42:08 GMT  
 private variables
Hi --

Quote:


> > Neato! -- Actually I sort of like Dave's idea - it is probably
> > better then the 1001  incarnations of

> >   {<a; b |   local z
> >     i_am_block_local := ...
> >     etc
> >     }

> is that colon there on purpose?

> if so, it woulld also  get rid of the ambiguity between local variable
> assignment and calling standard writter methods.

I think Christoph's point (with the colon and the rest of the
punctuation) was to illustrate the visual and stylistic dangers
of such things :-)

David

--
David Alan Black                      | Register for RubyConf 2002!


Web:  http://pirate.shu.edu/~blackdav | http://www.rubyconf.com



Tue, 01 Mar 2005 23:02:31 GMT  
 private variables

Quote:

>   _a   - localized block variable,

>        _a = 1

>        10.times {|_a| puts _a}

>        puts _a  # => 1

Interesting idea.  

Would non-localized block variables:
  a) retain their original behavior (that is, they are local if the
     variable already exists in the outer block, otherwise they are
     non-local), or
  b) always be non-local?

I like (b) since it's cleaner, but (a) because it doesn't break any
code.

On a side note, I wish there were another symbol that could be used in
place of _.  It makes variables look asymmetric (unless you write _a_).

Paul



Wed, 02 Mar 2005 00:42:05 GMT  
 private variables

Quote:


> >   _a   - localized block variable,

> >        _a = 1

> >        10.times {|_a| puts _a}

> >        puts _a  # => 1

> Interesting idea.  

> Would non-localized block variables:
>   a) retain their original behavior (that is, they are local if the
>      variable already exists in the outer block, otherwise they are
>      non-local), or
>   b) always be non-local?

> I like (b) since it's cleaner, but (a) because it doesn't break any
> code.

> On a side note, I wish there were another symbol that could be used in
> place of _.  It makes variables look asymmetric (unless you write _a_).

> Paul

Wasn't there some talk about using symbols?  It's not symmetric, but for
some reason it looks better to me.

a = 1

10.times { |:a| puts a }

puts a # => 1

--
Alan Chen
Digikata LLC
http://digikata.com



Wed, 02 Mar 2005 02:09:28 GMT  
 private variables

d> I think Christoph's point (with the colon and the rest of the
d> punctuation) was to illustrate the visual and stylistic dangers
d> of such things :-)

 No, no see [ruby-talk:12555]

  {
    e = 1    # e may or may not be local to the block
    f := 2   # f is always local to this block
  }

Guy Decoux



Wed, 02 Mar 2005 02:50:19 GMT  
 private variables
Well, I am proposing 2 alternatives that I think is more consistent with
the rest of Ruby.

1) The use of the keyword "private"
Any methods defined after this keyword is private.  So probably we can
make any new instance variables created after this keyword to be also
private.  But mixing the private and non-private variables will be
confusing.

2) The use of a new symbol.

"%" are used to denote the type of variables.  Ruby has used "$" and

for private variables.

Regards,

Bill
============================================================================

Quote:

>> On a side note, I wish there were another symbol that could be used in
>> place of _.  It makes variables look asymmetric (unless you write _a_).

>> Paul
> Wasn't there some talk about using symbols?  It's not symmetric, but for
> some reason it looks better to me.
> a = 1
> 10.times { |:a| puts a }
> puts a # => 1
> --
> Alan Chen
> Digikata LLC
> http://digikata.com



Wed, 02 Mar 2005 02:53:28 GMT  
 
 [ 88 post ]  Go to page: [1] [2] [3] [4] [5] [6]

 Relevant Pages 
 

 
Powered by phpBB® Forum Software