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.