what is "class behavior"

I thought that since I'm forced to go back and rethink implementing classes
in Prothon, this would be a good time to revisit what classes are in
Prothon.  Exactly what behaviour is needed or is beneficial?

I will list what I can think of.  Please add anything you can think of to
this list:

1) Directed method calling.  Right now, when you call a prototype's method
and intend to use it on the current self object, you have to use a special
Prothon method-calling syntax to specify that you want the method from the
prototype but not to use that prototype as self:

    object Proto1:
            def doSomething():
                    print 'doing 1', self.x

    object Proto2(Proto1):
            def doSomething():
                    Proto1.doSomething{self}()   # special syntax
                    print 'doing 2', self.x

If we just said "Proto1.doSomething(x)" instead of
"Proto1.doSomething{self}(x)", then doSomething() would act on Proto1, not
on self, just as sort!() acts on list in "list.sort!()".

If Proto1 were somehow known to be a "class" instead of a regular "object"
then "Proto1.doSomething(x)" would unambiguously work on self as it does in
Python.

2) str_() and call() behaviour.  If a class is just a blueprint, then it
should be treated special when used with call_ and str_.  call_ should
automatically create instances and str_ should return a string that
indicates the class nature of the object.  This would free up call_ and str_
for other uses on regular objects.

3) Inheritance is all managed through classes, not instances.  Each instance
just inherits from it's one class.  That class inherits from other classes.

4) Instances cannot have methods of their own.  They can only use methods
from their class.

Note 1: Only items 1 and 2 are positive benefits.  Items 3 and 4 are
limitations.

Note 2:  Instances don't normally inherit data from their classes, but I see
no reason to not allow that in Prothon's implementation of classes.  This is
backwards compatible as it won't break any old class code.

Note 3:  I think that "class types" can be prototypes, not classes
themselves.  This is just a gut feeling that I cannot defend until case
examples are tried.  Thus metaclasses are covered by prototypes.

I feel that item 2 will be very important if we remove the general
Object.call_() for objects from Prothon.  In other words you must use
classes to implement the 2-tier paradigm.  Note that item 2 only affects the
definition and construction of objects.  The rest of Prothon code is
unchanged.  Item 1 affects other code also.