Re: two-tier proposals

Mark Hahn wrote:
>...
> 
> I also made a small proposal in passing that is less than a class where each
> method in a prototype is flagged to indicate whether the method should
> respond to calls from only instances (extensions) of the prototype, the
> prototype itself, or both.  This would allow methods like str_ and call_ to
> behave differently for the prototype and the instances, giving much of the
> behavior that classes have in Python.

This proposal deserves more thought...does it mean that prototypes would 
have two different attribute dictionaries? One for 
prototype-as-prototype and another for instances?

Which namespace owns the init_ method?

How do I introspect the two versions of the (e.g.) str_ function for 
instance to overwrite them or something?

Another way to handle this is:

#!/usr/local/bin/prothon

object a:
~  def str_():
~     #print Object.str_{self}()
~     if self is a:
~        return "<prototype A>"
~     else:
~        return  "<instance of A>"

print a
print a()

The interesting bit is that Prothon makes it easy for you to control how 
the prototype/class stringifies and Python makes it hard. But then how 
often do you care how the prototype/class stringifies? As long as the 
default is reasonable, you usually don't care.

  Paul Prescod