Peter:

You stated:

>How can you make a safe design if there is no guarantee that objects
>implementing the interfaces can actually communicate with each other?

I can appreciate what you are saying yet this notion of safety is still
from a practical perspective to me quite confusing.
I have been delivering ST apps for quite a while now and I can't think of
one situation where I could not live with being not as safe as I quess
things could be.

When does "safety" become a "practical" problem. Perhaps more in certain
domains?

My problem with this entire issue is that all of this leads most usually
with people concluding that we need typing in Smalltalk and I personally
don't want to deal with it.  I have also heard some people argue that one
can't use ST in this or that because it is not safe. I'm not sure if I can
agree with this.




At 05:40 PM 7/19/99 +0930, Peter Smet wrote:
>Charles,
>
>Maybe I am looking at interfaces from the wrong angle. I see an Interface as
>a kind of contract. If an Object implements an interface, you can make lots
>of otherwise dangerous assumptions about what messages it understands.
>Similar to IDL or Types (I know, that word makes Smalltalkers cringe). If
>Distributed Objects are to be the next big thing, how will you talk to them?
>Discovering an Interface is a good way. As I have explained, the current
>Interfaces are 'leaky' in that an Object can have Interface A, you can send
>it an Interface A message, but the object will not understand it. I gave an
>example of this in my previous post -
>
>>>To truly reason
>>>about Interfaces it is not enough to treat them as a bunch of selectors.
>To
>>>me, the function of an Interface is as a prerequisite for communcation
>>>between objects. In its present form, objects with compatible interfaces
>may
>>>NOT be able to communicate.
>>>
>>>For example, the interfaces
>>>1: do: [^1]
>>>2: do: [: aNumber | ^aNumber printString]
>>>
>>>Are incompatible and most definitely not interchangeable. However, they
>are declared to be compatible with the present Interfaces approach.
>
>
>>Would you mind explaining what the real practical benefits of incorporating
>>something as you suggest into
>>Smalltalk ?
>
>
>Well, I am assuming that when you say an object implements an Interface,
>that I can send it any message in that interface. Is this assumption flawed?
>You will not be able to build very complex stuff without this foundation in
>place. With the present Interfaces, this assumption does not work.
>
>>Will not the addition of complexity outweigh the benefits in this case?
>
>
>To be honest, I havent played around with Interfaces to determine how
>difficult this is. Once the primitive classes have well-defined interfaces
>it may not be as bad as it looks.
>
>>Being aware of "interfaces" from a design perspective is important of
>>course but I'm still not sold on the usefulness of enforcing them as an
>>actual language construct.
>
>
>How can you make a safe design if there is no guarantee that objects
>implementing the interfaces can actually communicate with each other?
>
>>SmallInterfaces as currently implemented provide a certain utility. To take
>>this further as you suggest would over constrain things from my
>perspective.
>
>
>I think Interfaces could be hugely useful in interfacing to the outside
>world. This includes compiling to C, C++, Objective C and back, implementing
>IDL, communication objects across the net, etc. However, you may find that
>you are getting 80% of the functionality with 20% of the complexity, which
>seems like a reasonable tradeoff.
>
>Peter
>