Re[2]: Mutable Bytes

Lenard Lindstrom <[email protected]> Mon, 26 Jul 2004 19:22:44 -0700 (Pacific Daylight Time)
Newsgroups gmane.comp.lang.prothon.user
Message-ID <Mahogany-0.66.0-4294505119-20040726-200924.00@pop3.norton.antivirus>
On Mon, 26 Jul 2004 14:02:55 -0700 Mark Hahn <[email protected]> wrote:

> Lenard Lindstrom wrote:
> 
> >I can only guess that in Python character strings were used 
> >for binary data to keep down the number of built-in types. 
> 
> >Also a function's compiled byte code is stored as a string. 
> >Byte code is a low level feature that is not considered 
> >portable across versions. So it makes sense to discourage 
> >direct manipulation of the byte code. If Prothon binary data 
> >is made visible within the language as byte strings does it 
> >make sense to allow direct changes to them?
> 
> If bytecodes were an attribute of a function like you have always suggested,
> you'd be able to change them whether the bytecodes themselves were in a
> mutable object or not.  Just as you can change a string attribute of
> something even though a string is immutable.
>
Not when it is a read-only attribute.

> Also, the problem you bring up is a perfect candidate for the security
> feature.  You could easily set the bytecode object write access to system
> level and then nobody could ever touch it.
>
Okay.
 
> By the way, I think you are getting your wish.  I am in the middle of
> restructuring my objects for the new copying garbage collector and
> binary-data is stored directly inside objects now instead of being linked to
> in a separate malloc.  Every function is copied before it is called and my
> old way of storing the bytecodes in the binary-data section of an object is
> now inefficient because the bytecodes would be copied on every call.  Having
> the bytcodes in a separate Bytes object would mean the shallow function copy
> wouldn't have to copy the bytecodes on every call.  So I'm moving the
> bytecodes to an attrbiute of the function like you have always said it
> should be.
> 
It was only a suggestion so the disassembler can be written in Prothon. Beyond
that unless one can actually execute custom created bytecode strings it is
of little use.

> Another change I am mentioning in my talk is on my to-do list.  The scope
> object for functions will now be the actual function object itself.  So all
> local variables will be attributes of the function also.  This means every
> attribute like fParams_ better have the trailing underbar. :-)
> 
What if the function is called recursively or from more than one thread at the
same time?

Lenard Lindstrom
<[email protected]>