Re: [chlor-develop] CSegment

[<chl...@li...>]

>> and consistent. A bounding box at node or segment level is  
>> absolutely not needed.
>
> I cannot agree. You need segment bounding boxes for intersection  
> tests. Have a look at CPath's containsX: Y: for example. Not to  
> mention Segment-segment intersections finding.

This is the common performance-memory dilemma. As a bounding box is  
often cheap to calculate, it's not always the best solution to keep a  
cached boundary box. We should be able to make a choice per class  
basis, this should not be fixed for all classes by using a base class.

>
>> In the third option, it is possible to change the content of a  
>> node or segment through moveTo or other methods. The parent path  
>> object listens on changes and changes its state accordingly. This  
>> complicates things heavily as each child node or segment needs to  
>> keep a reference to its parent.
>
> No, that's how it works currently without parent keeping, just by  
> means of NSNotification.
>
> I am quite satifised with the current shape of things. What we  
> should remove is exposing low level data structes like  
> NSMutableArrays. This includes making CPoint and CSegment read/only.
>
Exposing implementation details is asking for troubles. Not only do  
you make it hard to change afterwards, it makes it impossible to keep  
an object consistent at all times. You end up doing checks all over  
the place, while the checks belong to the object. This has nothing to  
do with choices, this is good or bad design.
The choice to make is to make objects mutable or immutable. If the  
objects are mutable, the parent needs to be notified (parent keeping,  
observer pattern or NSNotification,...). I don't have a problem  
leaving the objects mutable, but in very controlled manner. Each  
object should be able to keep its state consistent whatever changes  
are made. This is the only way to keep the application in a  
consistent state as we move on and the application grows.

Kind regards,
Marc