[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