[melbourne-pug] structural subtyping

[brucedecoy-post at yahoo.com.au]

Bill wrote:
>
> Hi,
> 
> You asked:
>  What do you mean by "structural subtyping"?
> 
> In short if an object looks like another object it's
> a structural subtype. Given a type T which consists
> of things with four legs, then dogs and tables are
> subtypes of T because they have four legs. So if I
> can see the internal structure of an object I can
> subtype this way. 

Interesting. Are you wanting something like Java
interfaces, but without the need to explicitly
implement the interface? Guido blogged about adding an
interface concept to Python recently (around the start
of the year?) and raised a bit of a storm.

Python's "duck typing" gives you all the flexibility
you need, so I'm guessing you're wanting to make some
guarantees about the types of objects that are passed
to a function. Is that right?

IMO, system tests and unit tests nicely balance the
flexibility of dynamic typing, no const, unchecked
exceptions etc... I would possibly use an interface
type occasionally if there was one, but that would
typically be when I was writing a published API.

Regards,
Bruce

> For OO-encaspulated languages the subtyping is
> limited to the public methods. Given a type C which
> consists of things which respond to the command
> 'draw', both an Artist and a Cowboy are subtyes of
> C. Note the semantic dissonance ;-)  
>      
> I'm playing with the first kind, ie subtyping of
> composite, un-named, un-encapsulated objects (which
> may have been read in as input). 
> 
> The wikipedia definition
> http://en.wikipedia.org/wiki/Structural_subtyping is
> here.  
> 
> Cheers,
> Bill
> 
> 


	

	
		
____________________________________________________ 
On Yahoo!7 
Messenger - Make free PC-to-PC calls to your friends overseas. 
http://au.messenger.yahoo.com