Prothon Prototypes vs Python Classes

[John Roth]

"David MacQuigg" <dmq at gain.com> wrote in message
news:569c605ld1cj8fc1emolk08ete0s1prls1 at 4ax.com...
> Playing with Prothon today, I am fascinated by the idea of eliminating
> classes in Python.  I'm trying to figure out what fundamental benefit
> there is to having classes.  Is all this complexity unecessary?
>
> Here is an example of a Python class with all three types of methods
> (instance, static, and class methods).
>
> # Example from Ch.23, p.381-2 of Learning Python, 2nd ed.
>
> class Multi:
>     numInstances = 0
>     def __init__(self):
>         Multi.numInstances += 1
>     def printNumInstances():
>         print "Number of Instances:", Multi.numInstances
>     printNumInstances = staticmethod(printNumInstances)
>     def cmeth(cls, x):
>         print cls, x
>     cmeth = classmethod(cmeth)
>
> a = Multi(); b = Multi(); c = Multi()
>
> Multi.printNumInstances()
> a.printNumInstances()
>
> Multi.cmeth(5)
> b.cmeth(6)
>
>
> Here is the translation to Prothon.
>
> Multi = Object()
> with Multi:
>     .numInstances = 0
>     def .__init__():              # instance method
>         Multi.numInstances += 1
>     def .printNumInstances():     # static method
>         print "Number of Instances:", Multi.numInstances
>     def .cmeth(x):                # class method
>         print Multi, x
>
> a = Multi(); b = Multi(); c = Multi()
>
> Multi.printNumInstances()
> a.printNumInstances()
>
> Multi.cmeth(5)
> b.cmeth(6)
>
>
> Note the elimination of 'self' in these methods.  This is not just a
> syntactic shortcut (substiting '.' for 'self')  By eliminating this
> explicit passing of the self object, Prothon makes all method forms
> the same and eliminates a lot of complexity.  It's beginning to look
> like the complexity of Python classes is unecessary.

You're mixing two different issues here. The first one I'm going
to address is namespaces. I tend to agree with you, and I've
said it before; most languages would benefit a lot by putting
different kinds of identifiers in lexically distinct namespaces, and
letting the editors take up the slack. We expect modern editors to
colorize keywords, why not let them do some of the dogwork?

> My question for the Python experts is -- What user benefit are we
> missing if we eliminate classes?

Duh? Again, as far as I can tell, classes are a leftover idea from
static typing. However, you should think of a lot of the standard
OO patterns. We have, for example, classes which are never
intended to be instantiated, and classes that are, and classes that
have only one instance (singletons.) In interactive fiction (and I
suspect other application areas) having a class with more than
one instance is rare (but not unheard of.)

In more normal applications, you usually have a large number of
instances of any given class; those instances don't vary in their
behavior so it makes sense to optimize access by distinguishing
between the class and the instance. This is, in fact, what Python
does. It has syntactic support for creating instances of type "class",
complete with builtin support for methods and fancy initialization
options, and a very abbreviated syntax for the much more prevalent
operation of creating instances of type "instance."

I've seen another recent comment to the effect that eliminating
classes would remove a very valuable level of abstraction for
larger programs. The idea is superficially attractive. I'd like to see
examples of very large systems done in a prototype based language
and how they handled the problem, or if it was, indeed, a problem.

I doubt very much if I'm going to find that one extreme or the
other is "correct." It seems to differ by what you want to do
with it.

John Roth
>
> -- Dave
>