On Wednesday, June 11, 2003, at 05:48 AM, Tim Bunce wrote:
(vi) ---- Conversions of User Defined Types/Classes ----
It may be useful to allow the same level of pragma-based control for
user-defined types and classes. For example, a given class Foo may
wish to be "silently" convertable to an C<int>. One proposed syntax to
declare the method of coercion/conversion might be:
class Foo { ...
to int {...} # or C<as int {...}>? }
However, users of such a class could adjust the warning level of the given conversion using the alternate syntax given above (v):
use strict conversions warn { Foo => int };
For my int $int = $foo;
isn't the int() method (vtable entry) called on $foo? (effectively) So the $foo object is asked to provide an int for assigment to $int. So the Foo class gets to decide how to do that.
Yep. The general question that has come up before is to what extent the user of a given class or module should be able to influence the "strictness" of the interface of that class/module -- without altering the module, obviously. The general feeling was that people wanted to be able to do it, because they didn't want to be bound to a particular CP6AN author's decisions on interface strictness.
The specific issue discussed previously, IIR, was something like this:
class Foo {
method bar(str $s);
}If you said:
my int $i = 5;
$foo->bar($i);what should happen? Should bar() convert $i to a str, or give a compiletime warning or error because it's not a str? And is that determined by the strictness level of the Foo class, or the strictness level of the calling code, or --shudder-- possibly both?
Please correct me if I'm wrong (which I could easily be as I've not been following any of thise closely).
I think this is an important topic because it may reflect back on how the specific Int/Num/Str classes should also be handled.
Tim [quite possibly talking nonsense]
Talking perfect sense. It's a nasty issue.
MikeL
