class proposal 3.1

My thinking on this is starting to converge (I hope) so I'm making my
proposal numbers converge also.  I hope to converge on the number PI.

If you buy off on my proposal for call_ and str_ then the class proposal is
left with nothing but the contract provisions that I spelled out in my class
proposal 3.  When I finished with the call_/str_ proposal and the amendment
on the factory keyword, I realized that it looked very much like the class
proposal 3.  You could substitue the factory keyword for the "class =
Class.Factory(Klass)" and have the identical syntax.  So why have the class
proposal in a seperate module?

I am now going to change class proposal 3 from an imported module to a
language keyword, but keep it only as a contract that does not affect
intrerpreter behaviour (I hope), just as class proposal 3 didn't.  This way
the syntax can be integrated logically.

I will take the syntax from the amended call_/str_ proposal and add the
class keyword.  Note that this is the same as class proposal 2, except that
I am seperating the call_/str_ namespace solution from the class/contract
solution and I am giving up on being able to do the Python method calling
(see below).

    # prototype version
    object Proto:
            def str_():
                    print 'extension'
            def call_():
                    "special call for instances"
                    blah blah blah
            factory:
                    def str_():
                            print 'proto'

    # class version
    class Klass:      # object changed to class
            def str_():
                    print 'extension'
            def call_():
                    "special call for instances"
                    blah blah blah
            factory:
                    def str_():
                            print 'class'

This innocuous one-word change invokes all the 5 items in class proposal 3
with one exception.  According to Greg if we have the dual namespaces we
probably won't be able to use the normal Python directed method calls
mentioned in item 1.  I think this will be no problem.  Prothon already has
a solution for this in it's new flexible method calling syntax.  We also
have the super method calls which are even simpler than Python's.

1) The class is a blueprint only.  It cannot function as an instance. (I
removed the method call fix from this item).

2) The class is immutable.  Once defined it cannot have class or instance
methods added, removed, or redefined.  Class variables cannot be added or
removed but their values may change.

3) Instances may have only data attributes.  No instance methods are
allowed.

4) Instances only inherit from their one class.  All inheritance is through
their class which inherits only from other classes.

5) Class and instances will have seperate namespaces due to the call_/str_
proposal fix that works for prototypes and classes.

I feel that my call_/str_ proposal and this class proposal are now a
complete package.  They fulfill everything we have been able to come up with
as needs for classes in our postings.  They have done this in an orthogonal
way that does not disturb prototype's performance or flexibility.

I would use the factory keyword in the standard library but not the class
keyword.  The class keyword is for applications and project environments
that need structured contract control over programmers.