On Sun, 28 Mar 2004 17:53:16 +0200, Manfred Nowak <svv1999@hotmail.com> wrote:

>Congratulations for this idea!
>
>Ben Hinkle wrote:
>
>> 3) for run-time optional parameters use varargs style ... or
>>    an array
>
>That is the second time, that there ssems to be a difference between compile time and runtime optionality.
>
>What is meant by that? I do not catch the difference.
>
>Please explain.

by "compile-time" I mean that the number of default arguments,
their types and their values are known when the code is
compiled. Every call to that function - even if the function
is overridden at run-time - will use those defaults and only
those defaults. That's why defaults and overriding is so
confusing - the defaults are determined at compile-time but
the actual function called is determined at run-time.
Wrapper functions actually are more flexible than C++ style
defaults since a subclass can override the wrapper (unless it
is marked "final") and specify a new default value.

by "run-time" I mean "not compile-time". :-)

-Ben

J Anderson wrote:

> Another thing I don't like about this solution is that if default values change you your function would stay the same.   The vendor can't go into your code to fix these things.  You would need to write (assuming u used 5 instead of 6):
> 
>    func( DefaultParam1, DefaultParam2, DefaultParam3, DefaultParam4,
>    DefaultParam5);
[...]

I do not understand why you have changed the fifth parameter to default. Now all parameters are the defaults? So the call could have an empty parameter list.

However, thanks for this argument.

Let me reason on it:

if a value for an optional parameter, that is a default valued parameter, is not supplied with the actuall call, then the current default value is imposed on that parameter. Because there is no further information, it stays unknown, whether

1) the writer of the call was simply not aware of the existence of that optional paramter xor

2) the writer of the call intentionally has not provided a value to that parameter, because he knew and was happy with the current default value, that would be imposed by omitting any value.

Now let us assume, that the default value to be imposed on that optional parameter changes with some reason.

Above case 1) would cause no harm.

But, arghhh, because of above case 2) every lexical occurence of that call must be checked and it must be decided whether case 1 or case 2 holds. In latter case, the old default value must be inserted into the code.


Now the other way round: if a value for an optional parameter, that is a default valued parameter, is supplied with the actuall call and is identical with the current default value, then, because there is no further information, it stays unknown, whether

3) the writer of the call was simply not aware of the precise value of the current default value of that optional paramter but wanted exactly this current default value (Note: this unawareness could have also resulted from the fact, that a previous change to the default value, established the value provided by the writer of the call to be the new default value by pure chance, xor

4) the writer of the call was only forced to provide the current default value because his intent was to provide an explicite value to an optional default valued parameter further to the right in the sequence of optional default valued parameters.

Now let us assume, that the default value to be imposed on that optional parameter changes with some reason.

Above case 3) would not cause any harm.

But, arghhh, because of case 4) every lexical occurrence of that call must be checked and it must be decided whether case 3) or case 4) holds. In latter case, the new default value must replace the old default value.


Solutions:

To avoid case 4:

a) sequences of optional parameters that are default valued must be forbidden  xor

b) introduction of a keyword "forced" that accompanies the provided current default value. In fact this keyword can replace the value at all, and therefore may be better expressed by "currentDefaultEvenIfChangedByANewVersion".

More?


To avoid case 2:

c) Ummm. Differentiating between two empty cases? I see no other solution than that to make one nonempty. What about the version dependent keyword "IAmHappyWithTheDefaultOfVersionXX_YY_ZZ"?

d) forbid optional default valued parameters to have no value, which is a contradiction. qed.

More?


Preliminary conclusion:

Optional default valued parameters cause some problems, when it cannot be guaranteed that the default value is unchangeable over time.

So long!

Ben Hinkle wrote:

> by "compile-time" I mean that the number of default arguments,
> their types and their values are known when the code is
> compiled. Every call to that function - even if the function
> is overridden at run-time - will use those defaults and only
> those defaults. That's why defaults and overriding is so
> confusing - the defaults are determined at compile-time but
> the actual function called is determined at run-time.
> Wrapper functions actually are more flexible than C++ style
> defaults since a subclass can override the wrapper (unless it
> is marked "final") and specify a new default value.
> 
> by "run-time" I mean "not compile-time". :-)

Thanks for this try of an explanation, but I still miss the point.

The end user, that who uses the final executable, and that is the only stage in which no compilation takes place, has influence only on the functions called by the input he provides. But that is typed input, so he has no influence on the function called, because he cannot change the type of his input.

Do you mean with "runtime" that time, when another programmer writes down some calls to a given function/struct/class? If so, then again all parameters are known at "compile-time", except he does never compile them. But then they are of no problem :-)

So do you mean with "compile-time" that time, when you introduce the functionality of your code to the compiler, knowing that it will be used by another programmer and do you call that usage "runtime"?

If so, then I assume, that my `(,,;;,)'- suggestion should replace your suggestion to use the unsafe varargs/... thingy.

So long!

On Mon, 29 Mar 2004 01:57:42 +0200, Manfred Nowak <svv1999@hotmail.com> wrote:

>Ben Hinkle wrote:
>
>> by "compile-time" I mean that the number of default arguments,
>> their types and their values are known when the code is
>> compiled. Every call to that function - even if the function
>> is overridden at run-time - will use those defaults and only
>> those defaults. That's why defaults and overriding is so
>> confusing - the defaults are determined at compile-time but
>> the actual function called is determined at run-time.
>> Wrapper functions actually are more flexible than C++ style
>> defaults since a subclass can override the wrapper (unless it
>> is marked "final") and specify a new default value.
>> 
>> by "run-time" I mean "not compile-time". :-)
>
>Thanks for this try of an explanation, but I still miss the point.

re-reading what I wrote I was being too vague. sorry for the confusion!

>The end user, that who uses the final executable, and that is the only stage in which no compilation takes place, has influence only on the functions called by the input he provides. But that is typed input, so he has no influence on the function called, because he cannot change the type of his input.

yeah - that's run-time.

>Do you mean with "runtime" that time, when another programmer writes down some calls to a given function/struct/class? If so, then again all parameters are known at "compile-time", except he does never compile them. But then they are of no problem :-)

Let me give an example of what I meant.
Suppose there was a function "fcn" with signature
  void fcn(...)
Suppose the variable "user" has a 0 or 1 depending on something
the user typed. Then the code

  if (user)
     fcn(0,"hello",33.3,"some random types");
  else
     fcn("some", "totally different", "data");

then the actual number and types of the inputs passed to fcn is
determined at run-time. You are right that we could enumerate
all the possible combinations at compile time through some static
analysis of the code, but I was just referring to the fact that
you can't tell from looking at the signature of fcn. I was being
vague in how I was using those terms. That vagueness comes out
also in my explanation about wrappers since subclasses can
override the wrapper and redefine the defaults. I just added
the "compile time" and "run time" to distinguish what the function
knows when about what is on the stack (sounds like Watergate:
what did the function know and when did it know it?)

>So do you mean with "compile-time" that time, when you introduce the functionality of your code to the compiler, knowing that it will be used by another programmer and do you call that usage "runtime"?
>
>If so, then I assume, that my `(,,;;,)'- suggestion should replace your suggestion to use the unsafe varargs/... thingy.

I admit I was confused by your proposal. I'll look at it again.

>
>So long!