On 8/10/06, Chip Salzenberg <[EMAIL PROTECTED]> wrote:
More on the STM branch:
ANSWERS, FOR A CHANGE
* A comment asks:
/* XXX is it okay to combine flatten/slurpy into one flag? */
The answer is "No": "flat" is an output flag, "slurpy_array" is an input
flag, and there's no guarantee that the input and output flags won't
conflict with each other. So I guess this means that something has to
change.
I suppose trying to make '@' mean something different for signatures and for
calls from C (as I have done) is a Bad Idea as long as the same code is used
to parse the signatures in both cases. The easy solution is to choose
a character
other than '@' for one of the directions though I can't think of what
might be most
natural ('F' for flat?).
[one note moved later in this email]
MORE QUESTIONS
* The '@' character for native call signatures is new, and AFAICT is just
syntactic sugar, since the caller could do the array creation himself.
Could you explain what you would have to do if you didn't introduce this
feature? (I'm not necessarily against it, mind you, I just want to know
what the deal is.)
It is just syntactic sugar. So, not using would be as you describe, having the
(most likely PIR) caller construct the array manually. My use of this feature is
only to allow naturally passing an arbitrary number of arguments to
the subroutine that
is first executed in a new thread, which I feel is quite convenient.
It is, however,
not terribly important (and perhaps I shouldn't have spent time
implementing it), and
if deemed undeseriable, I would not suffer much penalty in removing it.
* Another comment asks:
# autogenerate for exotic types
# (XXX is this appropriate or do we want them to each
# be explicitly cleared to have the variant?)
Well, that depends. Is there currently any way for a named METHOD to
specify whether it is :write, and if so, is this used? If so, then yes,
making an automatic ro variant is OK. If not, then I think we might want
such a thing...?
The read-only variant generation currently does not handle NCI methods
at all. There are number of implementation options; the best I can
think of is to override findmethod (in the read-only type) to check
for a property on the found method PMC that would indicates it writes
(or vice-versa).
It also does not allow .pmc files to overide the default idea of
whether a vtable method is read-only.
A bigger issue for automatic read-only variant generation is that MMD
methods currently don't do any read-onlyness detection. (Sorry!) (This
is not quite as much as a problem as it may seem because things like
String and Integer, being designed to allow subclassing, call vtable
methods from their MMD methods to do any manipulation.)
As a stopgap solution, it would be easy to reverse the logic I have
now and default to not generating a read-only version except when the
.pmc file says it is okay instead of the other way around.
ANOTHER NAMING THING
* Please rename 'ro_variant' to something ending in '_vtable',
e.g. 'ro_variant_vtable', to make clear that it's not a class pointer
or type number.
Done (using suggested name).
-- Charles Reiss
