CoCoA » CoCoALib

After working on it, I realized that usually the function actually doing the "test" computation is also the function knowing whether other flags may be set. For example the test function for IsPrime in K[x] can also set the IsMaximal flag.
So now I believe that the test function should set the flag and all the other flags it knows of.
In other words: the flag should be set by the test function.

I'm not sure if this suggestion is a good one or a bad one.

If the flags are simply data members of type bool3 then the compiler offers no protection against using C++ assignment to these fields (rather than calling the specific flag-assigning fns).

We could get help from the compiler by putting all the flags in a separate, internal class; this class then offers public fns for assigning the flags, and for getting their values. Here is an outline of what I mean:

class ideal
{
  class FlagManager
  {
   private: // data members
     bool3 myMaximalFlag;
     bool3 myPrimeFlag;
   public:
     FlagManager() {} // default ctor OK???
     void myAssignMaximalFlag(bool value) { .... };
     void myAssignPrimeFlag(bool value) { .... };
     bool3 myGetMaximalFlag() const { return myMaximalFlag; };
     bool3 myGetPrimeFlag() const { ... };
  }
  FlagManager myFlags;
};

I am not proposing the names I have used here -- I think they are too cumbersome: for instance, a mem fn of ideal which has proved the ideal to be maximal would have to call myFlags.myAssignMaximalFlag(true) which says Flag twice...

Is it better to have a single setter fn which accepts a bool as arg, or have two setter fns (one with implicit arg true, the other with implicit arg false)? JAA currently prefers a single setter fn with a bool arg, as it "feels" a bit more flexible (even though no concrete example springs to mind).

I have a question: I have the function IsRadicalSPR(const ideal& I) which, in the way of determining if I is radical, may detect maximality.
This is not a member function: should it be? it is effectively an auxiliary function for IsRadical.

John Abbott wrote:

If the flags are simply data members of type bool3 then the compiler offers no protection against using C++ assignment to these fields (rather than calling the specific flag-assigning fns).

We could get help from the compiler by putting all the flags in a separate, internal class; this class then offers public fns for assigning the flags, and for getting their values. Here is an outline of what I mean:

I really like this idea, both for the safety, and also for the cleanliness: ideals have lots of 3flags...
I'll try doing something along those lines.