Add ResizableStringArray.get_number VTABLE function

[Austin_Hastings]

NQP uses exclusively Numeric math, and if a string is split, the result is an RSA.

Since RSA currently does not support .get_number, NQP code fails when it generates $N1 = $P0 type code to extract the number of elements.

[whiteknight]

Can you post the NQP example code that creates this problem?

A few basic notes:

First, seems nonsensical to me to expect an Array to return a floating point number in any case. Especially in this case where it seems you want Parrot to implicitly cast the integer value to a float. It seems to me like the better option would be to retrieve the integer value and explicitly cast it if that's what you need.

Second, it seems strange to me that NQP would be forcing all mathematics operations to use floating point. Though considering the constraints of that language I won't raise a huge fuss over it. I know that it's not designed to be a complete and robust mathematics package. Is there any way in NQP to explicitly cast from float to int?

Third, what do the other Array types do in this instance? Is it just RSA that's missing the get_number VTABLE, or are other types missing it as well? I would much rather we move in a direction of more consistency among array types than less consistancy.

[Austin_Hastings]

Note that the first array here is a PMC array, because NQP creates the objects individually. The second is a RSA because that's what split returns.

austin@andLinux:~/kakapo$ cat test.nqp
my @strap := ('Foo', 'Bar');

if @strap > 1 {
	say("strap ynam toG");
}

my $str := "Foo::Bar";
my @parts := pir::split__PSS('::', $str);

if @parts > 1 {
	say("Got many parts");
}

austin@andLinux:~/kakapo$ parrot-nqp test.nqp
strap ynam toG
get_number() not implemented in class 'ResizableStringArray'
current instr.: '_block11' pc 0 (EVAL_1:6)
called from Sub 'parrot;PCT;HLLCompiler;eval' pc -1 ((unknown file):-1)
called from Sub 'parrot;PCT;HLLCompiler;evalfiles' pc 1303 (src/PCT/HLLCompiler.pir:707)
called from Sub 'parrot;PCT;HLLCompiler;command_line' pc 1489 (src/PCT/HLLCompiler.pir:794)
called from Sub 'parrot;NQP;Compiler;main' pc -1 ((unknown file):-1)

To your first point, while I'm not entirely comfortable with it, I can understand that there's no difference between get_number() and int2float(get_int()).

The second point is an NQP issue. Patrick's got math working, and if the price of that was that everything is an $N register, so be it. There's no way to go from float to int because int is virtually unheard of in NQP.

Third, the PMC type already has get_number. The other two, I can't say - they haven't appeared on my radar since they aren't naturally generated anywhere. I agree it were better to be consistent - by all means make sure they all DTRT.

[pmichaud]

On Mon, Feb 15, 2010 at 02:57:10PM -0000, Parrot wrote:
>  Third, what do the other Array types do in this instance? Is it just RSA
>  that's missing the get_number VTABLE, or are other types missing it as
>  well? I would much rather we move in a direction of more consistency among
>  array types than less consistancy.

[Answering out of sequence here for clarity]

Most of the other array types default get_number to be calls to get_integer.
In general, I think that any type that provides a get_integer should also
provide a get_number (that can just delegate to get_integer if appropriate).
More below...

>  First, seems nonsensical to me to expect an Array to return a floating
>  point number in any case. Especially in this case where it seems you want
>  Parrot to implicitly cast the integer value to a float. 
>  [...]
>  Second, it seems strange to me that NQP would be forcing all mathematics
>  operations to use floating point. 

Let me re-frame this discussion in terms of what our dynamic languages
actually need and are trying to do.  First, the forcing of mathematics
into floating point is really Parrot's influence, not NQP's.
What NQP, Perl 6, and other dynamic languages want is a way to say 
"give me a numeric value for this Object".  We really don't care if
that value is an integer, floating point, complex, fraction, or whatever 
-- we just want a numeric value that we can use as an argument in a 
mathematics operation.  (Here I'm using the term "numeric" in its
more generic sense of being number-like, emphatically not in Parrot's 
sense of meaning "floating-point".)

In particular, given a HLL statement like...

    my $c := $a + $b;

what we're wanting to do is take the numeric value of $a, add that
to the numeric value of $b, and store the result in $c.  Or, more
directly:

    my $c := +$a;

My point is that it's not the HLL (e.g. NQP) that is requesting 
these values to be floating point -- ints would be just fine.
It's Parrot's opcode and vtable set that constrain this to be
a "floating point operation".

The vtable interface that Parrot provides for "give me a numeric 
value" is "get_number", which currently casts everything into a 
floating point number.  For the +$a code above, I clearly can't 
have the compiler generate a call to "get_integer", because $a's 
numeric value might be something that doesn't fit in an integer.
So, NQP goes with what Parrot _does_ provide, which is to use
"get_number" to obtain a PMC's numeric value.

Any PMC that expects to be usable in a numeric context (including
arrays) therefore needs to supply a get_number vtable operation.

My view the underlying issue isn't that NQP or other languages 
are expecting Arrays to return floating point values specifically; 
the issue is that we want to be able to ask any generic object 
for its numeric representation, and we can't always know in advance 
if that object numifies to an integer.  So, the best we can do
at the moment is to use get_number as the general interface for
"give me a number".  (Clearly we don't want to be asking each 
object "what do you prefer" before we do any math on it... 
we just want an operation that gives us back a number that
we can do math on.)

It might be nice if there was a PMC form of the get_number
vtable function -- this would enable individual types to
dynamically decide what sort of numeric value to return instead
of constraining the answer to be a something that fits
in an N register.  Then an array could always return an 
Integer PMC in response to get_number, while a string or 
other data type could choose an Integer, Float, or whatever
is best for its particular value.

Pm

[whiteknight]

On Fri, Feb 19, 2010 at 10:39 AM, Patrick R. Michaud <pmichaud@pobox.com> wrote:
> Most of the other array types default get_number to be calls to get_integer.
> In general, I think that any type that provides a get_integer should also
> provide a get_number (that can just delegate to get_integer if appropriate).
> More below...

On one hand, I like the idea of consistency and if "all the other cool
kids are doing it", I don't see a problem with RSA doing the same
thing as well, for consistency's sake.

> my $c := $a + $b;

In this case it's not that we want to just take any old numeric value
and just store any old numeric type into $c. Far more common are ideas
of type promotions where $c is an integer if $a and $b are integers,
and $c is a different type depending on the types of $a and $b and the
rules of type promotion. If $a and $b are both Integer PMCs, it is
flat wrong in any language I can think of that $c would become a
Float.

That said we can obviously do some rudimentary checks, like if $a is
an Integer PMC, and $b is an Integer PMC, that $c likewise is an
Integer. But the waters get more murkey when we consider a myriad of
HLL-mapped integral types, some of which may choose not to cleanly
derive from Integer. In those cases it's prudent to ask whether the
PMC is int-like or float-like and handle it accordingly.

My point stands that it is completely nonsensical to ask certain types
for a floating-point value, and it's completely nonsensical (and
likely very inconsistent depending on HLL) to ask some types for an
integer one. NQP is one thing because it's a separate project and I
won't tell you how to write your code, but I am very strong in the
believe that Parrot should not be forcing these kinds of defaults on
it's users.

> Let me re-frame this discussion in terms of what our dynamic languages
> actually need and are trying to do.  First, the forcing of mathematics
> into floating point is really Parrot's influence, not NQP's.
> What NQP, Perl 6, and other dynamic languages want is a way to say
> "give me a numeric value for this Object".  We really don't care if
> that value is an integer, floating point, complex, fraction, or whatever
> -- we just want a numeric value that we can use as an argument in a
> mathematics operation.  (Here I'm using the term "numeric" in its
> more generic sense of being number-like, emphatically not in Parrot's
> sense of meaning "floating-point".)
>
> ...
>
> The vtable interface that Parrot provides for "give me a numeric
> value" is "get_number", which currently casts everything into a
> floating point number.  For the +$a code above, I clearly can't
> have the compiler generate a call to "get_integer", because $a's
> numeric value might be something that doesn't fit in an integer.
> So, NQP goes with what Parrot _does_ provide, which is to use
> "get_number" to obtain a PMC's numeric value.

So this really is a conflation of two separate issues. First, Parrot
really is misusing the term "number" in the context of VTABLEs to
really mean "floating point number". I think that should change. It's
not that get_number casts things to a FLOATVAL, it's that the function
is typedefined to return a FLOATVAL. Hypothetically if we renamed some
VTABLEs, in the case you described above would you opt to call
get_integer() or get_float() by default? Again, hypothetically, what
if there was a "get_numeric_pmc" (that you also mention below) that
would return the correct numerical representation of a PMC as another
PMC (be it an Integer, a Float, a Complex, etc)? Would that help to
make things a little more type-agnostic and prevent needing to ask an
array for it's floating-point value in the examples you posted?

In the way Parrot is currently set up, get_number() is explicitly a
request for a floating-point value and is treated as such throughout
the core repository. get_integer() is likewise an explicit request for
an INTVAL. We also don't have a way to even ask a PMC which of the two
it prefers, a choice which can have some very real relevance when the
type is expected to be used in calculations, especially calculations
performed by externally-loaded libraries, such as dynop libraries.

Second, Parrot needs a way to get a "proper" numerical value from a
PMC which is suitable for use in numerical calculations like you
mention above. This could come in one of two ways: Either asking the
PMC whether it is int-like or float-like, or asking it for a numeric
PMC type and delegating mathematic operations to that PMC.

> My view the underlying issue isn't that NQP or other languages
> are expecting Arrays to return floating point values specifically;
> the issue is that we want to be able to ask any generic object
> for its numeric representation, and we can't always know in advance
> if that object numifies to an integer.  So, the best we can do
> at the moment is to use get_number as the general interface for
> "give me a number".  (Clearly we don't want to be asking each
> object "what do you prefer" before we do any math on it...
> we just want an operation that gives us back a number that
> we can do math on.)

I would suggest that numifying to an integer is the far more common
operation when you consider things like counters, loop sentinels, and
array indices in most programming language. But, that's a semantic
issue that isn't worth discussion. Is the question "how to get any
math-suitable numeric value?" or "how to get the correct math-suitable
numeric value?". The two questions often will have very different
answers, especially in different HLLs. It should not be Parrot's place
to make the decision on a global level and say that all PMCs default
to returning a floating point value in a mathematical context.

> It might be nice if there was a PMC form of the get_number
> vtable function -- this would enable individual types to
> dynamically decide what sort of numeric value to return instead
> of constraining the answer to be a something that fits
> in an N register.  Then an array could always return an
> Integer PMC in response to get_number, while a string or
> other data type could choose an Integer, Float, or whatever
> is best for its particular value.

I like this idea the best, and will open a ticket to request it.

--Andrew Whitworth

[pmichaud]

On Fri, Feb 19, 2010 at 11:13:51AM -0500, Andrew Whitworth wrote:
> > my $c := $a + $b;
> 
> In this case it's not that we want to just take any old numeric value
> and just store any old numeric type into $c. Far more common are ideas
> of type promotions where $c is an integer if $a and $b are integers,
> and $c is a different type depending on the types of $a and $b and the
> rules of type promotion. If $a and $b are both Integer PMCs, it is
> flat wrong in any language I can think of that $c would become a
> Float.

Agreed fully.  The problem is that Parrot opcodes don't give me
this sort of control -- all I have for the above is the various
'add' opcode variants, and the only one that currently fits the 
generic meaning of '+' for most of the built-in types is add_n_n_n.
(In particular, the *Array PMCs don't support the VTABLE_add_* 
functions that would be needed for using the add_p_p_p opcode here, 
and arguably they shouldn't have to do so.)

The more direct explanatory case is the one I gave afterwards...

    my $c := +$a;

...how exactly would one represent this in PIR?  (The intended
meaning is that $c becomes the numeric representation of $a;
if $a is an Array, we'd like $c to be the number of elements in
the array; if $a is a String, we'd like $c to be the numeric
representation of that String (which might not even be integer
or floating point!), etc.

> My point stands that it is completely nonsensical to ask certain types
> for a floating-point value, and it's completely nonsensical (and
> likely very inconsistent depending on HLL) to ask some types for an
> integer one.  NQP is one thing because it's a separate project and I
> won't tell you how to write your code, ...

You've seemingly again made the mischaracterization of NQP as 
wanting a "floating-point value".  That's explicitly what
I was trying to disclaim in my previous message -- NQP doesn't
want "floating-point value", it wants something that is 
arithmetical/numeric.  At present all Parrot provides for this
are the "get_integer" and "get_number" vtable functions, and faced
with this choice, NQP settles for get_number simply because it
has the wider range.  But the choice of floating-point is imposed
on NQP by Parrot's API, not because NQP inherently wants operations
to be floating point (it emphatically doesn't).

> ...but I am very strong in the
> believe that Parrot should not be forcing these kinds of defaults on
> it's users.

...and my point is that Parrot is forcing these kinds of defaults.
So I think we're agreeing here.

> really mean "floating point number". I think that should change. It's
> not that get_number casts things to a FLOATVAL, it's that the function
> is typedefined to return a FLOATVAL. Hypothetically if we renamed some
> VTABLEs, in the case you described above would you opt to call
> get_integer() or get_float() by default? 

My point is that _neither_ of those vtables are a correct default.
NQP uses the "get_float" (get_number) option only because it's
less incorrect in the general case than "get_integer".

In the cases I've describe above, I want to have a vtable function
that means "return me a numeric value" without forcing me into
the false choice of a-priori requesting either an integer or a floating
point.  In other words, the caller shouldn't have to predetermine 
what kind of number it wants, it should be able to say "give me 
a number" and let the callee decide what sort of number (int, float,
fraction, complex, etc.) is appropriate to return.  (The caller
then decides what to do with that value, and if it's not something
it knows how to handle, it carps appropriately.)

> Again, hypothetically, what
> if there was a "get_numeric_pmc" (that you also mention below) that
> would return the correct numerical representation of a PMC as another
> PMC (be it an Integer, a Float, a Complex, etc)? Would that help to
> make things a little more type-agnostic and prevent needing to ask an
> array for it's floating-point value in the examples you posted?

Yes, it would be a big help.

> Second, Parrot needs a way to get a "proper" numerical value from a
> PMC which is suitable for use in numerical calculations like you
> mention above. This could come in one of two ways: Either asking the
> PMC whether it is int-like or float-like, or asking it for a numeric
> PMC type and delegating mathematic operations to that PMC.

The first approach (ask the PMC for int/float) is wrong on several 
levels, so the correct approach is ask it for a numeric PMC and delegate
to that PMC.

> It should not be Parrot's place
> to make the decision on a global level and say that all PMCs default
> to returning a floating point value in a mathematical context.

Agreed.  It should also not be Parrot's place to say that a caller
must decide beforehand if it wants an integer or floating point
representation.

> > It might be nice if there was a PMC form of the get_number
> > vtable function -- this would enable individual types to
> > dynamically decide what sort of numeric value to return instead
> > of constraining the answer to be a something that fits
> > in an N register.  
>
> I like this idea the best, and will open a ticket to request it.

NQP (and Rakudo) will benefit a great deal from this, I think.

Pm

[pmichaud]

A thought as I was heading out to lunch...

Turning this thread around a bit -- while it might seem nonsensical for a caller to ask an Array for a floating point value, I suppose one could argue that it's equally nonsensical for an Array to refuse to provide a floating point value if asked, given that it's perfectly willing to provide an integer value (and integers are subsets of floats).

This comment is not at all intended to detract from any of the points or suggestions made above -- I'm just observing that for many of our existing PMC types that are able to respond to get_integer requests, it's perhaps unreasonable for the PMC to also say "...but I won't give you a float if you ask for one of those." In the few cases (I can't think of any) where returning a float might be incorrect or misleading, then throwing an exception makes perfect sense. But I wouldn't want to see Parrot imposing an interpretation that things that tend to be integer-like won't also act as floats when explicitly asked to do so.

Bottom line: In addition to the get_number_pmc proposed above, I think we should also do what this ticket asks, and add get_number vtable entries to the PMCs that provide get_integer (and where it makes sense to do so). We already do this for a number of the array PMC types -- let's just make it consistent all the way through (and hopefully this comment provides a justification for doing so).

Pm

[whiteknight]

Replying to pmichaud:

Turning this thread around a bit -- while it might seem nonsensical for a caller to ask an Array for a floating point value, I suppose one could argue that it's equally nonsensical for an Array to refuse to provide a floating point value if asked, given that it's perfectly willing to provide an integer value (and integers are subsets of floats).

Point noted, and in the spirit of musing I would turn this around on you again and ask why treating an array as an integer value should return the element count of that array? This is very much a perlism, when many other languages would require you to call length($P0), or $P0.count, or $P0.length, or some variation thereof. The fact that we can say "$I0 = $P0" to get the length of the array really does require a cognitive leap and a familiarity with Perl5's notions of arrays in a scalar context.

If getting the integer form of an array is really code for "get the number of elements" (which, I think, is especially unnecessary in light of the "elements" opcode and VTABLE), it really is a bit of an extra stretch to suggest that calling get_number should only be able to return a floating-point representation of what get_integer returns (which, again, is just a convenience copy of VTABLE_elements). Maybe I suggest that get_number should return a value for the array which is more suited for representing as a floating point: Maybe memory utilization percentage, some sort of compression metric, memory fragmentation percentage? In the case of sparse arrays, VTABLE_get_number could easily return a some kind of utilization percentage.

If we look at everything through perl-colored glasses we can say that it only makes good sense that Parrot's array types behave in various contexts the same was as Perl's arrays do. If we look at a language like Octave, asking for an integer from an array (a vector) is actually intended to return an array where all the elements of the input array are converted to integers, recursively. Array types there are multi-dimensional, so Octave needs concepts of "length" and "width", in addition to a total count of "elements". So obviously we wouldn't use Parrot's VTABLE_get_integer for that behavior, but it does go to show that other languages have very different notion of how an array type should respond to a "get an integer" or "get a number" request.

[pmichaud]

On Fri, Feb 19, 2010 at 06:20:18PM -0000, Whiteknight wrote:
>  Point noted, and in the spirit of musing I would turn this around on you
>  again and ask why treating an array as an integer value should return the
>  element count of that array? This is very much a perlism, when many other
>  languages would require you to call length($P0), or $P0.count, or
>  $P0.length, or some variation thereof. [...]

I fear that you routinely ascribe to my suggestions and comments
far more Perl-think and Perl-based motives than are actually present.  
If this is the case, please stop doing so.

None of what I wrote above depends on or has anything specifically
to do with a perlish interpretation of arrays.  In one comment above
I did give an example of an Array returning its element count, but 
there I was simply citing Parrot existing behavior for arrays,
and not intending to imply that this is the way arrays are
supposed to behave when treated as integers.

More to the point, even NQP doesn't impose this interprestation
on arrays.  NQP truly does wish to be as transparent as
possible to the underlying vm and objects, so if you say

    my $value := +$obj;

then what NQP wants to give you is $obj's idea of its numeric
value, whatever that happens to be.  NQP absolutely does *not*
say or imply "if $obj is an array, then its numeric value is
the number of elements in the array" -- that choice is
entirely up to the underlying objects and vm (Parrot in this
instance).

This extends even to variables that have the @ sigil -- with

    my @array := XYZArray.new;
    my $value := +@array;

you get whatever XYZArray reports as its numeric value, which
can be whatever the XYZArray implementor decided was
appropriate.

>  If getting the integer form of an array is really code for "get the number
>  of elements" (which, I think, is especially unnecessary in light of the
>  "elements" opcode and VTABLE), it really is a bit of an extra stretch to
>  suggest that calling get_number should only be able to return a floating-
>  point representation of what get_integer returns (which, again, is just a
>  convenience copy of VTABLE_elements). 

The choice to have Parrot arrays return the number of elements
as its integer value was made long before I started working
on things, and it's not something that either I or NQP require.  
If an NQP programmer wants to be sure to get the number of elements 
in an array and not rely on the PMC's get_number interface, the code is:

    my $value := pir::elements(@array);

Or, if @array has a method for returning its number of elements, you
can use that:

    my $value := @array.elems();

The meaning of +@array is not at all dependent on Perl.

>  Maybe I suggest that get_number
>  should return a value for the array which is more suited for representing
>  as a floating point: Maybe memory utilization percentage, some sort of
>  compression metric, memory fragmentation percentage? 

I suspect you mean this as a strawman argument, but overall 
the suggestion would seem to be a very poor one.  The point of
the vtable interfaces is to promote language interoperability, and
not as places to hang behaviors we think might be appropriate.

In Parrot, the commonly understood meaning of get_integer is
"give me your integer value", and the common understanding of
get_number is "give me your floating-point value".  I think that
the vast majority of us would be very surprised to have get_integer
and get_number use such wildly different semantics (whatever
they may be).

Again, the point of my previous comment was simply to say that
if a PMC provides a get_integer vtable, it would seem to make
sense in most cases to have it go ahead and provide get_number
as well.  This does not seem to me to be a particularly perlish 
view of things.

>  ... but it does go to show that other languages have very
>  different notion of how an array type should respond to a 
>  "get an integer" or "get a number" request.

Sure, but how many of those languages have the notion that
"get an integer' and "get a number" are radically different, 
as you suggest above?

Again, I'm not at all saying that "get_integer" or "get_number" 
on an array must always return the number of elements, or
basing my suggestion on this perl-specific behavior.  I'm simply 
saying that if a PMC provides get_integer (whatever that ends up 
meaning for the PMC, in whatever language), then providing the 
equivalent value for get_number often makes a lot more sense 
than throwing an "not implemented" exception.  (And I think
it makes much more sense than putting in some other behavior
that just happens to provide a floating point value.)

If your dislike of perlisms in Parrot is so great that you 
believe that Parrot's core array PMCs should not have the 
current get_integer behavior, that's actually okay with me.  
It won't affect NQP one bit.  But let's at least have get_number 
and get_integer be reasonably consistent wherever we do provide them.

Pm

[whiteknight]

Replying to pmichaud:

I fear that you routinely ascribe to my suggestions and comments far more Perl-think and Perl-based motives than are actually present. If this is the case, please stop doing so.

I apologize if this is the way my comments have been viewed. This is not my intention. All of my objections and criticisms are aimed at Parrot and it's design, not at you or at NQP. Parrot's design has been strongly influenced by Perl5 for, as far as I can tell, the entirety of the project. In many cases I think that influence is fine. In some I think it doesn't make sense in light of Parrot's greater goals.

None of what I wrote above depends on or has anything specifically to do with a perlish interpretation of arrays. In one comment above I did give an example of an Array returning its element count, but there I was simply citing Parrot existing behavior for arrays, and not intending to imply that this is the way arrays are supposed to behave when treated as integers.

My point was that this is how arrays are treated in Perl5: In a numerical context an array returns it's element count. I can't think of too many other languages where this is the default behavior for an array (of course, we have to stretch the notion of "context" when talking about other languages).

I suspect you mean this as a strawman argument, but overall the suggestion would seem to be a very poor one. The point of the vtable interfaces is to promote language interoperability, and not as places to hang behaviors we think might be appropriate.

It was a strawman, but does illustrate a point. When I say "get a floating-point number from that array", there are a handful of different values that could be reasonably returned. Likewise, when I say "get an integer from that array", it doesnt have to mean get the element count. Parrot defines VTABLE_get_integer on arrays to be identical to VTABLE_elements by convention, and I don't think that's necessarily the best idea. We also like to think about VTABLE_get_number as returning the same value in a different format as VTABLE_get_integer by convention, when I don't think that always makes good sense either. And then saying that Arrays should be forced to implement VTABLE_get_number as a cast over VTABLE_get_integer is just compiling a strange decision onto a strange decision. Sure, we can talk about PMCs interoperating and how there's this magical common interface, but the reality is we're talking about using arrays as items in non-vector mathematical equations, and that requires several leaps of logic and understanding that I don't think Parrot should be forcing at the lowest level.

Again, the point of my previous comment was simply to say that if a PMC provides a get_integer vtable, it would seem to make sense in most cases to have it go ahead and provide get_number as well.

If it is the intention that get_integer and get_number always return the same number only in different formats, then that is a guarantee that we should enforce. We can discuss that topic in a different ticket if changes need to be made.

Sure, but how many of those languages have the notion that "get an integer' and "get a number" are radically different, as you suggest above?

It has to depend on the type. Integer.get_number and Float.get_integer have certain expectations but other more complicated types do not. I can imagine legitimate types where the ideas of "give me an integer" and "give me a number" could easily be expected to return different values.

If your dislike of perlisms in Parrot is so great that you believe that Parrot's core array PMCs should not have the current get_integer behavior, that's actually okay with me. It won't affect NQP one bit. But let's at least have get_number and get_integer be reasonably consistent wherever we do provide them.

I have no dislike of perlisms, it is not a criticism to say that they exist or that Parrot has been influenced by them. It is also not an insult to say that many other HLLs do not share the same kinds of semantics.

So long as things do stay consistent (or, more realistically, begin to approach consistency) I will not be unhappy, but my strong preference is in not providing VTABLEs on types where they are not necessary and not creating a de facto standard where PMC types are compelled to provide large numbers of extra VTABLEs. Consistently minimal is always easier to get right and maintain than consistently complicated. We could argue all day, of course, about what constitutes an acceptable "minimum".

[pmichaud]

Added in r44393 (with tests), closing ticket.

Pm