Re: Semantics and STL/DTL

From: Cristiano Sadun (cristianoTAKEsadun_at_THIShotmailOUT.com)
Date: 07/15/04 

Date: 15 Jul 2004 11:29:09 GMT

Denis Johnson <allobjects@optusnet.com.au.nospam> wrote in
news:40f5086d$0$25460$afc38c87@news.optusnet.com.au:

>> But what of other methods/functions? What the overall system?
>
> No. I'm only interested to ensure a given object passed into my local
> scope conforms to the minimal interface used within my local scope. An
> example of what I'm referring to as "my local scope" may be a print
> queue class which only ever calls #print on the elements. Are you
> suggesting that my print queue mandates that all elements conform to a
> complete Invoice protocol (lets say) because the elements may be used
> in some other context which requires full blown Invoice instances ? or
> did I miss you meaning.

Good question. The answer is twofold: one, if the behaviour is
characterized and found generally enough to warrant it, I don't see any
problem in defining a Printable interface and have your objects
implementing it. After all, they *have* to have a print method, so the
formal declaration adds little effort.

Note that at modeling leve I associate interfaces with roles - roles that
any object may decide to assume in the system. So I'd never write a
method in terms of Invoice (a concrete class) if I can do it in terms of
a role (Printable).

The only issue here is retrofitting. We can discuss that aside if
required.

Two, if really is a one-shot, you use the reflective properties of the
language, which enable you to locate and invoke a method indipendentely
from its type altogether: so long it has it, you can invoke it.

> I understand your point, but if all my local scope only ever calls is
> #pop
> then why should my local scope enforce the full Stack interface
> to be implemented on any object being passed. Again is it the
> responsibility of my local scope/context to care or know how the
> passed object is used elsewhere ?

This is not an issue with static type check per se. Your local scope
(i.e. the type of the parameter) should not require the full stack
interface if you don't decide it do so. If all you expect is to have a
pop operation, all you would need is an operator (say, []) that allows
you to cast an object to an interface, with a cast failing or not (at
runtime) in dependence to the presence or not of the interface methods in
the object.

Say "interface Poppable { public Object pop(); }" and you write
"void myMethod(Poppable p) {...}", invoking the method with

Stack s = ...;
myMethod([Poppable]s);

This way, you're still doing static type checks and runtime evaluations
(on the method signatures instead of the runtime types set).

You'd still have to *declare* the Poppable interface, which is the point
of static typing: to tell explicitly to the compiler all you have in mind
so it can better check that what you ended up doing *is* what you told it
you wanted to do. Errors, after all, are stuff that we do without willing
to do.

Finally, the fact that in most libraries Stack is not an extension of
"Poppable, Pushable, Peekable" :) (and that the concept of stack as an
algebraic structure has evolved at all), and the fact that such an
operator is not present in lots of languages show either the poor insight
of library and language creators (and mathematicians :) or the fact that
it's unlikely that in any non-artificious context you'll have a situation
where you need only to pop(). "Stack" (both concept and interface) is the
miminal distillation etc.. If "Poppable" were as generally useful, you'd
have it around in first place.

> I propose that better OO practice is
> to minimize how much my local scope knows about the object being
> passed. The less objects know about each other the better. This
> results in looser coupling.

Looser coupling is always a force in tension with others. If you can
reduce it without consequences, obviously you do it. But reducing it by
doing *all* the checks at runtime might indeed have consequences.

Relevant Pages

  • Re: Semantics and STL/DTL
    ... > scope conforms to the minimal interface used within my local scope. ... > then why should my local scope enforce the full Stack interface ...
    (comp.programming)
  • Re: 6SN7 Mu Follower Distortion Paper
    ... the device I have bought is an HP 3581A Wave Meter - it is in effect a spectrum analyser but not with a PC interface for capturing nice pictures. ... You can connect it to a scope but as its scan rate is of the order of seconds you wont see much on a scope unless it is a storage type and mine isn't - it will interface directly to a pen plotter though!!!! ... It is a start and the spectral shape of the harmonics is the second step. ...
    (rec.audio.tubes)
  • Re: 6SN7 Mu Follower Distortion Paper
    ... the device I have bought is an HP 3581A Wave Meter - it is in effect a spectrum analyser but not with a PC interface for capturing nice pictures. ... You can connect it to a scope but as its scan rate is of the order of seconds you wont see much on a scope unless it is a storage type and mine isn't - it will interface directly to a pen plotter though!!!! ... Could not get either one of them to work properly - probably something to do with the sound chip but it is a new laptop. ...
    (rec.audio.tubes)
  • Re: 6SN7 Mu Follower Distortion Paper
    ... Ian. ... the device I have bought is an HP 3581A Wave Meter - it is in effect a spectrum analyser but not with a PC interface for capturing nice pictures. ... You can connect it to a scope but as its scan rate is of the order of seconds you wont see much on a scope unless it is a storage type and mine isn't - it will interface directly to a pen plotter though!!!! ...
    (rec.audio.tubes)
  • Re: Unexpected multicast IPv4 socket behavior
    ... Default route set, src INADDR_ANY: ... src bindto interface address: ... There's no way for the stack to know which interface to originate the traffic from in the case where there is no default route, and no IP layer source information elsewhere in the stack. ... the use of multicast requires that you create a socket and bind to the interface where you wish to send and receive the channel. ...
    (freebsd-net)