On Wed, 21 Oct 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.
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.
Hm. I like this direction of thinking, yes...
What about
function StepNext: Boolean; iterator 'movenext';
property TheCurrentValue: Integer; iterator 'current';
or better yet, because it is more strict:
function StepNext: Boolean; iterator nextvalue;
property TheCurrentValue: Integer; iterator currentvalue;
In this way, it's more like some extra modifiers.
(so like safecall, default, stored and whatnot)
It just adds some modifiers, and we're free of hard-coded names.
With one of these I could live :-)
Michael.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
