Prothon Prototypes vs Python Classes

[David MacQuigg]

On Sun, 28 Mar 2004 11:15:34 -0500, "John Roth"
<newsgroups at jhrothjr.com> wrote:

>
>"Paul Prescod" <paul at prescod.net> wrote in message
>news:mailman.10.1080485351.20120.python-list at python.org...
>> John Roth wrote:
>>
>> > It's certainly true that in a prototype based language all objects
>> > exist: there are no objects that the compiler deals with but does
>> > not put into the resulting program. And it's quite true that it does
>> > open up the floodgates for a lot of messiness.
>>
>> Ummm. This is also true for Python. Python classes exist at runtime.
>>
>> foo = 5
>>
>> class foo: # oops. I've overwritten foo
>> def bar(self):
>> pass
>>
>> print foo
>> print dir(foo)
>> print type(foo)
>>
>>   Paul Prescod
>
>Sure. But misusing classes as instances is quite rare in
>practice, and plugging members into instances is also
>quite rare in practice. Python's highly dynamic nature
>opens it up to a lot of difficulty in principle, but most
>deveopers seem to be quite disciplined in their use of
>dynamism.
>
>The difficulty here is simply that there is no way of
>isolating a base object that is supposed to be the platform
>for other objects from objects that are supposed to be
>updatable with new behavior.
>
>The higher a tower you want to build, the firmer the
>foundation. Conventions help, but if the conventions
>are helped along by the language, that's even better.

In Ruby you can freeze() any object.  But it seems like in this case,
just giving your base object a distinct name, like PrototypePolygon
will remind you not to change its definition later as you create
triangles, rectangles, etc.

I also would have no objection to some syntactic lock, like any object
name ending in an underscore is an immutable object.  We could also do
this the other way around.  Objects, by default are immutable.  That
would take care of most uses.  If you want a mutable object, give it a
name ending in ! (bang).

-- Dave