Prothon Prototypes vs Python Classes

[John Roth]

"Mark Hahn" <mark at prothon.org> wrote in message
news:ZNF9c.49108$cx5.10276 at fed1read04...
> 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)

I think that's a very rational way to go about it. I don't think that
lexical
labeling will work, though. It makes initialization too difficult.

John Roth

> 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
> >
>
>