[ruby-talk:5798] Re: Dynamic languages, SWOT ?

Dave Thomas wrote:

> ...A type is defined by a state domain and a set of operations that
> (normally) act on that domain. The state domain determines the valid
> set of values that objects of that type may have, and the operations
> talk about how objects of the type may be manipulated.
>
> ...
> Object-oriented languages extend the paradigm. Now we can define a
> class, where we manage the state internally and export the operations
> that manipulate and use that state. Each of these classes defines a
> type.
>
> OO languages that support subclassing have the ability to create new
> types based on existing types. These new types have (at least) the
> same set of operations as their base types, but their domain is
> restricted. (Does this paragraph sound familiar? What a well-crafted
> note, eh?)
> ...

> Help me understand the other point of view.
>
> Regards
>
> Dave

So, a class is a type that implements methods?  This is the standard usage
from C++ (at least several years ago), and I was convinced by it for quite
awhile.  I suppose that it was Object Oriented Software Construction (B.
Meyers, Eiffel) that changed my mind.  He asserted that an external entity
shouldn't be able to look inside the class, and that it therefore shouldn't
be able to tell whether a result was returned by a function or a variable.
I read that several years ago, so I may have some of his details wrong, but
he convinced me that from the outside, one shouldn't be able to tell
whether or not a method had been called.  So types and classes merged
together again.

Now, of course, this is idealistic (unless you are programming in Eiffel,
where it is true by design).  But it is still what it looks like from a
distance.  When one gets really close to the class, there are likely to be
routines that "know" all about it, and for efficiency's sake, sometimes
ignore the class' cell membrane.  But this has to be done delicately, with
restraint, and with great care.  The benefit has to be quite high before it
is justifiable.  Both Python and Ruby, however, have decided that it should
be up to the programmer to use good sense about this.  So if you are
looking quite closely, there is a valid difference between a type and a
class.  But from any distance the concepts merge into something that looks
the same.  And acts the same.

<ramble>

I realize that this particular conclusion is framed in terms of a
particular mental model of the process, and I don't see any easily
generalizeable abstraction (that's at all new).  But when I think about
programs, I tend to think in terms of concrete models.  They just aren't
UML diagrams, they're more like hunks of code floating around inside a cell
membrane.  And one process can say "I require *that* piece" in order to
proceed with the synthesis of the answer.  Of course, when one actually
gets to hooking the pieces together, the syntax is much more verbal, but
the components being hooked together is "stuff that ought to be around here
somewhere".  This metaphor for programming probably can't be taken too far
(is a directory a kind of reticular membrane?), but it seems to be the one
I'm using right now.

If I easily could, I would certainly also express this in more formal
terms.  But I don't naturally think that way, so the only time it usually
comes out is when I'm repeating what someone else has said.  And then it
means that I haven't fully assimilated it.
</ramble>


-- (c) Charles Hixson
--  Addition of advertisements or hyperlinks to products specifically
prohibited