[fpc-devel] [] property overloads

[Ondrej Pokorny]

On 01.07.2019 18:21, Michael Van Canneyt wrote:
> On Mon, 1 Jul 2019, Ondrej Pokorny wrote:
>
>> On 01.07.2019 15:57, Ryan Joseph wrote:
>>> Yes, I’ve made a patch to allow overriding the actual property 
>> (https://bugs.freepascal.org/view.php?id=35772).
>>
>> Very good! Just a short question: does your solution allow one 
>> overload without array indexes? It is very useful as a for-in 
>> enumerator of the array property:
>>
>>   TTest = class
>>   public
>>     // ...
>>     property StringArray[Index: Integer]: string read GetString;
>>     property StringArray: TTestObjectEnumerator read GetString;
>>   end;
>
> I really don't think this should be allowed. You can perfectly do
>
> property EnumStringArray: TTestObjectEnumerator read GetString;
>
> For S in Mytest.EnumStringArray
>
> Typing this extra letters is not going to hurt.
>
> Your proposal violates the rule that the resulting type of an 
> expression must be known when evaluating it.
>
> with
>   Mytest.StringArray
> it is not clear what the Mytest.StringArray should evaluate to.
>
> It can be 2 things:
>
> - An array, in which case an index is needed.
> - An enumerator.

 From the above example "Mytest.StringArray" can only evaluate to 
TTestObjectEnumerator. Nothing else.


>
> The compiler does not know what to choose, except by looking at the 
> context and that is definitely not OK.

Yes, you are right that there can be some clashes when finding the right 
overloads - the compiler needs some rules for resolving them. But that 
has always been like this with overloads...

When the rules are there, the proposal above is not different to any 
other type of overload.

A problematic example would be e.g.:
     property StringArray[Index: Integer]: string read GetString;
     property StringArray: TStringArray read GetString;
- but again, this can be solved with compiler rules.

Ondrej