[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Regions
- To: <heh>
- Subject: Regions
- From: Mark S. Miller <mark>
- Date: Wed, 15 Nov 89 15:08:13 PST
- Cc: <xtech>
- In-reply-to: <Hugh>,59 PST <8911112001.AA02440@xanadu>
Date: Sat, 11 Nov 89 12:01:59 PST
From: heh (Hugh Hoover)
...
Other limitations:
The lambda operations (intersect, union ...) are limited to be between
DiscreteInterval and DiscreteInterval or:
DiscreteIntervalUnion and DiscreteInterval or:
DiscreteSet and DiscreteSet.
The implementation can be extended as required for better polymorphism.
(except that I think it is inappropriate to build a DiscreteSet of Integers
and then do operations with DiscreteIntervals or their Unions)
The problem is simplicity of contract. How should
"Region * Region::intersect (Region *)" be defined? Remember that
the holder of a pointer-to-Region shouldn't have to know or care which
implementation he's got unless he wants to interact with subclass
specific behavior. To say that both Regions have to be in the same
coordinate space is a restriction that means something at the "Region"
level of abstraction. The above restrictions on polymorphism don't.
If we are going to have this kind of restriction, then "intersect",
"unionWith", etc, shouldn't be defined in class Region, just in the
subclasses at which your restrictions make sense.
I feel strongly that these kinds of polymorphisms need to be complete,
or the user of the module *cannot* form a simple model of correct use.
Take a look at "predx.cxx". This is essentially the module that your
Region stuff is attempting to replace. Most of the mechanism in there
is to achieve this very polymorphic completeness. That's why
"predx.cxx" looks so hairy inside.
More hair inside in order to have less hair outside! Isn't software
anatomy strange?