On Wed, Dec 16, 2009 at 2:10 PM, Dave Whipp <d...@dave.whipp.name> wrote:
> The definition of the Complex type seems a little weak. A few things:
>
> To get the Cartesian components of the value there are two methods ("re" and
> "im"). In contrast there is just one method "polar" to return the polar
> components of the value I'm not sure that this asymmetry is a good thing.
> Contrast with Rat which has both separate accessors and the "nude" method (a
> name that could possibly be improved to avoid adult-content filters)
>
> The next thing I notice is that the return value of "polar" is defined as a
> "Seq" (as is the return value of "nude"), with an English-language
> definition of that the (exactly) two members of the sequence are. Surely it
> is possible in a perl6 signature to define the return value more formally,
> something like:
>
> our multi method polar (Complex $nim: --> [ Real $mag where 0..Inf, Real
> $angle where -π ..^ π ]) is export { ... }
>
> Finally, anyone using complex numbers probably wants a "conjugate" method
> and/or operator postfix:<*> almost as much as they want unary-minus:
>
> $mag = sqrt( $z * $z* );
All good points.
IMHO, what we want is a role that defines four separate accessors (two
for cartesian coordinates and two for polar coordinates); a "coercion
constructor" (i.e., it accepts any object that does the role, and
returns an object using an implementation to be defined by the class);
a postfix:<*> method; and the usual stuff. And we want a pair of
classes, one of which implements the role using cartesian coordinates
and another that implements it using polar coordinates. I forget if
Perl still allows you to use a fully-defined role as a class; if so,
handle the cartesian implementation within the Complex role, with the
ComplexPolar class overriding enough of that definition to make it
polar instead of cartesian.
--
Jonathan "Dataweaver" Lang
