[melbourne-pug] structural subtyping

[Birch, Bill]

I'm not really into declarative interfaces for Python, duck typing works fine. 

Too many people believe that classes are "factories for creating objects" whereas they ought to be viewed as collections of objects with the same attributes. The problem I am working on is "first construct your object, then figure out which classes it belongs to." This is more in keeping with the dynamic language world view. 

Here's a code example: 

  >>> it = Shape.classify( [1,2] )

  >>> typesOf(it)
  obj:  [1, 2]
  generalized:  [<type 'int'>, <type 'int'>]
  super under:  <class 'examples.BarGraph'>
  subshape of:  <class 'examples.Cartesian'>
  subshape of:  <class 'examples.MyComplex'>
  subshape of:  <class 'examples.BarGraph'>  

Here I have created an composite object [1,2] and I have asked the system what classes it belongs to. It knows about some classes which I declared previously:

  class Number :
      __metaclass__ = Shape
      shape = Either(int, float, long) # one of either int or float

and

  from shape import *
  __metaclass__ = Shape

  class Cartesian :
      shape = (Number, Number) # two numbers

  class MyComplex :
      shape = (Number, Number) # two numbers
      def real() : 
          return self[0]
      def imaginary() : 
          return self[1]

  class BarGraph :
      shape = (Number, etc) # some  numbers
      def plot() : 
          for r in self:
              print r[0], "*"*r[1]

In the fullness of time I should also handle interface definitions as you say. For now I'm mostly focussed on compound objects made up of collections. My next challenge is get Classify() to dynamically re-write the class and superclasses of [1,2].  so that "it.plot()" work. Any hints?

Cheers,
Bill


-----Original Message-----
From: melbourne-pug-bounces at python.org
[mailto:melbourne-pug-bounces at python.org]On Behalf Of
brucedecoy-post at yahoo.com.au
Sent: Tuesday, 21 March 2006 10:48 PM
To: melbourne-pug at python.org
Subject: Re: [melbourne-pug] structural subtyping


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 

_______________________________________________
melbourne-pug mailing list
melbourne-pug at python.org
http://mail.python.org/mailman/listinfo/melbourne-pug