Re: Object-Oriented thinking

First . . .

I think your description of the object model and how you think of it is
excellent, and it very closely approaches the way I think about it,
though I think some of the points you make come off a bit more subtly
than they would if I tried to explain it.  Of course, I'm also having a
difficult time figuring out how to articulate my thoughts on that
clearly, which is why I haven't contributed an explanation of my own
sense of Ruby's object model to this thread.

That having been said, I'll respond directly to some stuff you said now.

On Wed, May 25, 2011 at 12:12:44PM +0900, David Masover wrote:
> On Friday, May 20, 2011 12:58:26 PM Michael Sokol wrote:
> >
> > 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 pushe=
s us
> > to believe.
>=20
> If you don't know JavaScript well, I would strongly suggest picking it up=
.=20
> Read pretty much anything Douglas Crockford has to say about it, and play=
 with=20
> different OO patterns. I'm going to use this as an analogy here, so I'll =
try=20
> to include enough background that it's understandable if you don't know a=
ny=20
> JavaScript, or if you still think JavaScript is "Java Lite".
>=20
> JavaScript objects behave like hashes, and the two can be used almost=20
> interchangeably. Methods are just functions (generally anonymous) which h=
ave=20
> been stored in the hash, and a syntax for calling them which sets 'this' =
--=20
> but you can apply almost any function to almost any object. Many=20
> implementations allow you to get a method's source easily -- playing arou=
nd=20
> with this, it seems that when you attempt to coerce a method into a strin=
g,=20
> you get the source back.

I would actually suggest that, in large part because of the compromises
made in JavaScript's implementation in the ECMA standardization process,
there is a lot of clutter in the language's design that obscures these
characteristics of JavaScript's object model in some unfortunate ways.
As an alternative to JavaScript, if the goal is solely to gain an
understanding of this prototype-based object model philosophy, one might
be better served to learn Io.  I think that in the end JavaScript is a
much more *useful* language, and there are in fact some implementation
details of Io that I find a bit perversely cumbersome, but as a way to
rapidly pick up the feel and implications of a prototype-based object
model nothing comes to mind that comes anywhere near the efficacy of Io
as an example language.


>=20
> Your choices for inheritance are either to use JavaScript's own prototypa=
l=20
> inheritance, or to write your own inheritance -- and your only choice for=
=20
> multiple inheritance is to roll your own. With prototypal inheritance, an=
y=20
> time you try to access a property (either an instance variable or a metho=
d) of=20
> a given object, it checks that object first, then its prototype object, t=
hen=20
> the prototype's prototype, and so on, arbitrarily deep.
>=20
> Rolling your own is much more flexible -- you just create a new, empty ob=
ject=20
> (as easy as {}) and start adding methods to it. Basic inheritance would j=
ust=20
> mean calling some "constructor" method which returns an object, then modi=
fying=20
> it in the child "constructor" method.

Here is one case where I think Io serves better than JavaScript.  A lot
of what goes on in JavaScript -- especially where "best practices" and
common cultural idioms are concerned -- is pretty heavily polluted by
more "traditional" C++ish and Java-like object models' concepts of class
hierarchies and the like than Io's approach.  Ultimately, I find that it
is much more obvious how to do protype-based OOP "correctly" in Io than
in JavaScript as a result of that, and of other factors as well.

So, to summarize . . . I think that Io is a better choice for the limited
purpose of learning about these things.  I think JavaScript is a better
choice for learning a useful language, though.

Some Io programmer may well take exception to my statements, and if so, I
invite explanations why I'm mistaken.  I'd really like to find out why
(if it is true) Io is as useful a language as JavaScript for "real world"
problem solving when it seems to me like it kinda isn't (and not just
because of lacking libraries, tools, et cetera, but also because of some
characteristics of its design).

--=20
Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]