> Experiment with all you want to. But it must be an object.
> 
> Interfaces can be interesting if they can be defined/refined dynamically.
> Consider the diferences between development in a language and in an environment. If you use only a language (not an evolutive environment) you MUST have a mechanism to detect potential errors during > Java and C++ must have interfaces because they have
 types, are static (no real meta-programming during runtime), and programmers are pasive most of the time (no interaction with real objects).
> In evolutive systems (like Smalltalk) interfaces can be a waste of time. :-)
> 
> Do you know the time you invert in interfaces (defining, mantaining) ?
NO

> Are they usefull for you?... or for your compiler. :-|
> Are they for people or only for the compiler (or the component technology)?

Not direcly, but they are not that different from the categories we 
already have. 

> I think, that interfaces can be interesting if they are "normal" objects and have all the properties of anObject (dynamic, meta-programable, changeable during runtime, etc.).
> All the things that are not present in Java nor COM. :-)
> 
> Components are not the same as objects.
> The diference is not the size, the information hiddin, etc...
> The diference is that components are most of the time static pluggable parts.
> When created they MUST:
> 1.- conforms its interface (to be pluggable).
> 2.- do it's work (components are task oriented entities)
> in this order. And they are created to do a piece of work.

That's what I like about components. They harbor all they things they 
are used for, including the GUI, in one thing.
 
> But objects...
> Objects are more natural things. They are imperfect, they evolve, mutates.
> Objects are things that has been born to change.
> When created they MUST:
> 1.- provide a medium to learn.
> 2.- be. (and all that it means)
> 3.- live. (do all the work it want to in the current medium)
> 4.- evolve.
> 
> Interfaces are a power mechanism to components.
Exactly.

I agree that objects can be more powerful, but I think a class 
hierarchy alone could not offer the ease of use needed for rapidly 
building apps.

I'm thinking more along the lines of Morphs encapsulated with all  
the code they need. Make them distributable and you have something 
magnificent.

You could even transfrom a Bookmorph into a real compound document 
that could travel over the net.
Say something?!

Matthijs van Kempen