Re: Re[2]: Re: class proposal

"Mark Hahn" <[email protected]>
Newsgroups gmane.comp.lang.prothon.user
Message-ID <[email protected]>
Lenard Lindstrom wrote:

> Prothon prototypes do  not give one a simpler alternative
> to metaclasses as
> claimed. It simply does not allow it, period.

Why haven't you told me this before?  :-(

Can you show me a metaclass example that Prothon cannot handle?  I would
like to understand this situation better.

> I fear that Prothon is simply becoming an extended Stackless Python
> without the latters flexible C-Python api. I am still wondering what
> advantage Prothon's distinctive interpreter design has over Stackless
> Python.

The more I learn about Python's interpreter the more I learn there isn't
much difference.  You seem to think there is a big difference in this "type"
business but I'm not convinced.  I suspect it is just a vestige left over
from the old Python design.

> Prothon has no reference counting to simplify life for C
> module designers. But tools like SWIG and Pyrex effective hide
> C-Python reference counting. And as a language Prothon
> lies somewhere between Pyrex and Ruby in compatiblity with Python. At
> the C api level there is little simularity. So in effect all modules
> added to Prothon will be written from scratch - no automatic
> translation from Python.

This is a function of having no backwards compatibility.  Saying that we
would have automatic translation would have been a form of backwards
compatibility and limited our design choices.  Believe me, being forced to
have C object compatibility would have ruined our object design.  Prothon's
objects are the key to it's power.

> Given that Prothon is becoming more
> convensional with time is the extra effort worth it?

What made you expect an unconventional language?  There is nothing in the
Prothon prime directive about conventionality.  There are only things about
it being a great language.

> If one starts
> with Stackless Python and throws out the backwards compatibility
> requirement what kind of language would result? Would Prothon still
> have its advantages?

Once you throw out backwards compatibility you end up with Prothon by
definition.  You end up with a language that can be whatever it wants to be
based on what the designers feel is important.  Given the same set of
designers (us) you will end up with the same language.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.