[Types-sig] Issue: definition of "type"

[Greg Stein]

On Mon, 20 Dec 1999, Paul Prescod wrote:
> Tim Peters wrote:
> > > spam is a class but not a static type.
> > 
> > True, but it can be given a static type *name*; e.g.,
> > 
> >     decl type spam
> > 
> > Provided that the attributes of spam actually referenced outside of spam
> > have the same signatures, static type checking outside of spam shouldn't
> > care that it doesn't know about spam's internals.  Or, IOW, if the two
> > dynamic versions of spam present the same external interface to the
> > compiler, it doesn't matter how the *class* spam comes into being at
> > runtime.
> 
> Okay, but do you or do you not agree that in the simple case of:
> 
> class spam:
> 	def a(self) -> String:
> 		return "abc"
> 
> a type object should be made implicitly as if someone had actually typed
> in the decl. I certainly would not support a position that said that the
> entire signature of spam had to be re-declared. I MIGHT support a
> position that said that the user had to explicitly declare spam as being
> available to the static type system.

I believe that a typedecl object would be created implicitly with the
above class definition. Even if the ->String wasn't present. Every class
definition implies an interface typedecl.

I concur: having to redeclare would suck.

Explicit declaration is unneeded -- why should a person have to declare
that the implicit type is usable? It is there, so it can be used.

> I'm on the fence about this last requirement because I would like to
> think that all of the code out there with class statements is *already*
> defining a bunch of types. A minority of it depends on runtime
> information and we can easily detect those cases. So why not let the
> simple case of "defined class that doesn't depend on runtime
> information" be a shortcut for a type declaration?

Absolutely.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/