Prothon Prototypes vs Python Classes

[Mark Hahn]

Mutability is an interesting area.  I just added an unmutable bit in the
Prothon internal object which makes the read_lock call a no-op and causes a
write_lock call to throw an exception.  This makes the object
write-protected and makes the lock code run much faster.

I did this for internal performance reasons, but after doing it I realize
that extending it to the Ruby freeze() level would be really good.  Tying
the freezing in somehow to the bang! methods is also in interesting area of
research.
Mark Hahn (Prothon Author)

P.S. If this belongs in the Prothon list instead of Python, let us know.


"David MacQuigg" <dmq at gain.com> wrote in message
news:bi1e601vsm4qtqaieqdo69bco64m7naupa at 4ax.com...
> 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
>