Re: [pooma-dev] Domain traits

[Julian Cummings]

Hi Jim,

I feel your pain with regard to the whole design of Domains.
However, you are overstating the difficulties here a fair bit.
You are correct that the main reason for the existence of
DomainTraits is to handle int's as a Domain.  We need that
capability for the Array interface.  As a result, it is sensible
to standardize the method of obtaining traits info by having
all Domains do this via a DomainTraits specialization.  I
don't think DomainTraits can or should be eliminated at
this point.  My only question was whether it was OK to
require that code pull these traits from DomainTraits, and
not assume that the traits info is duplicated in the Domain
class itself.  Obviously, not using DomainTraits fails if the
"Domain" is actually an int, but then again, the code may not
be expecting an int anyway.

There are not many changes required to existing code.  I found
a few spots in BrickBase.h, the MakeReturn functors for Array
and NewField, and some of the Evaluator classes where we
were extracting a trait from a Domain rather than DomainTraits.
I have already sent Jeffrey all the changes so he can double-check
me on that.  To address your comments about usability: the Domain
header files such as Interval.h already include the corresponding
DomainTraits.Interval.h header for the DomainTraits specialization.
So no new includes are required beyond what is already done.  The
DomainTraits.int.h file is sneakily included by Loc.h and/or Interval.h
as well, mainly because we define arithmetic interactions between
int and these two Domain types primarily.  I agree that this is crummy
physical design, but it is functional, and we are not likely to add further
DomainTraits specializations for other non-Domain types.

The main motivation here is not to clean up the design of Domains.
It is to avoid unnecessary duplication of static traits data in both Domains
and DomainTraits, given the necessary evil of a DomainTraits class.

-- Julian C.

P.S. This issue of a separate traits class doesn't apply to Layouts or Engines.
In those cases, I would like to convert the enums to static data members,
but we can just leave the data where it is.  I'll do those changes later.


James Crotinger wrote:

> on 4/10/01 7:44 PM, Julian Cummings at address@hidden wrote:
>
> > I think people are used to the first notation because we
> > do that with objects like Array and NewField.  If people
> > are really annoyed by this, I suppose I could put the traits
> > values back into the Domain classes.  It just seemed kind
> > of silly to me to have the traits values repeated in two
> > different places.  What do you think?
>
> ACK!
>
> >From a usability standpoint, these should stay in the domains. I think we
> went way overboard in generalizing domains, and part of that is
> DomainTraits.
>
> Aside from "int", we don't use any non-"src/Domain" classes as Domains, and
> I suspect that most things that get a Domain really aren't expecting an int.
> Thus we don't need the extra layer of indirection (which does have a cost in
> both compile time and code complexity). Further, since we have Loc<1> for to
> represent single points, we don't even need to provide the capability of
> using Domains as ints. The main exception is in user interfaces where ints
> are expected (Array::operator()).
>
> Also, I'm not even sure what I'm supposed to include if I'm going to use the
> DomainTraits class. Do I just include "Domain/DomainTraits.h" (which is just
> the general template). Do I include every one? What if someone later adds
> another?? Whoever instantiates our template will have included the
> appropriate Domain header, and thus will have the appropriate DomainTraits
> header, so maybe I only need the general template to get things to compile,
> although this seems like a physical design mistake to me. And what about our
> friend "int" (the only reason to provide the indirection in the first
> place). There is no "int.h" that includes "DomainTraits.int.h", so that
> specialization will not be there. So I do need to include
> DomainTraits.int.h. What if someone tries using an int[] as a 1D domain? We
> could probably make that work (if we can't, then DomainTraits really is
> pretty worthless 8-). Etc...
>
> So...
>
> I'd say changing enums to static const's in order to eliminate some compiler
> warnings is cool. But I don't think we want to start cleaning up the Domain
> design unless we're ready to jump in whole hog and basically do
>
>   % rm -rf Domain
>
> and make a fresh start.
>
>     Jim

--
Dr. Julian C. Cummings                       E-mail: address@hidden
California Institute of Technology           Phone:  626-395-2543
1200 E. California Blvd., Mail Code 158-79   Fax:    626-584-5917
Pasadena, CA 91125