I don't think global options are desirable.
I would make your operators work in a single way and if the user
wants a different way he can call whatever functions you provide
directly instead of using the operators.
If you really need two ways with operators I would define a subclass
with operators working in the alternative way and have as.whatever
methods that converts back and forth.
Another possibility is to have the way it works be a special
attribute of the object itself (other than "class").
On Feb 4, 2008 9:25 AM, Robin Hankin <[EMAIL PROTECTED]> wrote:
> hits=1.0 tests=MANY_EXCLAMATIONS
> X-USF-Spam-Flag: NO
>
> Hi
>
> I am writing a package for multivariate polynomials ('multipols')
> using S3 methods.
>
> The package includes a Ops.multipol() function for the
> arithmetic methods; I would like
> to define some sort of user-specified Boolean option which, if
> set, would force results to be simplified as they are produced.
>
> Call this option "trim". Trimming a multipol results in
> a smaller array that is more manageable.
>
> Mostly one wants to trim, sometimes not.
>
>
> Would options() be a good way to manage this?
>
> One issue is the behaviour of unary operators "+" and "-".
>
> If trim is TRUE, then "a" is one thing, but "+a" returns
> "trim(a)", which might be different.
>
> Also "1*a" would be different from "a" and "a+0"
>
>
>
> Does the List consider this to be Good Practice?
>
> Has anyone got comments?
>
>
>
> --
> Robin Hankin
> Uncertainty Analyst and Neutral Theorist,
> National Oceanography Centre, Southampton
> European Way, Southampton SO14 3ZH, UK
> tel 023-8059-7743
>
> ______________________________________________
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
