change get_string on FPA, RPA (et al?)

[coke]

RPA inherits the get_string vtable from its parent, FPA, which says:

Returns the number of elements in the array as a Parrot string. (??? -leo)

??? indeed - why doesn't this return something more useful like, e.g.: join(" ",@foo) ?

Anyone like the current functionality, or agree with the proposal?

[pmichaud@…]

On Wed, Nov 25, 2009 at 04:27:55AM -0000, Parrot wrote:
>  RPA inherits the get_string vtable from its parent, FPA, which says:
> 
>  {{{
>  Returns the number of elements in the array as a Parrot string. (??? -leo)
>  }}}
> [...]
>  Anyone like the current functionality, or agree with the proposal?

The current functionality (return the number of elements as a string)
is not at all useful, and in many cases it's worse than throwing
an exception would be.

I'd like to see the default behavior be something like "all elements
joined by a space", or if that's inappropriate then simply throw
an exception when attempting to get_string() from a RPA/FPA.

Pm

[dukeleto]

+1 to get_string = join(" ",@foo)

[cotto]

+1 to returning the equivalent of join(' ', @foo).

[whiteknight]

I disagree, I think the better option is to throw an exception. An Array isn't a scalar, and any VTABLE that implicitly treats it as one is wrong. If I have an RPA, for instance, and it contains PMCs which don't stringify, when we call VTABLE_get_string on the array we are going to get something that looks like an unrelated error and it's going to be very confusing.

If HLLs want this kind of behavior, it can be easily added in a subclass, or some kind of extension method in the namespace.

[cotto]

We have VTABLE_does so that people know what class of PMC they're dealing with. If an HLL is looking for a string-like thing, it should be checking that the PMC does String.