[DGD]varargs void foo(object bar)

[Felix A. Croes]

Frank Schmidt <franks at colargol.tihlde.hist.no> wrote:

>[...]
> My problem: varargs with objects as parameters, and dealing with default
> values for objects.
>
> Example: varargs void foo(object bar)
>
> Now the call to this function can happen in four different scenarios:
> 1) foo()
> 2) foo(beer) /* when <beer> != 0 */
> 3) foo(beer) /* when <beer> == 0 */
> 4) foo(0)

Note that 3) and 4) are always identical, from the called function's
point of view.  Unlike MudOS, DGD has no way to distinguish a
destructed object value from a zero value.


> The problem in this example is that there is absolutely NO way in foo()
> to detect that <bar> is a default parameter set-to-0 in 1). E.g.
> according to the tracelist, scenario 1), 3) and 4) are identical.
>
> This makes functions with default arguments ambigous with functions called
> with object variables set to 0, or just the value 0. This is bad
> when you both want to trap situations with object-values of 0, AND handle
> default values for vararg object-parameters. And there is necessity of
> trapping such situations since the values of object variables may change
> to 0 without any warning to the current LPC scope.
>
> Should I change all my "varargs foo(object,)"-alike-functions to
> "foo(object,)"? Or should DGD change in handling of arguments, e.g. show
> how many arguments was REALLY supplied in the tracelist?

If I understand you correctly, you want to let call_trace() provide
the caller's view rather than the called function's view.  That's an
interesting solution to the varargs problem, but I'm not convinced it
is the best one.  I am considering changing the way varargs works,
though I haven't yet decided on anything specific.


> The latter seems a better solution, though I don't know if it could break
> with existing code. Remember, that there are lots of times you want to
> supply "varargs". For example  to a function containing several parameters
> of mixed types, herein also objects. Then there will be no knowing what is
> default, and what is not. 
>
> Hmm, this problem (w/solution) also extends to all types it seems. It's
> just that you Very rarely have use for a default parameter of
> anything != 0.
>
>
> DGD is a great piece of work btw. My ultimate dream would be LPC
> displacing Java.

Both LPC and Java have their strengths and weaknesses.  The greatest
advantage that LPC has over Java may be multiple inheritance.

Regards,
Dworkin