ambiguity between local variable assignment and writter method
dbl...@candle.superlink.net
On Sat, 10 Aug 2002, Tom Sawyer wrote:
> does anyone else find it annoying that local variable assignment is
> indistinguishable from a writter method.
(Not ignoring the rest of the thread -- just wanted to comment on the
underlying question.)
At first, I found it to be a minor but noticeable fly in the
ointment. However, I've come to think it's a small price to pay,
Cons:
1. you have to type what feels like an "extra" "self".
Pros:
1. in Ruby, you get to leave "self" off a lot, so having it not be
100% of the time isn't so bad. One can think of it as: you have
to specify the receiver, except where it's clear without it, and
it's clear without it much of the time (which I like).
2. The "self.thing = x" form is, ultimately, completely consistent
with Ruby syntax in general; we're not being asked to do
something anomalous. Even though this is a special case, it's
not special syntax. It's just disambiguation.
3. It's one of the rites of passage into Ruby to have to master
this, sort of like realizing that #{...} can interpolate more
than just single variables :-)
Follow-up to #2: for that reason (i.e., providing a receiver is normal
Ruby syntax), I'd rather it were left like this than that any new
construct were added to avoid it. That seems like a potentially
never-ending spiral: define syntax; where it's ambiguous, instead of
requiring strict/explicit usage *within* the syntax, introduce a new
construct; eventually, something will crop up with the new construct
that requires disambiguation; create new syntax for that... etc.
David
--
David Alan Black
home: dbl...@candle.superlink.net
work: blac...@shu.edu
Web: http://pirate.shu.edu/~blackdav
Tom Sawyer
> Cons:
>
> 1. you have to type what feels like an "extra" "self".
2. you have to know when you need the extra self and when you don't
3. code looks spotty with self used sometimes but not others
4. code is longer
5. writer methods have an EXCEPTION in their behavior
> Pros:
>
> 1. in Ruby, you get to leave "self" off a lot, so having it not be
> 100% of the time isn't so bad. One can think of it as: you have
> to specify the receiver, except where it's clear without it, and
> it's clear without it much of the time (which I like).
counter-argument: "isn't so bad" isn't good enough, unless there are no
reasonable alternatives. if there is a good alternative, for all of the
time, why not take it?
> 2. The "self.thing = x" form is, ultimately, completely consistent
> with Ruby syntax in general; we're not being asked to do
> something anomalous. Even though this is a special case, it's
> not special syntax. It's just disambiguation.
counter-argument: don't really see this as a PRO. you are right, it is
consistent and you can use self all you want, whether you need to or
not. that's fine. i'm certainly not suggesting that we throw out self.
self is very essential.
> 3. It's one of the rites of passage into Ruby to have to master
> this, sort of like realizing that #{...} can interpolate more
> than just single variables :-)
counter-argument: such can never be a PRO, in fact, no offense, but it
smacks of ruby righteousness. it also flys in the face of POLS. you
don't judge a thing "good" b/c it is difficult and overcoming the
difficulty gives you a sense of accomplishment. if that were the case we
should all be coding in machine code. :-)
> Follow-up to #2: for that reason (i.e., providing a receiver is normal
> Ruby syntax), I'd rather it were left like this than that any new
> construct were added to avoid it. That seems like a potentially
> never-ending spiral: define syntax; where it's ambiguous, instead of
> requiring strict/explicit usage *within* the syntax, introduce a new
> construct; eventually, something will crop up with the new construct
> that requires disambiguation; create new syntax for that... etc.
i agree. i don't want to add any new constructs. and i don't think we
need to in order to clear up this inconsistency. simply giving
precedence to writer methods would do it.
--
~transami
dbl...@candle.superlink.net
On Sat, 10 Aug 2002, Tom Sawyer wrote:
> On Fri, 2002-08-09 at 22:50, dbl...@candle.superlink.net wrote:
>
> > Cons:
> >
> > 1. you have to type what feels like an "extra" "self".
>
> 2. you have to know when you need the extra self and when you don't
Isn't it good to have to know when you're calling a method and when
you're assigning to a local variable :-)
> 5. writer methods have an EXCEPTION in their behavior
It's just a constraint, not an exception. Just as in some situations
you have to use parentheses, in some situations you have to name your
receiver.
> > Follow-up to #2: for that reason (i.e., providing a receiver is normal
> > Ruby syntax), I'd rather it were left like this than that any new
> > construct were added to avoid it. That seems like a potentially
> > never-ending spiral: define syntax; where it's ambiguous, instead of
> > requiring strict/explicit usage *within* the syntax, introduce a new
> > construct; eventually, something will crop up with the new construct
> > that requires disambiguation; create new syntax for that... etc.
>
> i agree. i don't want to add any new constructs. and i don't think we
> need to in order to clear up this inconsistency. simply giving
> precedence to writer methods would do it.
(At one point you suggested "localvar := x", though I won't argue if
you've reconsidered :-) Anyway -- with regard to defaulting to writer
methods, rather than to local variables: the problem arises that you
can't know what will be present at a given point in the execution of
the program. For example (pointless code, but just for illustration):
class A
def initialize(n)
thing = n
puts "Initializing with argument #{thing}."
end
end
class B < A
attr_writer :thing
end
What happens when you now say:
b = B.new(123)
Does "thing = n", from B's superclass, now suddenly mean
"self.thing = n", rather than assigning to a local variable?
(Obviously part of the picture is that subclasses of A cannot and must
not know anything about the names of local variables in instance
methods of A.)
In other words: the meaning of "thing = n" has to be determined, once
and for all, when it's first encountered; and the only thing it can
definitely be in every single case is a local variable assignment.
(I think this is related to what Dave was saying about subclasses in
response to Rich, though that's in a slightly different context.)
Tom Sawyer
> def initialize(n)
> thing = n
> puts "Initializing with argument #{thing}."
> end
> end
>
> class B < A
> attr_writer :thing
> end
>
> What happens when you now say:
>
> b = B.new(123)
>
..
> (I think this is related to what Dave was saying about subclasses in
> response to Rich, though that's in a slightly different context.)
i see. yes, that would be a problem. although there are plenty of
particulars of knowing how the superclass and the subclass will
interact, so i do not see that as going against it. the fact that the
interaction is not a one-thing-to-its-like-thing but rather a local
varible assignment interacting/interferring with a method, that is
problematic. and this just would not work. you are right.
and i am assumming too that Rich's idea has the same problem.
yes, i did suggest := and/or .= earlier, but only as speed convience. i
would not not vote for it.
now there only seems two options left, and they are both constructions.
the construction just stated above (:=) or, and i think the proper way
to have done it, a prefix symbol for local variables.
%localvariable = 'i am me, not some method'
unfortunately that's just not going to go over well with the population
at large. and i can only wish that it was included early on. all
variables would have a prefix (%, @, @@, $) and methods would not, Ruby
might be a tad faster, and our conversation would never had to exist.
;-)
~transami
p.s outside of another solution. i have to fall back, unless you all
like %, yeah right! :-}
thanks!
George Ogata
> the construction just stated above (:=) or, and i think the proper way
> to have done it, a prefix symbol for local variables.
>
> %localvariable = 'i am me, not some method'
>
You're kidding, right? I think one of the things that makes Perl so unreadable is the
amount of $$wildlife \@growing %out[$of] =~ /the/ \${@writing} $! It's nice the way ruby
doesn't go over the top with it, and perhaps even at times uses it to improve readability.
> unfortunately that's just not going to go over well with the population
> at large. and i can only wish that it was included early on. all
> variables would have a prefix (%, @, @@, $) and methods would not, Ruby
> might be a tad faster, and our conversation would never had to exist.
> ;-)
I'd say locals don't use prefixes (prefices?) since locals are (one of) the most common
identifiers used, and that sort of junk ought to be minimized.
I'd personally rather lose the o.member = 'something' notation for method calling. As
David Alan Black mentioned:
>> Isn't it good to have to know when you're calling a method and when
>> you're assigning to a local variable :-)
Anyhow, I wouldn't consider anything backward-incompatible likely to be worthy of
Rubydom.
Mauricio Fernández
> On Fri, 2002-08-09 at 15:37, Dave Thomas wrote:
> > The behavior of parent classes would vary if they were subclassed by
> > classes that defined specific accessors, which might be upsetting.
>
> could you elaborate on that a touch more? perhaps a small example?
>
This is how I see it:
class A
def initialize(blah)
@blah = blah
end
def amethod(*args)
# do things with args
puts "I don't expect anything special to happen in the next line"
@blah = ... # doesn't use accessor as there isn't one
end
end
class B < A
def blah=(thing)
# do something with thing
puts "Hey, doing things in self.blah=, which may be wrong!"
@blah = ...
end
end
obj = B.new
obj.amethod(...)
# vim: ts=4:
@blah=... inside amethod, defined in class A, will use self.blah=, which
could be wrong if you really need low-level access to the attribute.
amethod expects @blah not to use an accessor, so you're changing the
behavior of things belonging to the superclass. This isn't as
if you were overloading a method, since there's no easy way to avoid
self.blah= being called...
One solution: each method using @attr=... would have to ignore accessors
defined in derived classes. This involves changing the way Ruby looks for
methods, but I don't think it would be that hard.
This would however make Ruby dirtier, and I don't quite think I'd like that :-|
--
_ _
| |__ __ _| |_ ___ _ __ ___ __ _ _ __
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com
'Ooohh.. "FreeBSD is faster over loopback, when compared to Linux
over the wire". Film at 11.'
-- Linus Torvalds
Tom Sawyer
> > now there only seems two options left, and they are both constructions.
> > the construction just stated above (:=) or, and i think the proper way
> > to have done it, a prefix symbol for local variables.
> >
> > %localvariable = 'i am me, not some method'
> >
>
> You're kidding, right? I think one of the things that makes Perl so unreadable is the
> amount of $$wildlife \@growing %out[$of] =~ /the/ \${@writing} $! It's nice the way ruby
> doesn't go over the top with it, and perhaps even at times uses it to improve readability.
no, if i were creating ruby now, i would very much consider doing that.
certainly it adds an extra char to all local vars, but it makes things
quite distinct.
> > unfortunately that's just not going to go over well with the population
> > at large. and i can only wish that it was included early on. all
> > variables would have a prefix (%, @, @@, $) and methods would not, Ruby
> > might be a tad faster, and our conversation would never had to exist.
> > ;-)
>
> I'd say locals don't use prefixes (prefices?) since locals are (one of) the most common
> identifiers used, and that sort of junk ought to be minimized.
do you consider @, @@, and $ junk?
you know other languages have commands to specify the access level of
variables. so you can't tell the difference just by looking at them. you
code something like 'global avar' or 'public avar'.
> I'd personally rather lose the o.member = 'something' notation for method calling. As
> David Alan Black mentioned:
>
> >> Isn't it good to have to know when you're calling a method and when
> >> you're assigning to a local variable :-)
so you think writer methods are the problem? what would they be replaced
with?
> Anyhow, I wouldn't consider anything backward-incompatible likely to be worthy of
> Rubydom.
nor would i, well, unless it was really really good.
--
~transami
Kent Dahl
> 5. writer methods have an EXCEPTION in their behavior
The real base of the exception is that Ruby allows some rather wierd
symbols in the method names. Personally I'd be more likely to alias my
writer methods to set_* methods, if I found myself using them alot from
inside the class and annoyed at all the selfs. (But then again, C++ and
Java will do the first to your brain and the latter don't apply to me
that much :-)
The exception is also tied to the ambiguity of optional parenthesis,
allowed spaces between name and = when calling, and in general its a
very exceptional thing to begin with, to help code outside the class be
readable. One might use stricter call syntax on the inside of the class
to get rid of the ambiguity without self, i.e.
class X
attr_accessor :x
def test
x=(5) # == self.x=5
x =(5) # == x = 5
x= (5) # == x = 5
end
end
But that seems like a bug waiting to bite also.
> i agree. i don't want to add any new constructs. and i don't think we
> need to in order to clear up this inconsistency. simply giving
> precedence to writer methods would do it.
Dave mentioned the performance issue, which I believe would be very
significant. Upon parsing, every local variable assignment cannot be
interpreted and optimized as a local variable assignment, but has to
have a check to see if there was a method with that name at _runtime_,
each and every time. Or you could do the decision only once at parsing
time, and be dependant on the order of definition of methods. (I.e. put
the writer methods below the method in question, and you're screwed.)
So I don't think giving precedence to writer methods will suffice.
--
(\[ 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___)
Kent Dahl
> no, if i were creating ruby now, i would very much consider doing that.
> certainly it adds an extra char to all local vars, but it makes things
> quite distinct.
Isn't this a step _backwards_ to "feeding compilers" instead of solving
problems?
> do you consider @, @@, and $ junk?
Dunno about George, but I consider $ junk and I am very vary of using
@@. Ironically we're arguing about writer methods inside classes, which
also distances us from the @.
So, while not quite junk, they are ugly, nececarry implementation
details that need to be hidden as soon as possible :-)
> so you think writer methods are the problem? what would they be replaced
> with?
Nothing stopping you from making traditional setter and getters. Writers
are _external_ interface syntax sugar, IMHO.
--
(\[ 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___)
Tom Sawyer
> Tom Sawyer wrote:
> So, while not quite junk, they are ugly, nececarry implementation
> details that need to be hidden as soon as possible :-)
how might you do that? as far i can tell that would involve declaring
variables. i don't know how i feel about that.
> Nothing stopping you from making traditional setter and getters. Writers
> are _external_ interface syntax sugar, IMHO.
this is true. but i like the #writter= methods. ugh, there seems to
grand solution to this.
> (\[ 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___)
>
--
~transami
Tom Sawyer
> @@. Ironically we're arguing about writer methods inside classes, which
> also distances us from the @.
>
> So, while not quite junk, they are ugly, nececarry implementation
> details that need to be hidden as soon as possible :-)
just to throw this out, i'm wondering why placement wasn't used to
determine scope, just like when you have have variables defined outside
of a block, they are available inside of it, and not local to it. here:
globalvar = 'global b/c from top level ($)'
class X
X.classvar = 'class var (@@)' # perhaps?
instancevar = 'object instance var (@)'
def x
localvar = 'local to x'
end
end
i hope no one thinks that i have been trying to push a notion i've had
about this, that's not modus operandi. truly i am just exploring to see
in what ways things might be improved whether that can reasonably happen
or not. for one day i hope to make my own language and in these
discussions i am learning much that i will be able to carry into that.
so, thank you!
--
~transami
Kent Dahl
>
> On Sat, 2002-08-10 at 05:26, Kent Dahl wrote:
> > Tom Sawyer wrote:
> > So, while not quite junk, they are ugly, nececarry implementation
> > details that need to be hidden as soon as possible :-)
>
> how might you do that? as far i can tell that would involve declaring
> variables. i don't know how i feel about that.
Uh, no, I was thinking:
We already use accessor methods to hide @ away, all the time from the
outside, and also from the inside (which this discussion is mostly
about).
Earlier there has been discussions about @@ vs instance variables of the
class objects. I'm not sure how cumbersome that would be to use though
(in subclasses, you wouldn't be able to just do type.variable=).
As for $, you use accessor methods on module (or class) objects instead,
effectively giving yourself a namespace for your global variable. I.e.:
module X
def self.x
@x
end
def self.x=(x)
@x=x
end
end
X.x = 5
puts X.x
Defining the methods are akin to declaring the variables, but it sure
beats a $ anyday :-)
--
Albert Wagner
Smalltalker?
George Ogata
> no, if i were creating ruby now, i would very much consider doing that.
> certainly it adds an extra char to all local vars, but it makes things
> quite distinct.
I think it makes things less distinct. @, @@, and $ appear quite scarcely
(compared to locals), and so they stand out. Giving locals a prefix letter
blends the whole lot into an unreadable mess.
> do you consider @, @@, and $ junk?
If they were used on every identifier, yes. If used sparingly (as in
current ruby), though, I think it can sometimes (ok, quite often) help you
follow code. I guess "that sort of junk" wasn't a fair expression to use.
> you know other languages have commands to specify the access level of
> variables. so you can't tell the difference just by looking at them. you
> code something like 'global avar' or 'public avar'.
Well, 'public' doesn't really come into it here, does it? Ruby uses
methods for that to mimic the way other languages do it.
I wasn't suggesting that we rid them all (I said "minimize", not
"eliminate"), just that they should be used only when really needed, and
when the alternatives aren't better. Prefix symbols have a side-effect of
making things stand out, and when too much stands out, it just becomes
noise.
>> I'd personally rather lose the o.member = 'something' notation for method
>> calling. As David Alan Black mentioned:
>>
>> >> Isn't it good to have to know when you're calling a method and when
>> >> you're assigning to a local variable :-)
>
> so you think writer methods are the problem? what would they be replaced
> with?
set_x methods, as is used in most traditional OO languages. They should
still be magically generated using attr_*.
I understand the motive of member=(), though. Since the interface of a
class consists only of methods, o.member = 'x' has no meaning, so why not
make that a method too? The problem is when it's used inside a class, when
you can omit the "o.", and a gotcha arises from potential ambiguity. I
wonder if simply leaving "o.member = 'x'" as illegal ruby would've been
better.
dbl...@candle.superlink.net
On Sun, 11 Aug 2002, George Ogata wrote:
> Tom Sawyer wrote:
> [George wrote:]
> >> I'd personally rather lose the o.member = 'something' notation for method
> >> calling. As David Alan Black mentioned:
> >>
> >> >> Isn't it good to have to know when you're calling a method and when
> >> >> you're assigning to a local variable :-)
I didn't mean that as an anti o.member = 'x' argument though :-) It
was in response to Tom's having listed needing to know when to write
"self." among the cons of the variable/method ambiguity. My point was
just that one already knows one is calling a method; there's no extra
knowledge involved.
> > so you think writer methods are the problem? what would they be replaced
> > with?
>
> set_x methods, as is used in most traditional OO languages. They should
> still be magically generated using attr_*.
>
> I understand the motive of member=(), though. Since the interface of a
> class consists only of methods, o.member = 'x' has no meaning, so why not
> make that a method too? The problem is when it's used inside a class, when
> you can omit the "o.", and a gotcha arises from potential ambiguity. I
> wonder if simply leaving "o.member = 'x'" as illegal ruby would've been
> better.
I would describe it in a different sequence: it's used inside a
class, you *can't* omit the 'o', you write the 'o', there's no
ambiguity :-)
I think one thing that needs to be taken into account is how little
impact this actually has on code -- in comparison to the impact there
would be, visually, if every local variable assignment looked
different, or if every "obj.thing = x" became something else.
Here are some rough statistics. The output of /tmp/lines is
the content of all *.rb files in and below ruby/lib, filtering out
"def meth..." lines and comment lines (including block comments).
Local variable assignments:
$ /tmp/lines | grep "\(^\|[[:blank:]]\)[a-z_]\w\+ *=[^=>~]" | wc
1863 7471 58965
Calls to '=' methods:
$ /tmp/lines | grep "\b\w\+\.\w\+ *=[^=>~]" | wc
195 667 6360
Subset of above, where receiver is explicit "self":
$ /tmp/lines | grep "\bself.\w\+ *=[^=>~]" |wc
34 119 1109
Of course the ratio will vary from one case to another (and I don't
guarantee the perfection of the filtering or counting :-), but this
suggests strongly to me that having to name the receiver under some
circumstances is a small price to pay for the overall cleanness of
assignment code.
Tom Sawyer
> Hi, Tom. I see a pattern to all of your expectations for Ruby. Are you a
> Smalltalker?
nope, not a SmallTalker, and i assume there's no pun intended ;-) but
perhaps not coincidently, i did recently discover Squeak.
--
~transami
Albert Wagner
Just curious. I used Smalltalk exclusively for about 15 years. The syntax is
beautiful and elegant. But I grew weary of the huge image based model.
Tom Sawyer
ambiguity between local var assignments and standard ruby setter
methods, i am taking kent's advice, and from this day forward will use
something i picked up from rich kilmer. no longer will i use #var=
setter methods!
i'm creating my own attribute module methods to replace attr_reader,
attr_writer, and attr_accessor. instead of having a seperate method for
assignment, i use the same method as the reader, but it checks to see if
there's an argument passed. if there is than it acts like a setter.
not positive about the names of these yet, but:
class Module
def Module.attr_rw(name)
name = name.to_s
class_eval <<-EOS
if not method_defined?(:#{name})
def #{name}(*args)
if args.length > 0
return @#{name} = args[0]
else
if @#{name}
return @#{name}
else
return @#{name} = nil
end
end
end
end
EOS
end
def Module.attr_ro(name)
name = name.to_s
class_eval <<-EOS
if not method_defined?(:#{name})
def #{name}
if @#{name}
return @#{name}
else
return @#{name} = nil
end
end
end
EOS
end
end
is this the right way to go about this? can anyone improve on this code?
or see any flaws that need to be fixed? i don't have a write only
version, do i really need it? i don't think i've have used one before.
given all is well i can now do:
class X
attr_rw :instancevar
def initialize
instancevar 'i am me' # set
puts instancevar # get
end
end
--
~transami
Justin Johnson
> Dunno about George, but I consider $ junk and I am very vary of using
> @@. Ironically we're arguing about writer methods inside classes, which
> also distances us from the @.
Personally, I disagree. I do a lot of C++ programming with large systems
and one of the first standards we adopted was variable name identification.
This is quite a common thing to do. For example, our C++ classes are named
similar to Ruby consts, our class data members are appended with '_' . We
use setter/getter. And so on.
class TestClass
{
public:
void var( uint32_t Var );
uint32_t var() const;
private:
uint32_t Var_;
};
You get the idea. I was surprised and quite happy to find that Ruby adopts
variable naming as standard. A good idea enforced.
> So, while not quite junk, they are ugly, nececarry implementation
> details that need to be hidden as soon as possible :-)
By hiding them you'll make large bodies of code less readable and allow
people to adopt non-standard solutions to variable naming. This is
something I know from experience.
--
Justin Johnson
Kent Dahl
> Personally, I disagree. I do a lot of C++ programming with large systems
> and one of the first standards we adopted was variable name identification.
>
> This is quite a common thing to do. For example, our C++ classes are named
> similar to Ruby consts, our class data members are appended with '_' . We
> use setter/getter. And so on.
I think you misunderstand me. Since you are using setter/getter methods,
you are hiding these details, no? I merely extend this to include
internally in the class: If you have accessor methods, prefer them to
using variables, even when inside methods of the class. If the outside
shouldn't have write access, make the writer private or protected, don't
leave it out.
In C++, there is even less fear of using methods instead of variables
directly inside classes, since the performance hit can be removed by
declaring the getter and setter inline.
I am not a proponent of tossing @ out of Ruby.
I'm a proponent of reducing its usage as much as possible in ones own
code.
Justin Johnson
> Dunno about George, but I consider $ junk and I am very vary of using
> @@. Ironically we're arguing about writer methods inside classes, which
> also distances us from the @.
Personally, I disagree. I do a lot of C++ programming with large systems
and one of the first standards we adopted was variable name identification.
This is quite a common thing to do. For example, our C++ classes are named
similar to Ruby consts, our class data members are appended with '_' . We
use setter/getter. And so on.
class TestClass
{
public:
void var( uint32_t Var );
uint32_t var() const;
private:
uint32_t Var_;
};
You get the idea. I was surprised and quite happy to find that Ruby adopts
variable naming as standard. A good idea enforced.
> So, while not quite junk, they are ugly, nececarry implementation
> details that need to be hidden as soon as possible :-)
By hiding them you'll make large bodies of code less readable and allow
Tom Sawyer
>
> By hiding them you'll make large bodies of code less readable and allow
> people to adopt non-standard solutions to variable naming. This is
> something I know from experience.
i too tend to think that it is better to have these then not, even
though i understand how they can be viewed as junky, read perly ;-)
curious to know your take on having local variables prefixed as well.
def how(%do, %you)
%feel = 'about local variables'
%with = 'prefixes'
puts "#{%do} #{%you}?"
end
:-)
--
~transami
Michael Campbell
--- Tom Sawyer <tran...@transami.net> wrote:
> well, given that there dosen't seem a reasonable solution to the
> ambiguity between local var assignments and standard ruby setter
> methods, i am taking kent's advice, and from this day forward will
> use
> something i picked up from rich kilmer. no longer will i use #var=
> setter methods!
This seems more reasonable than "this."? Wow.
=====
--
Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/
Yahoo IM: michael_s_campbell
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
dbl...@candle.superlink.net
I would recommend:
1. Don't check for method existence. Use -w, and let Ruby warn you
if you're redefining and/or discarding methods.
2. Consolidate some of the logic; I don't think you need that many
branches. (Or am I overlooking a scenario?)
3. Consider how you would do the equivalent of this:
class X
attr_reader :thing
def thing=(x)
@thing = "I am #{x}"
end
end
I can't spot a way to do it very cleanly (i.e., without either
using aliases and/or manually rewriting the method that was
automatically written.)
Here's a somewhat trimmed-down implementation (which I think behaves
the same as yours). I've added multi-argument handling.
class Module
def attr_rw(*names)
names.each do |name|
class_eval <<-EOS
def #{name}(*args)
@#{name} = args[0] if args.size > 0
@#{name}
end
EOS
end
end
def attr_ro(*names)
names.each do |name|
class_eval <<-EOS
def #{name}
@#{name}
end
EOS
end
end
end
class X
attr_rw :thing, :other
end
x = X.new
x.thing "Hello"
puts x.thing
x.other "Bye"
puts x.other
Charles Hixson
>On Fri, 2002-08-09 at 12:05, Paul Brannan wrote:
>
>
>>Why not use:
>>
>> self.localvar = x
>>
>>
>>
>
>code smell.
>
> Proc.new {
> self.i_am_a_writter_method = 'so i need my self'
> but_i_am_not('so i'm cool without it')
> self.there_could_be_a_lot_of_these = 'that's a lot of ego ;-)'
> }
>
>
>
>
To me it seems that efficiency issues can dominate here (as to which
form should be used). The argument for having a setter method be the
same as a direct reference (for externally accessible variables) seems
impecable. The caller shouldn't need to know.
Internal use, however, can be quite different. Sometimes the validation
methods can be a bit expensive (e.g.: Is value actually referred to in
the file?) Even an expensive check may be highly desireable when an
external call is being made, but internally, calls that are known to be
safe should be able to short-circuit the validation, and set the method
directly. Otherwise processing can become unbearably slow. And this is
a kind of slowness that changing languages won't fix.
--
-- Charles Hixson
Gnu software that is free,
The best is yet to be.
George Ogata
>> >> >> Isn't it good to have to know when you're calling a method and when
>> >> >> you're assigning to a local variable :-)
>
> I didn't mean that as an anti o.member = 'x' argument though :-) It
> was in response to Tom's having listed needing to know when to write
> "self." among the cons of the variable/method ambiguity. My point was
> just that one already knows one is calling a method; there's no extra
> knowledge involved.
I know I was putting it in a different context. I didn't mean to imply you
were making the same point as me. :)
>> I understand the motive of member=(), though. Since the interface of a
>> class consists only of methods, o.member = 'x' has no meaning, so why not
>> make that a method too? The problem is when it's used inside a class,
>> when
>> you can omit the "o.", and a gotcha arises from potential ambiguity. I
>> wonder if simply leaving "o.member = 'x'" as illegal ruby would've been
>> better.
>
> I would describe it in a different sequence: it's used inside a
> class, you *can't* omit the 'o', you write the 'o', there's no
> ambiguity :-)
I was considering the motive from a language design point of view. As in,
"I'm making a funky new flawless language, and I've just saved the world
from the evil of public data members. Now what've we got to build on?" Or
maybe that was never part of the design process...
> I think one thing that needs to be taken into account is how little
> impact this actually has on code -- in comparison to the impact there
> would be, visually, if every local variable assignment looked
> different, or if every "obj.thing = x" became something else.
Not sure if I get what you mean by "impact" since I was looking at it as a
retrospective curiosity, not as a proposed language change. If set_*
methods would've been the norm, I don't think I could describe it as any
"impact" whatsoever, since it's a pretty normal thing to do (looking at
other OO languages). member= methods in contrast are unexpected; an
"impact"; a protrusion on an otherwise pretty flat, consistant landscape.
(Not that that's necessarily bad; protrusion == innovation.)
Massimiliano Mirra
Consider this:
class HalfDouble
attr_reader :double, :half
def double=(val)
@double = val
@half = @double / 2
end
def half=(val)
@half = val
@double = @half / 2
end
end
hd = HalfDouble.new
hd.double = 4
p hd.half
p hd.double
Then try to replace @double= with self.double= and @half= with
self.half= and see what happens...
Maybe I'm just being naive, but even though a one uses tongue to
translate his thought for the outside world, and ears to translate
what comes from the outside world into thought, I see nothing wrong in
using just thought for internal communication.
In other words, to me, using setters from inside the class seems a lot
like talking to oneself. :-)
Massimiliano
MikkelFJ
"Justin Johnson" <jus...@mobiusent.com> wrote in message
news:3d5783ed$1...@news.teranews.com...
>
> > Dunno about George, but I consider $ junk and I am very vary of using
> > @@. Ironically we're arguing about writer methods inside classes, which
> > also distances us from the @.
>
> Personally, I disagree. I do a lot of C++ programming with large systems
> and one of the first standards we adopted was variable name
identification.
I'd like dot name ".x" instead of "@x" for referencing members.
Incidentally, this is also what the C99 standard adopted. "..x" would then
be a class reference, however, I'd prefer "type.x" or "class.x" over "@@x"
or "..x". "self.x" is an alternative to ".x".
I wouldn't have any great problem with "_x" or "x_", but I think this is
already part of the name namespace.
As usual I'm probably overlooking some blatantly obvious that prevents this
from being possible.
In C++, Microsoft world tends to use "m_x" for members, I'd personally
prefer "x_" and sometimes "_x" for private (I'm hardly consistent over all
my applications).
Mikkel
Gavin Sinclair
Tom Sawyer
>
> class Module
> def attr_rw(*names)
> names.each do |name|
> class_eval <<-EOS
> def #{name}(*args)
> @#{name} = args[0] if args.size > 0
> @#{name}
> end
> EOS
> end
> end
>
> def attr_ro(*names)
> names.each do |name|
> class_eval <<-EOS
> def #{name}
> @#{name}
> end
> EOS
> end
> end
> end
>
by the way, thanks for this david. much nicer than mine --very elegant.
when i get a chance (way too busy at the moment) i'll investigate your
comments.
~transami