Re: Accessing class instance variables from an instance?

On Thu, Dec 22, 2011 at 2:09 AM, Garthy D
<[e-mail]> wrote:
> I've run into this kind of thing before, and it does impact me regularly.
> Having said that, I know my C++ background (which allows this) biases me
> somewhat on the issue. ;)
>
> I tend to steer away from "Foo.bar" style calls inside class Foo for the
> following reason- it complicates refactoring. If you determine that a class
> would benefit from being split (perhaps because another class has common
> functionality and you want it to share a common base), then you have to
> selectively rename all of the calls you have made to point to the correct
> class. Sure, it's not hard, and doesn't take too long, but when you're
> refactoring something for the sake of something else you have developed, not
> having to deal with additional chores to make it work makes it less likely
> that you'll stuff something up in the process. A similar problem arises with
> renaming the class, but admittedly the solution tends to be far easier.
>
> For that reason, I'd instead use "class.bar" calls, if it were possible,
> which it is not, which brings us to "self.class.bar". I do this as you can't
> always tell ahead of time when you'll need to refactor something to pull out
> a base class, and so I'll assume that (almost) all of the classes I work on
> could be subject to such changes later in its lifetime. If you could tell
> beforehand, you would have designed it that way in the first place. :) Now,
> if you have a class method that is used both inside and out, but mostly
> inside (and regularly), it's a pain to have to write "self.class.bar" each
> time you want to call "bar". Incidentally, for "bar", I have a specific
> method in mind for something I have been working on (ie. a real-world
> problem), that makes the most sense as a class method, since it works
> entirely off the arguments and carries no state. The call in question has
> very specific structured input requirements, and is called extremely
> frequently inside the class, and occasionally outside.
>
> In my case, I ended up solving it by adding an "abar" method that just
> called "self.class.bar", although using it that way does feel a bit silly,
> and makes the code less readable (an observer might ask what the difference
> between "bar" and "abar" is, for example).

A better alternative would be to do this:

class Object
  def my_class; self.class end
end

Then you do not need to do

Foo.bar
self.class.bar

but instead you can do

my_class.bar

which seems a lot clearer to me while avoiding the nasty "self.class".
 Maybe someone else can think of a better (presumably: shorter) name
than #my_class.

> Anyway, I just thought I'd share my particular experience. It's not hard to
> work around, but there are definitely good reasons to want to make it work
> that way. It falls under the area of a "quirk" for me, but that is of course
> just my personal experience based on my personal experience.

I guess my main point is that making a method call appear to be on the
local instance which in fact is done on another instance is
misleading.  For the reader it is better to at least signal that #foo
is not invoked on self but rather on another instance.  For that you
need a method or a variable reference.

>> That has the added advantage that
>> you make the call explicit in instance methods which use it and it is
>> immediately clear that this method does not manipulate instance state.
>
> There are definitely cases where this could be advantageous, but there are
> also cases where this is not necessary or desirable. In general, I would
> personally say that if a particular mechanism is sometimes beneficial, but
> sometimes not, it is better to leave it up to the person writing the code to
> emphasise the mechanism where it is appropriate, and de-emphasise where it
> is not. For example, sometimes it is beneficial to be specific about the
> particular class of an object (or its capabilities), but would that justify
> requiring every method call to be prefixed by the class name, every time? I
> would say not. There are times where being specific about it would be
> beneficial, but in the remaining cases it would clutter up the code
> unnecessarily.

We differ in the estimation about the distribution of useful and
harmful.  I'd say obfuscating a method is invoked on another instance
does more harm than good so the default should be to not make it too
easy.  This forces people to know what they are doing when they do it.
 As an example: you can modify instance variables of another instance
but it is deliberately made clumsy (#set_instance_variable etc.)
although possible.

> I think in the situation I outlined above, and possibly also in Josh's case,
> it falls in the realm of clutter. This does not, of course, take away from
> the fact that in some situations it would be important, or absolutely
> essential, to explicitly convey that the instance state will not be
> manipulated. I know that I have certainly run into this case as well- I
> won't bother with a personal anecdote as I suspect you also already know of
> many cases where it is extremely beneficial already. :)

That's the point: OO is mostly about the state of instances and its
changes.  Everything that helps keep clear what's happening is good
IMHO.

> I guess what I am saying is that if something is sometimes beneficial, and
> sometimes detrimental, that enforcing it is not always the best idea, but
> providing an optional means to make it explicit is beneficial. I do not
> believe that is a good idea in general to either force a mechanism that is
> only sometimes useful, or argue that as the mechanism is sometimes
> important, that having a means to conveniently avoid the mechanism when it
> is detrimental is not justified. There are of course always all sorts of
> tradeoffs when designing a language- perhaps the particular feature Josh and
> I would find beneficial is not readily possible for some technical reason.

There are no technical obstacles here defining instance methods which
access class state.  I just happen to believe that the tradeoff fall
on the side that we do not want to have such a feature because the
convenience of the writer is the pain of the reader of the code.

> All IMHO.

+1

> PS. Wow, that message was a bit longer than I had planned. ;)

:-)

Kind regards

robert


-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/