On 20 May 2011, at 18:58, Michael Sokol wrote:
> Hello everyone,
>=20
> What I find fascinating when hacking in Ruby, is that we use one of =
the
> purest implementation of OOP, and at time we find ourselves tweaking C
> extensions. Thus, the boundary between the two ways of thinking =
(procedural
> vs OOP) seem very thin, yet it's still fundamentally different.
>=20
> My question is, what kind of mental model do you use when you program =
in
> Ruby? How do you think about objects? Do you see them as elements =
carrying
> with them their own methods, bundled with their data?

Mostly I tend to think about programming as a sort of a collaborative =
writing exercise between myself and the computer as we explore a =
particular problem space. Along the way we'll spot some interesting =
landmarks, chat with the natives about their lifestyle and customs, get =
stuck in some weird backwater or three along the way and when we get =
back have a really great yarn to tell.

Out of that experience we (I and Friend Computer) seem to produce this =
artefact called a software program with objects and classes and =
meta-programming adornments.=20

And at times we write tests. Which is a polite way of saying we perform =
unethical vivisection on various of the natives we meet, take snapshots =
for the further edification of science, and then run away from the scene =
of the crime very very quickly.

> How about the flow of the program: Whenever there's a method call, do =
you
> picture the method to be inside the receiver - just like it would be =
in a
> real-life object -, or since you know that in the underlying =
implementation
> the method is stored in the class, you just think about a procedure =
call
> with a self variable being the receiver?

It's all just messages, all the way down. Often in a Schroedinger's =
Cat/Shakespearean tragi-comic sense.

> Do you think using the OOP abstraction without knowing the internals =
can be
> harmful? My case for that (even if I tend not to believe so) would be =
that
> someone might be tempted to think that during an object instanciation, =
all
> the instance variables AND methods gets duplicated for this particular
> instance, which isn't the case - yet, that's what the abstraction =
pushes us
> to believe.

Anything with quantum mechanics can catch us out if we fall for the =
fallacy of determinism. Message passing languages such as Ruby are an =
example of this and an object is only ever what it claims to be when =
asked.

Just because a Ruby object is a Dog, doesn't mean it can necessarily =
bark ;)


Ellie

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason