On Thu, 14 Apr 2016, Ryan Joseph wrote:
On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt <mich...@freepascal.org> wrote:
So, put bluntly, you are unwilling to do things properly, and then complain
that the
language does not allow you to do this easily enough ?
No, you need to do things properly.
I thought that was probably the answer I’d get but I wanted to ask anyways. I
get there’s a Pascal way but it’s making the job more difficult then it should
be so I opt for the quick and easy hack. Maybe it’s bad form but at the end of
the day I just want to make things work and get the job done instead of getting
held up on small details.
The interface was probably over complicating the example actually because
the true problem is having this pattern of a parent->child relationship
where both classes need to know about each other to some extent but
putting them in the same unit causes clutter and pollution in other units
namespaces. In this example it’s likely that many other units use TClassB
and it’s not exclusive to TClassA so putting them in the same unit doesn’t
make sense.
It certainly does make sense, if they are so intertwined.
This is not Java where you must put all classes in a single separate file.
If classes are so intertwined that they need detailed knowledge of each
other's property, put them in 1 unit.
It is as simple as that.
That would be a solution but it’s not very pretty. Having 2 classes in the
same unit that need knowledge of each other but are still mutually
exclusive is also bad design in my opinion.
Each is entitled to his opinion.
Practical people use the tools at their disposal how they are meant to use.
In this case the tool tells you that the 2 classes should be in 1 unit.
So, you can waste your time looking for a way out, or just use the tool as
it is meant.
Michael.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
