Hi Robert,
On 22/12/11 21:11, Robert K. wrote:
selectively rename all of the calls you have made to point to the correct
could be subject to such changes later in its lifetime. If you could tell
In my case, I ended up solving it by adding an “abar” method that just
Then you do not need to do
than #my_class.
I like that. I hadn’t thought of it myself- it’s one of those “of
course, it’s so obvious!” type things, which leaves you wondering why
you didn’t think of it yourself. 
I have to admit a guilty pleasure of mine is adding the occasional
method to “Object” in Ruby, and I could see myself adding such a thing
to “Object”. But I shall have to keep such impure thoughts away from the
list.
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.
There are definitely cases where the additional information (ie. that it
is not being performed on the local instance) is vitally important. I am
just saying that there are also cases where it is not. It is important
to emphasise that I’m not saying only one case exists or one is more
important than the other. Anyway, the question becomes: Whose
responsibility is it to ensure that in these cases that it is properly
emphasised? Is it the responsibility of the language to ensure these
cases are always handled correctly by enforcing it through the language,
or should the language step back, and leave it to the user to write
either good or bad code?
I suspect that when designing a language you would come up across a lot
of these sorts of choices. C++ requires impressive template gymnastics
to pass a single generic parameter- type safety through fear of daunting
pain. Python makes whitespace syntactically significant; pretty code
whether you like it or not. C++ uses operator overloading for ease of
expression, Java disallows it to avoid difficult to follow code. A good
case could be made to either allow, or forbid, the exact same feature in
this case. I think the problem we are talking about is that kind of
thing.
I guess that personally I err on the side of giving the user the means
to shoot themselves in the foot, if they really want to, provided that
you don’t set things up so that they can accidentally do it. Perhaps in
this case it would be something like this:
class Foo
def self.bar *args
whatever *args
end
attr_class_method_from_instance :bar
def baz
one
bar 2,4
two
bar 6 if three
four
bar 7
end
Working on the assumption for now that allowing class methods to be
called implicitly from an instance is bad (it’s probably easiest just to
assume this for now), then we only allow a user to go for the foot shot
(calling a class method for an instance) if they’ve explicitly requested
it.
I would hate to be forced to, for example, write:
def baz
one
self.class.bar 2,4
two
self.class.bar 6 if three
four
self.class.bar 7
end
Because it draws attention toward the instance versus class method
distinction, which simply may not be the most important thing in this
context.
(Of course, the “self.class.bar” call could be wrapped in an “abar”
wrapper, which might help to make it more understandable, or use the
my_class shortcut you suggested above)
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.
I think this touches on the safety aspect I mentioned above. I think we
would agree that powerful but dangerous techniques should require
deliberate actions to trigger, to avoid them being used inadvertently.
We might differ on some of the details but I think we have similar
motivations here.
IMHO.
Personally, I’d adjust that to say that everything that causes the
behaviour to become clearer is good to include, but I would exclude
unnecessary detail that does not add to the understanding, and
especially leave out unnecessary verbiage that draws attention away
from what is most important in that context. I would say that sometimes
being explicit is beneficial, but sometimes it is not, and sometimes it
has the opposite effect. Again, all IMHO. 
There are no technical obstacles here defining instance methods which
access class state.
Ah, sorry, I did not explain properly. I mean, if there are any
technical reasons for which a class method of a certain name (say,
“bar”) could not be easily triggered when an instance method of the same
name (eg. “bar”) is invoked. Perhaps, for example, it isn’t easy to
ensure without complicating calls or adding some sort of instance method
proxy, which might not be desirable? I’m basically just saying that
there might be a tech blocker here that I’m unaware of which could
actually be the main reason behind the behaviour.
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.
I would say that if you get the wrong person writing the code, no
framework of restrictions can prevent them from writing terrible code.
Such people always find a way, somehow. The right developer instead
could emphasise such a thing, if it is important in the context. And
anyway, I would argue, why hold back the better developers for the sake
of the ones that cannot write easy-to-understand code?
Anyway, these are just a few more rambling evening thoughts from someone
who should probably be getting a bit of sleep soon. I hope they are
useful, even if it’s nothing more than just a different perspective on
the problem.
Garth