Mike wrote:
>
> >: (B) Need to know the root of the numeric types
>
> If it isn't obvious to everyone else, the main (only?) reason to care
> about this is when checking/specifying context/args. Assume num means
> a double-precision float.
>
> Simply put: (a) if you pass an <int> to a function defined as taking a
> (floating-point) <num>, does the function always convert your <int> to
> a <num> before doing anything with it, or does it know it doesn't have
> to? And (b) are you allowed to discriminate between 'floating point'
> and 'integer' context, and how?
>
> Option 1:
>
> sub foo(num $n; int $i) # _always_ forces $n to a double
> # _always_ forces $i to an int
> sub bar(numeric $n) # allows both int or double, doesn't care
>
> if want numeric {
> if want int { ... } # both are subclasses of numeric,
> if want num { ... } # but only siblings to each other
> }
>
> Option 2:
>
> sub foo(num $n; int $i) # allows $n as int or double
> # $i always forced to an int
> sub bar(num $n) # allows both int or double, doesn't care
>
> if want numeric { # (maybe still want abstract base anyway)
> if want num { # num is the base class
> if want int { ... } # int is special case of a num
> }
> }
>
> .... Nasty issue. #1 allows you to be more precise, important if
> constantly converting nums <--> ints would notably slow things. But #2
> more obviously does WYM most of the time.
>
> Hmm, here might be an answer (thinking aloud). Perhaps <num> is the
> base class, just like it is now (you can put both floats and integers
> in it, it doesn't care). <int> is for explicit integer, <float> is for
> explicit double.
>
> num
> - int
> - float
>
> Such that the literal 1.234 is born as type <float>, which is trivially
> type <num>. Literal 1234 is treated as an <int>, same deal.
>
> So we'd still use <num> and <int> for most things, but we'd have
> <float> hanging out as a way to explicitly type/cast/contextify*:
>
> sub foo(float $i)
>
> .... in cases where it really mattered. Would that better solve the
> issues in options 1 and 2(?)
>
> MikeL
>
> *(contextify? contextification?) :-)
A common base class is not necessary for automatic type casting.
Besides, in p6, multimethod dispatch will be the preferred way of
handling such cases.
The p6 type system is still in heavy flux at the moment. There won't be
any final answer until closer to A12. Go with what you have for now.
Type casting isn't really a subject for first few chapters anyway.
Allison
