Matt Emson wrote:
I would also agree. I used to use Interfaces or raise shared
classes/declarations to a new unit both could use to overcome this
issue myself. But I remember the Be GUI porters having loads of issues
mimicing the Be API header structure because there were so many
forward class declarations in the C++. It was impossible to do a unit
to header file match because circular dependencies crept up at almost
every turn. Without direct matching of header and unit names, the Be
API documentation became hard to use. I don't know if they ever
solved it, maybe if Olivier is still about, he can chime in?
I would think any time you have two objects that need bidirectional
access of any sort that you would need to define an connector object to
make this link, so the data or functions that needs to be shared between
the two don't reside in either object, but in the connector object.
Because if the data or functions are needed by both, they really aren't
a part of either, it is its own thing and should have its own object.
Or maybe I'm not seeing the problem properly. I just know that the few
times I've hit on the circular unit problem where A needed to know about
B, and B needed to know about A, that's how I've solved it, by making
another unit C with the parts that needed access and pointing both A and
B to that new unit. Maybe my problems were trivial, though. I'm
certainly no OOP expert.
Jeff.
--
I haven't smoked for 3 years, 4 months and 2 weeks, saving $5,572.94 and
not smoking 37,152.94 cigarettes.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
