🚀 go-pugleaf

In article <1993Jan23.081616.29910@us-es.sel.de> reindorf@us-es.sel.de (Charles Reindorf) writes:
>|> Actually, you could "new" them.  Just allocate the functions on the
>|> "heap", and free them when you are done.  Or, we could take a flying
>|> leap at the slippery slope and add garbage collection.
>
>Again, as you say, you have to free them "when you are done", but in 
>this situation, there is no natural idea of "when you are done". In 
>fact, whereas the natural lifetime of a nested function is until the 
>containing function completes, the natural lifetime of a bound function 
>is until the destruction of the object to which it is bound. How do you 
>ensure that whenever an object dies, that bound function trampolenes 
>which *might* have been generated for it are deleted? 

	The compiler doesn't bother to try. Leave it up to the programmer.
Nothing new here :-) After all, just killing the trampoline doesn't stop 
you calling it through the pointer you still have lying around.

>I can see no way that the solution can be implemented in a way that 
>doen't impact the normal performance of the system. 

	Just leave deletion of the trampoline up to the programmer
like all other dynamically created objects.

>
>None of this detracts from the fact that *nested* functions *can* be 
>implemented without impacting on the normal performance of the system, 
>and without requiring any special new constructs in the language (more 
>a relaxation of a rule). What's more, they are extremely valid for 
>situations where iterators are used for many general call-back 
>mechanisms which are considerably more awkward (or unsafe) when done 
>using one of the manual alternatives.

	Yes, callbacks are a compelling argument. Must
remember this for the proposal.
>
>Moreover, if nested functions are implemented, they imply an easy 
>manual solution to many cases where bound member functions might have 
>been required. Other cases where bound member functions might be 
>required can surely be solved through abstract base classes and in some 
>cases MI.

	But the bound members can be had easily
IF we have trampolines for the nested functions, without
any more loss of safety than you get with ordinary pointers.
(Although the effects of executing non-existant code,
or existant code for non-existant objects will be nasty,
if you dont like it --- dont use it)

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;------ SCIENTIFIC AND ENGINEERING SOFTWARE ---ph:  2 799 8223 --------