Delphi, methods and default values.
Being somewhat unique in methods declaration for the classes, Delphi requires you to have proper method parameters declaration, but:
- You do not have to have any default values for the parameters being propagated into implementation section for the method.
- And you do not have to have any parameters being specified in implementation section at all.
- If your class implements an interface, then while order and type of parameters remain unchanged for the interface method implemented, compiler would not not even detect it.
- When declaring the method and then using code complete feature of the IDE, stub generated would have all parameters but no default values.
- Declaration of the parameters could be “optimized” by changing the way they are grouped if they are of the same type. And sync is not enforced between declaration and implementation.
Convenient. Nice. Easy.
Again, it is convenient since it does not force you to propagate your changes between two if you are to change your default values.
Is default value good or evil?
Well, Microsoft saying it is specific to an implementation of the language (C#) and suggests to use overloads instead. Yes, it can be done, but defaults were introduced for a reason. And, in fact, some compilers, even Delphi, would be confused with overloaded declaration if there is a slight chance of mixing two.
Back in 2005, dflat wrote:
1. A bit tedious to call, because even if you don’t put any actual parameters, you have to write down all the types.
1. Unlike C++ default params, this allows all combinations
2. No signature conflict or ambiguity. The whole signature is matched when calling a method with default parameters, because type must be specified if the parameter is missing.
3. No run-time overhead, because everything can be determined at compile time.
Feasibility. I don’t think it’s difficult to implement (in later version of C#) because:
1. No additional key word is introduced. “default” is already a key word in C#
2. No ambiguity. It doesn’t conflict with any existing C# language semantics
I may sound old fashioned, but I prefer propagate declaration of the method into implementation, because:
- if for any reason you have to move things around the code, it is convenient to be able grab implemtation of the methoid and easily reusing it in declaration of another class.
- while reading the code, be able to see exact calling contract for the function you are investigating without a need to jump between declaration and implemtation.
- also having it in sync, force you to review the code when any default values are changed and if you are using something like XMLDoc/JavaDoc/PasDoc, compiler will force you review your method documentation.
Yes, it “breaks” a “Dry code” principle. But it is not more of “dryness” with that approach then not having any parameters in implemtation section of the method. And while it “polutes” the code, it adds more self-documenting and readability to it.
What are yours points “for” and “against” default parameters and use of them?