On Sat, 2004-02-07 at 20:11, Wade Bowmer wrote: > ... except that if it is evaluated once, then the runtime knows with 100% > certainty whether it has a simple scalar or a structure. Then it's just > like calling copy(). But this is superseded by discussion below.
But doing so would require that it be evaluated whether or not the default value is ever needed - or even whether or not the procedure is ever called at all! This strikes me as not being a good idea - since this might cause various mysterious side effects and violates the 'minimum cost' principle [or whatever it's called: one shouldn't have to pay for things that aren't used] - the reason I didn't consider it further. > >2 is the same as 1a, so that leaves 1b and 1c as possibilities. > > Actually, option 1a excludes static variables whilst option 2 does not. Typo on my part (my typing is going to the dogs...). That was supposed to say "2 is the same as 1c", which is why I could then ignore 2 and use only 1b and 1c. > .... [snip] .... > >My preference is that the evaluation order on a procedure call would be: > > > > evaluate parameter type and default value expressions, if any > > evaluate initial clauses, if any, on first call > > evaluate local variable initializations, if any > > evaluate procedure body > > > >i.e. 1b above. > > I prefer the default value expressions to be after the initial clause. Why? > Because this would mirror how default variables are manually handled. (This > would be your option 2.) Also, the initial section is executed just once > wheras the default expression should be called every time a parameter needs > defaulting when the procedure is called. It also provides a way for dynamic > defaults, which is elegantly Iconish. :-) I went around on this a few times and can see it either way. It's a trade-off: evaluating the default parameters first provides away for dynamic static variable initializations(!). So it's really a matter of which is more useful. In the end I picked the above order because of its 'naturalness' - expressions are evaluated in the order one would encounter them while reading the program. I'm not strong on it however, as I think the difference in order here is pretty esoteric [i.e. rarely likely to matter in practice]. Either of those two approaches would be fine with me - I think either can provide the functionality of the other, just at the cost of a bit more code (Love to see a counter-example!). Is anyone besides Wade and me finding this discussion interesting? If not, perhaps we (Wade and I) should take it off-line. (Uh, is anyone actually planning on implementing this? If not, then Wade and I should *definitely* take it off line.) -- Steve Wampler <[EMAIL PROTECTED]> ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
