[Types-sig] Scarecrow Proposal

M.-A. Lemburg mal@lemburg.com
Tue, 24 Nov 1998 19:58:47 +0100


Jim Fulton wrote:
> 
> M.-A. Lemburg wrote:
> >
> >
> > To be honest: I just flew over it at the time and then decided it
> > was a good thing but not something that would interest me too much.
> > After a while I started to see that this could be the solution to
> > providing "static" typing in a very smart way (with interfaces being
> > used as "type" tags providing all kinds of nifty details to possible
> > optimizing engines
> 
> Perhaps someone will prove me wrong, but I expect that optimization
> engines would want certain implementation information that would
> be absent from a purely behavioral specification.
> 
> Hm.  Maybe it would be worth consider additional meta objects
> (other than interfaces) that could be attributed to classes
> or objects to give optimization hints.

Actually, I thought of doing all those things (behaviour, optimization
hints and pre-/post-conditions) with interfaces. After all, it's
intended to provide structured meta-data about objects and all of the
three types of information fit in there nicely.

> > IMHO, interfaces ought to have information query methods, not
> > "real" ones that are only given to describe which methods are
> > expected to be implemented by a class conforming to an interface.
> 
> I agree.
> 
> > I would put more emphasis on the tagging nature of interfaces
> > rather than making them look like a C++ base class.
> 
> I couldn't agree more.
> 
> > [Code sample]
> 
> I'll post me initial implementation later today.
> This should make things a little bit clearer.

Looking forward to it. These discussions are getting a little
hard to handle without proof-of-concept implementations (I believe
that Python already has all necessary features to do so).

> > But I could define an Integer interface to mean: objects conforming
> > to this interface will work fine with the builtin int() and the
> > optimizer may convert them using int() to enable better ways of
> > storing their values. (The object could also define a reverse
> > method, e.g. reinit_from_int() to reverse that trick -- all well
> > definable in an interface definition.)
> 
> Fair enough.  The interface should probably say, if it can, what the
> possible range of values is.  (e.g. can a 16-bit integer be used at the
> C level, must a python long be used, etc.)

Right.

-- 
Marc-Andre Lemburg                               Y2000: 402 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------