[fpc-pascal] A better way?

Michael Van Canneyt michael at freepascal.org
Thu Apr 14 16:25:31 CEST 2016

On Thu, 14 Apr 2016, Ryan Joseph wrote:

>> On Apr 14, 2016, at 6:09 PM, Michael Van Canneyt <michael at 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.


More information about the fpc-pascal mailing list