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

Charles Hixson <[e-mail]> writes:

> 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?

I don't think that this is what I'm saying. A class is a type. The
methods are part of that type.

I don't know, put it's possible that I'm talking about types and
you're talking about values.

> 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.

This is two separate things: information hiding (encapsulation) and
the uniform access principle. Both are good.

> So types and classes merged together again.

Were they ever separate?

> 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 we're not talking about encapsulation, we're talking about type
checking.


Regards


Dave