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