Re: Re: Re[2]: Re: class proposal

Lenard Lindstrom wrote:

>> Can you show me a metaclass example that Prothon cannot handle?  I
>> would like to understand this situation better.
>>
> Metaclassing let me make Python's class statement create prototype
> object instances. In Python the class statement is simply a
> specialized
> function call. The inheritance section and class body are evaluated to
> provide the arguments. By default object 'type' is called to return a
> new object. Metaclassing is simply a way to change the function
> called.
> This permits new kinds of class systems to be added to Python without
> changes to the language. But in Prothon one only has prototypes. And
> the
> object statement can only return new prototype instances. In Python if
> you do not like existing object behaviour you are free to implement
> your own object types and have language support for them.

You have explained how Python metaclasses work.  I was asking for something
metaclasses can do that Prothon cannot do.

Serge gave me a reference to some metaclass examples.  I am in the process
of trying to understand them and see how Prothon would deal with them.
Serge himself says that metaclasses are only decorators, whatever that
means.

>> 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.
>>
> They let Python C extension modules customize an object in attribute
> lookup
> and memory management. One could add new object types to Python by
> writing
> a module.

Ah, I understand now.  I don't really care for that feature.  Has anyone
made good use of the capability?

>> 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.
>>
> Prototypes are supposed to be revolutionary. Adding classes to keep
> large companies happy is being conventional. If classes are truly
> necessary then
> they should be in the language. But if present they will be used. And
> Prothon will be precieved as another object-oriented language, even
> if this is not true. Given the number of well established OO
> languages already in existance will
> a newcomer be given serious consideration?

I can't pretend prototypes are something they aren't.  I have learned a lot
about prototypes, classes, and Python and the main thing I've learned is how
little difference there is.  All I can do is make Prothon the best language
possible and see what happens.

> A language that diverges from Python will remain compatibible in
> those areas where change is not required. Prothon was advertised as
> Python with prototypes. It has delivered on the prototypes; it is not
> Python.

I have openly said that it was not Python compatible from the beginning.

> Even simple Python programs require modification to run under
> Prothon. And it will be difficult and time consuming to make any
> Prothon feature consistent with Python. I keep stumbling onto new
> differences every time I try Prothon. Many error reports will have
> to be submitted to clear them all up.
>
> My question is just who is Prothon targetted towards? I think many
> Python users, expecting Prothon to be just an enhanced Python, will
> be put off by its incompatiblity. Prothon is different enough from
> Python to discourage the porting of existing Python applications.
> Only in those areas where Prothon has a definite advantage will it
> make sense. I am not convinced that prototypes give any clear
> advantage in most cases.

There are enough new applications started every year to make Prothon
successful.  Porting from Python is not a requirement.  Having said that,
making Prothon as close to Python as possible to make it easy to write
Prothon when you already know Python is a good goal.

> I see Prothon's strengths being native thread support and builtin
> i18n. So Prothon should be designed for those applications where
> these features are important. Maybe compatiblity with Python should
> not be a consideration at
> all?

It never was.  I've always said that Prothon would never be compatible with
Python.