[fpc-devel] New feature discussion: for-in loop
Marc Weustink
marc.weustink at cuperus.nl
Wed Oct 21 16:52:23 CEST 2009
Paul Ishenin wrote:
> Michael Van Canneyt wrote:
>> My only worry now is to make sure that if they are implemented, that
>> we make the design as clean as possible: e.g. No hardcoded
>> dependencies on class or
>> interface names.
> We need to count the pros and contras first regards hardcoded names and
> maybe 'hard coded' code. For example for me the hardcoded 'Result'
> identifier for all functions is a big advantage. But you are still using
> the function names to set the result values I suppose. So during this
> clean design designing we need to find a compromise between 2 approaches.
Having an implicit result variable or Self variable is something
completely different than having the knowledge of a class and scanning
its function names and assign a function to a certain name.
The first is defined by the compiler, the second is declared by you, the
code writer.
> for example, would you argue if iterator will be any container type:
> object/class with the next declaration:
>
> TMyIterator = object
> public
> function StepNext: Boolean;
> property TheCurrentValue: Integer;
>
> iterator MoveNext = StepNext;
> iterator Current = TheCurrentValue;
> end;
>
> When 'iterator MoveNext' or 'iterator Current' are not defined then
> compiler uses default hardcoded identifiers 'MoveNext' and 'Current'.
>
> This is very like to how you can bind interface methods to the class
> methods if they are differ.
Again, here you mix names and functionality.
Compare it to a default propery, you declare it as:
property Foo[index:integer]: String read GetFoo; default;
and not as
property Default[index:integer]: String read GetFoo;
Marc
More information about the fpc-devel
mailing list