On Tue, Apr 11, 2006 at 07:05:33AM -0700, Will Coleda wrote: > P1 = new .Float > P1 = 123
> The assignment of 123 autoconverts the float to an integer, which > doesn't support the 'exp' method that's defined in the Float pmc. > (Change the 123 to 123. and it works fine.) > > Given the morphing that typically happens, I'd expect to be able to > do numeric (as opposed to integer) ops on integer pmcs and have it > autoconvert to float. I'm not sure which parts of the fine documentation I've failed to read or digest, and whether I'm about to criticise something fundamental that someone(s) have worked on for a long time, but from reading this message alone this whole behaviour just feels plain wrong. Sort of "principle of most surprise" It doesn't seem very intuitive that the virtual machine's basic types (or at least the ones that have names suggesting that they are basic) are built to jump sideways at the least provocation. I can see value in a type .Number, which changes internal representation and vtable as and when necessary, but I'd still expect it to report "Number" when asked what type it is, because the internal representation would be a mere implementation detail. But I'd expect a type .Float to behave much like a C float and coerce values fed to it, rather than metamorphose to their type. Was this built in morphing the cause of the problems Leo was describing in trying to make a user defined class that is derived from Int? Nicholas Clark
