Frank Heckenbach wrote:
Scott Moore wrote:
For example, you can implement C++ style "default parameters" by using overloads ability to match parameter counts.
FWIW, I'll also consider default parameters when dealing with overlaods. They're no less type-strict, and may be more comfortable to use in some situations.
No longer any need to coin various names for WINAPI functions and document them. And the result, IMHO is cleaner. Instead of the C call:
someapifunc(&q, NULL);
I have:
someapifunc(q);
And a simple rule: if the parameter does not exist, leave it out !
Good example indeed. But it is a case where default parameters may be even better suited -- if there are n such parameters, with overloads you'll need 2^n routines.
In theory, yes. For practical matters, the number never rises above 8 (three optional parameters). However, I don't have any fundamental objection to default parameters beyond degradation in source transparency, which I agree overloading also affects. By this I define source transparency is making it obvious to the reader of a program exactly what routine will be executed for any particular call, and how that call will appear.
Typically I have seen this kind of interfacing in other Pascals by allowing for an operator such as &x, that takes the address of any variable, then allowing the user to stuff any address into a pointer parameter. This "solves" the problem, but imports a huge type safety problem from C into Pascal, namely the ability to arbitrarily manipulate addresses.
Taking the address doesn't imply doing address arithmetic. As a thought experiment, just imagine that every global and local variable is internally allocated via `New', every normal use of the variable uses the-internal-pointer^, and `&x' (or `@x' as in BP and GPC) yields this internal pointer. This is no less type-safe (as I just proved, as I described it in standard Pascal terms). Of course, most of the dialects that habe `&'/`@' also allow for address arithmetic which is not so harmless.
I don't disagree. I just think that Pascal has its methods for handling program objects by their address (VAR parameters) and C has its, and I am not wild about mixing them.
The number of traditional Pascal typing difficulties templates solve is stunning. Remember the common complaint about having to have several different procedures or functions to get around fixed length strings ? That problem no longer applies. A collection of string functions can be written for fixed length strings that adapt to any string type.
But in your scheme, each invocation would create a new copy of the routine, which is not really nice WRT compile-time and binary-size. I think I prefer schema parameters for this case which are also type-safe.
Schemas require run time templates, which mean that you trade code space (template style) for runtime efficiency. Schemas are largely the reason I decided not to implement the ISO extended Pascal standard. They largely import type checking from compile time to runtime. I had a conversation with John Reagan (one of the authors and chief proponents of the standard), where he related to me that the makers of the standard believed that compile time for runtime trade offs were acceptable in a day and age where "computers were more powerfully than what is required".
Without (hopefully) getting into a tirade on the subject, I fundamentally oppose that. Making Pascal increasingly rely on runtime work is a recipe for having Pascal fall behind other languages in runtime capability, whereas at present Pascal is at par, or even excels because of the better information Pascal delivers to the compiler. Schemas fundamentally (and permanently) degrade Pascals runtime performance. Further, type safety is an attribute independent of implementation. C has degraded the type status of type safety and type safe languages. Java has somewhat restored it, but has also created in programmers minds the idea that type safety must be paid for with degraded runtime performance. The trap of having C/C++ be perceived as "industrial strength" languages with Pascal, Java and other languages as lower performing "trade off" languages is all to apparent, and does not need the help of fundamental runtime trade-offs like schemas.
Finally, I debate that schemas are necessary for Pascal. The prime problem schemas are used for is to create dynamic length arrays. Indeed, that was the entire reason schemas were considered for creation in the first place. Instead, IP Pascal uses a completely type safe method advocated by N. Wirth himself in Oberon, which I further developed so that it is completely upward and downward compatible with the rules of fixed length arrays in standard Pascal. Thus, IP Pascal has dynamic length arrays, and fixed length arrays can be passed to a dynamic length parameter, etc. The method used in IP Pascal requires a fraction of the work of schemas, both from the point of view of the compiler writer, and also runtime checking, but accomplishes all of the aims of schemas with respect to dynamic arrays. So I submit that schemas were not a required price to pay to enhance standard based Pascal.
Templates (as in source time) certainly make it easier to generate multiple runtime routines, but this is very much in control of the programmer. Certainly, one would not want to use templates as a replacement for dynamic arrays, which is why IP Pascal implements same. For the situations templates are most useful, the alternative to a template would require multiple library variants in any case, each hand written by the programmer, perhaps with cut and paste. In fact, in virtually any case where a routine is created by cut and paste methods (i.e., a copy with trivial changes due to typing limitations), templates are likely to be a better implementation.
Ok, that might have been a tirade :-)
How about the ability to write a set of general purpose list manipulators ? In standard Pascal you have to rewrite a set of insert, delete, sort, etc routines to fit each type of dynamic list. With templates, you can write a series of routines that only rely on the common features of a list, such as each entry having a ".next" field, and a ".data" field.
Yes, here templates would come handy.
Frank