[fpc-pascal] with in classes/records

[Martin]

On 03/09/2018 17:00, Ryan Joseph wrote:
>
>> On Sep 3, 2018, at 9:17 PM, Martin <fpc at mfriebe.de> wrote:
>>
>> You.f.Free;
>> will always work, it is not ambiguous.
>>
>> You.Free;
>> depends on no method Free being declared on the class of You, or any of its base classes, or any other default class (if more than one is allowed) that would be searched at higher priority.
> sorry I just wanted to add, in the case of You.Free where there is an naming conflicting in super classes (Free in TObject of 3 classes) the rule is:
>
> 1) *always* use the base classes implementation regardless of order.
That is exactly by example. Base class takes priority over default property.

So you implement a "property f; default". At this time the base does not 
have a Free method, so you write You.Free. That works.

Except at some later time, you or somebody else adds a Free method to 
the base class. Then You.Free breaks.

Imagine the base class is in a package, used by many projects, then at 
the time of adding to the base class, you can not check all the projects 
(especially if the base package is published and used by others too).

> 2) if you want an implementation other than the base class you must explicitly call on that field.
So given the above, you can never safely use the shortcut, unless there 
is no base class/inheritance.

But even then, if more than one default was allowed: The 2nd default 
would not be safe, because the same method could be added to the first 
default. Or to any default that the first default has, since this can be 
nested indefinitely.

Btw, similar conflicts sometimes occur, if you add units to your project.
Given that there can be many levels of inheritance, or nested defaults, 
while on the other hands units do not have nesting (symbols from units 
used by a used unit, are not visible), the likelihood of conflicts with 
default, is far more likely that with using units.

-------------
If all you look for is an easy way to simulate automatic memory 
management, then it would be best to do so avoiding the many pitfalls of 
multiple inheritance (though the above is only a subset of multi 
inheritance)
Sorry I have no alternative proposal.