RE: [pooma-dev] Domain traits

[Julian C. Cummings]

Hi Scott,

OK, I will go ahead and replicate the DomainTraits
traits info in the Domain subclasses.  Just be aware
that code written using the traits this way will fail
when the object is not actually a Domain subclass
(e.g., an int).  I would prefer to eliminate such
potential pitfalls now, while the changes are easy
to make and the code base is small.  But I am clearly
in the minority on that point.  I will document the
potential problem here with code comments, in case 
this bites us later.

By the way, I made an attempt to implement Jim's idea
of eliminating DomainTraits specializations for Domain
subclasses and making the general DomainTraits<T> get
all traits from T.  Alas, it doesn't work.  There's
one really important reason for DomainTraits: to define
Storage_t, the type of storage for the Domain's actual
data.  This data lives in DomainBase, a parent class
to Domain.  A Domain subclass cannot provide the type 
for this data member of DomainBase, so it must come from
an external class: hence DomainTraits.  I forgot about
that.  Somewhere, Bill Humphrey is laughing fiendishly...

I'll check stuff in later today.

-- Julian C.


> -----Original Message-----
> From: Scott Haney [mailto:address@hidden
> Sent: Wednesday, April 11, 2001 3:00 PM
> To: address@hidden
> Subject: Re: [pooma-dev] Domain traits
> 
> 
> 
> On Wednesday, April 11, 2001, at 03:25 PM, Julian Cummings wrote:
> 
> > OK, but can I commit these changes anyway??  ;-)
> 
> Hi Julian,
> 
> I agree with Jim and Stephen on the basis that (1) it makes code uglier 
> and (2) it represents a significant change to the Domain user interface. 
> The Proximation crew is solidly against this, so please do not commit 
> these changes, except for the enum to static const modification. Let's 
> move on.
> 
> Scott
> 
> --
> Scott W. Haney
> Development Manager
> Proximation LLC
> 2960 Rodeo Park Drive West
> Santa Fe, NM 87505
> Voice: 505-424-3809 x101
> FAX: 505-438-4161
>