“Yukihiro Matsumoto” matz@ruby-lang.org wrote in message
news:1032187553.528959.21468.nullmailer@picachu.netlab.jp…
Hi,
Well, will these localized/private variables make it into the next Ruby
release? Because there were some previous objections regarding the single
leading underscore (“I have used leading underscore in my current instance
variables”), or regarding the symmetry (“It will not look balanced”), will
there be any vote on the format of the localized variables:
@_x @__x
@x
@x (ala Python ?)
(or some other second character indicator, such as @#x and @%x ?)
Or will Matz decide on this?
I will. Somewhere around “@_x” and “@x". I don’t care about the
balancing. Those who care may put extra "” after varriable names.
or being my repetitive self
_@x
This probably breaks no (non-obfuscating) existing
code and is quite distinct from regular instance (and
local) variables.
/Christoph
Ps. I am very curious about your opinion on Dave’s
_block_local_variable_idea
(Sorry Dave, hopefully you won’t be haunted by ``the
ghosts that you called’';-).
···
In message “Re: private variables” > on 02/09/16, William Djaja Tjokroaminata billtj@y.glue.umd.edu writes:
private variables being differnt from local ones how? further can a
keyword like this work?. other keywords are just shorthands aren’t they?
well, maybe it can.
I haven’t really read the parser yet, but I imagine that after the
detection of keyword “private”, the parser/interpreter will call
“rb_define_private_method()” instead of “rb_define_method()”. Therefore,
in a similar way, after the detection of the keyword “private”, any newly
detected “@var = …” will not call “rb_iv_set()”, but something like
“rb_private_iv_set()” which just simply writes the data in a separate
hash. Now, the “… = @var” case is a little bit more tricky, but I think
it should invoke “rb_private_iv_get()” before searching using
“rb_iv_get()”.
you see that’s interesting. that’s what i purposed for local variables
to end writer method ambiguities. ie. does x = 1 mean local variable x =
1, or self.x = 1.
I must be missing something. Why can “x = 1” imply “self.x = 1”?
The use of a new symbol.
Ruby is to some extent influenced by Perl, and in Perl “$”, “@”, and
“%” are used to denote the type of variables. Ruby has used “$” and
“@” for special meaning for variables, so this suggests to use “%” prefix
for private variables.
IIRC, neither of $ or @ are used as operators, but % is modulus in Ruby.
I can’t think of any case where it would not be backwards compatible,
but I think it looks confusing:
a = b%c # b modulus c
a = b %c # call method b with one argument; private variable c
But then, perhaps we have enough training dealing with this confusion
due to things like a +5 versus a+5…
Here’s an non-backwards compatible case:
%q__ = “some private thing”
a = %q__
What’s the value of a at this point?
Now, earlier when the talk of local variables came up, I noticed the £
sign sitting to the left of the $ on my keyboard. The pound sign almost
looks like a L too! (L for local. ) Or maybe even §, which looks like to
S’s (supersecret perhaps). Don’t take these ideas too serious though. I
do not prefer to program in ASCII art.
I was musing before on ‘#’, which has a secretive/private connotation,
as a variable prefix Thinking about these things makes one
increasingly grateful for the non-punctuation-riddenness of Ruby.
I’d prefer having something explicit like:
private_variables :some, :privvy, :vars, :listed, :here
making @some, @privvy, @vars, @listed and @here private in that class.
And who knows, perhaps there is some magic tricks to be learned if
privateness can be dynamic and delayed. (I.e. define class, methods and
make instances, then pull a class_eval { private_variables :somevar })
I am not an expert in Ruby parser/interpreter at all (let alone computer
science), but to me this seems perfectly doable. I.e., after the
detection of keyword “private_variables”, all public variables in the list
are moved from the current (public) instance variable hash to the private
instance variable hash. And then writing and reading the instance
variables are like in my other post.
IIRC, neither of $ or @ are used as operators, but % is modulus in Ruby.
I can’t think of any case where it would not be backwards compatible,
but I think it looks confusing:
a = b%c # b modulus c
a = b %c # call method b with one argument; private variable c
But then, perhaps we have enough training dealing with this confusion
due to things like a +5 versus a+5…
Well, “%” is also used in Perl as a modulus operator, and its use with
variables is fine there. Like you have written above, we can make the
rule. But probably people should write code in an explict way…
Personally I’d be sad to see any more double punctuation variable
semantics in Ruby (@@cvar being the only one I can think of). It’s
true that declaring things private (rather than tagging them as
private with an underscore) means that one can’t see privacy at a
glance. But that’s already true of private methods – i.e., their
names are not required to be different from names of other methods.
In this case where do you store class local variables (i.e. what you call
private variables :-)) ?
Whoops, I have reintroduced deprecated terminology into the discussion And I probably can’t answer your question very cogently. But I
guess I’d store them wherever they’d be stored if they were named @_var, only I wouldn’t name them @_var.
In the certainty that this can’t be a satisfactory answer, back to
you…
If you try to use a class-local instance variable and it has not yet
been initialized, I would expect to see a warning when you run with ruby
-w, just like you get now with regular instance variables.
Paul
···
On Mon, Sep 16, 2002 at 11:50:54PM +0900, Christian Szegedy wrote:
Private methods and class-local instance variables are quite different.
If you use a private method, you get an exception. If you try to use
a class-local instance variable then you just use another variable,
which could lead to obscure bugs.
So I think punctuation (and it should be as short as possible)
is a much better option.
This probably breaks no (non-obfuscating) existing
code and is quite distinct from regular instance (and
local) variables.
This also makes sense to me because it reads from left to
right: private (_) instance variable (@x). @_x looks
like “instance va… oh, did I forget to metion it was
private? …riable”.
I haven’t really read the parser yet, but I imagine that after the
detection of keyword “private”, the parser/interpreter will call
“rb_define_private_method()” instead of “rb_define_method()”. Therefore,
in a similar way, after the detection of the keyword “private”, any newly
detected “@var = …” will not call “rb_iv_set()”, but something like
“rb_private_iv_set()” which just simply writes the data in a separate
hash. Now, the “… = @var” case is a little bit more tricky, but I think
it should invoke “rb_private_iv_get()” before searching using
“rb_iv_get()”.
i see. thanks.
so were talking about instance variables being private? ugh, i’m
confused (sorry i didn’t catch the whole of this thread) arn’t instance
variable always private? you can only access them through accessor
methods. i’m missing somthing here.
you see that’s interesting. that’s what i purposed for local variables
to end writer method ambiguities. ie. does x = 1 mean local variable x =
1, or self.x = 1.
I must be missing something. Why can “x = 1” imply “self.x = 1”?
no it can’t which is exaclty what i mean becase any other method will
imply a self, EXCEPT the writer accessor method, unless of course the
local variable is define first. ex-
class It
attr_accessor :x
def seehere
x # same as self.x (self is implied)
x = 10 # not the same as self.x=
x # no longer the same as self.x
end
end
···
On Fri, 2002-09-13 at 14:22, William Djaja Tjokroaminata wrote:
I think you are right that “%X” sometimes is already special in Ruby (such
as %q, %Q, %w, %r, and %x). However, the use of “#” is really scary,
because it will make most, if not all, comments break down.
Hmmm, time to search other Perl symbols… how about "", anyone? Has
this symbol been used in Ruby?
I was musing before on ‘#’, which has a secretive/private connotation,
as a variable prefix Thinking about these things makes one
increasingly grateful for the non-punctuation-riddenness of Ruby.
I’d prefer having something explicit like:
private_variables :some, :privvy, :vars, :listed, :here
making @some, @privvy, @vars, @listed and @here private in that class.
I think this is a matter of taste, but for me a naming convention
seems to be better, since it would be simpler to tell the difference
for a particular variable.
I am not an expert in Ruby parser/interpreter at all (let alone computer
science), but to me this seems perfectly doable. I.e., after the
detection of keyword “private_variables”, all public variables in the list
are moved from the current (public) instance variable hash to the private
instance variable hash. And then writing and reading the instance
variables are like in my other post.
It would mean a slight slowdown for the access of all instance variables,
since you would need two hash lookups instead of one. If you use the naming
convention, the parser would be able to generate a node for the correct
hash lookup: you need only one (like now).
Whoops, I have reintroduced deprecated terminology into the discussion And I probably can't answer your question very cogently. But I
guess I'd store them wherever they'd be stored if they were named @_var, only I wouldn't name them @_var.
and if someone define an instance variable @_var, this instance variable
become a class local variable automatically (because it's stored with
class local variable), no ?
Can’t we just add something like “local_iv_table” in addition to
“generic_iv_table” in variable.c? All local variables will use something
like “rb_local_ivar_set()” and “rb_local_ivar_get()” which refers to
local_iv_table.
In this case where do you store class local variables (i.e. what you call
private variables :-)) ?
Whoops, I have reintroduced deprecated terminology into the discussion And I probably can’t answer your question very cogently. But I
guess I’d store them wherever they’d be stored if they were named @_var, only I wouldn’t name them @_var.
In the certainty that this can’t be a satisfactory answer, back to
you…
In message “Re: private variables” > on 02/09/17, “Christoph” chr_news@gmx.net writes:
I will. Somewhere around “@_x” and “@x". I don’t care about the
balancing. Those who care may put extra "” after varriable names.
or being my repetitive self
_@x
This will not break anything, but too ugly.
you don’t have to tell me “@” alone is ugly.
Jim Hranicky, Senior SysAdmin UF/CISE Department |
E314D CSE Building Phone (352) 392-1499 |
jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh |
“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
