Sunday 21 July 2002 21:34, Dan Sugalski wrote: > > No. They are not. You're missing the important case where the data > structure is inherently and intrinsically multidimensional. > > my int Array @foo : dimensions(3); > @foo[1;2;3] = 12; > > Or whatever the syntax is in perl to declare a 3D array and access > the element at (1,2,3). >
In my opinion, there are actually two different things to dicuss: - keyed opcodes - keyed methods on the PMC vtable You can keep keyed opcodes, without actually implementing the keyed methods. Actually, ALL our keyed methods look like: ... stuff to get the value of SELF[key] into VALUE.. VALUE->vtable->method(..) Puting this code into the opcode, and removing the vtable methods (except get_keyed_*), shouldn't make it slower at all IMHO (same job being done, in the same way. The same number (two) of vtable calls). Keyed opcodes can stay in the interest of code density. > > No. Keyed access for all methods stays. You're forgetting one very > important case, the one where the contents of an aggregate isn't a > PMC. This scheme would then require the aggregate PMC to construct > fake PMCs to do operations on. Bad, definitely bad. Is really so bad? As long that what is ultimately stored in the aggregate is one of our base types (pmc, int, string, float), the opcode shouldn't need to build the fake PMC. Or, ¿are you talking about multi-dimensional PMCs? I don't see why these should need to build fake PMCs: you just call the get_keyed method, and it will do the Right Thing (probably getting the value directly, maybe propagating a portion of the key to a inner PMC). As I said, there should no be any speed cost at all, and a significant improvement on code size. But this is only an opinion. I am willing to submit a benchmarking patch if it has some interest. Best, -àngel
