In message <20020721174150$1afe@gosford.compton.nu>
Scott Walters <phaedrus@illogics.org> wrote:
> I propose that keyed access do exactly eight things:
>
> * fetch a PMC using a key
> * fetch a integer using a key
> * fetch a number using a key
> * fetch a string using a key
> * store PMC
> * store int
> * store num
> * store string
>
> To add to a PMC, the PMC would be fetched, then a seperate instruction
> would add to it. This returns keys to their roots of merely optimizing
> access to deeply stored items.
You may well be right. I am certainly concerned about the amount of
cut and paste duplication involved at the moment.
Your argument is orthogonal to my question though - even if we decide
to restrict keyed access to just the set opcode we still have to decide
how to encode that keyed access in the bytecode.
> My ideal would be to axe keys entirely except as a special case of
> PMCs, and have PMCs define an iterator style interface that allowed
> them to be used as keys where it made sense, and simply return as_string()
> where it didn't, allowing them to be used as scalar-ref style hash keys
> at a minimum.. but I digress.
While I am a big fan of iterators I'm not quite clear how you mean
to apply them to keyed access?
Tom
--
Tom Hughes (tom@compton.nu)
http://www.compton.nu/
Thread Previous
|
Thread Next