freepooma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pooma-dev] Domain traits


From: James Crotinger
Subject: Re: [pooma-dev] Domain traits
Date: Wed, 11 Apr 2001 08:38:45 -0600
User-agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]