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