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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
