🚀 go-pugleaf

In article <1990Aug14.224806.21375@brutus.cs.uiuc.edu> 
nelson@melodian.cs.uiuc.edu (Taed Nelson) writes:
> The example where we really felt the need for something between non-const
> and const (and that being constant to the user but the object may change
> its internal state) is for objects which have a "current placeholder" type
> of field.
> 
> For example, we have a Dictionary class which is kept current by the system,
> not the user / user program.  Whenever the user wants to use the dictionary,
> we give them a constant reference to it. This allows them to extract entries
> (which return constant references as well) since that is a const
> member function.
> Sometimes, though, the user will want to iterate over the entire dictionary.
> For that reason, we provide them with various First() and Next() functions.
> Unfortunately, the "current entry" which is needed for the Next() needs to
> be changed, thus violating the "constness" of the object.
> 
> We solved this problem by providing an "iterator" class which the user 
> uses to provide the Next() functions (the iterator does the storing of the 
> state information), but I don't think it very clean.  Especially since it 
> requires another class...

I think the iterator solution is very clean.  Seperate iterator classes 
allow multiple iterations over the same collection.  They also neatly 
divide the job of iterating, and as you have shown, they pull out the 
variable part of a constant object.

In fact, the recent examples that have shown a need for "partially const" 
objects have fallen in the same catagory:  I think they can be solved by 
seperating the constant and variable portions of an object into constant 
and varying fields or classes.

Although it may be expedient to make a statement that an object is const 
when it really isn't, I think in the long run honesty is the best policy.  
I suggest a hard line approach: const is constant.


Derek White                          AppleLink: DEREK
              - Standard Discliamer -