Re: [Rapideuphoria-develop] UDT Cleanup

[Jeremy C. <je...@co...>]

Quoting Matt Lewis <mat...@gm...>:
> On Mon, Mar 16, 2009 at 9:37 PM, Derek Parnell <ddp...@bi...> wrote:
> >
> > The concept isn't temporary and neither should the syntax. The bigger
> > picture should include how to cater for future OO functionality as well.
> > UDT cleanups are a form of OO functionality in my book.
> 
> Is there room for both approaches?

I not only think there is room, I think it is required! Euphoria should not
require or force OO onto the users. Many applications can be happily, and
better made as procedural. Procedural applications can still use and should
be able to use UDT cleanups.

> Perhaps the first step is to
> introduce something that's still more procedural in nature.

I don't think it is a *first* step. I think it is a correct step and a
lasting step. As said in a previous email, UDT cleanups will be use
long, long after OO is introduced, and will be used correctly. A type
should not have to be an object just to get cleaned up correctly.

We will be making a big mistake not implementing UDT cleanup and
requiring the user to make everything an Object just for the sake
of releasing memory.

> What if
> we take away the UDT-ness of this, and simply consider adding a
> generic ability to specify a cleanup routine for an object?  This
> doesn't preclude a future OO way of doing this that's more automatic
> (using actual constructors and destructors).
> 
> Thinking a bit about this, we probably need at least two things to
> make this work:
> 
> 1. A way to associate a cleanup routine with an object.
> 2. A way to disassociate a cleanup routine with an object, or a
> generic way to call a cleanup routine.

I'm not sure we need #2, it sounds like it will just make it's internal
development more difficult, introduce further syntax for the user to
deal with and be of no value?

> My thinking on #2 is that users may want to call the cleanup routine
> prior to it's final deref.  If the object still exists, the cleanup
> could be called multiple times (if not disassociated), which could
> easily lead to errors.  I think the best way would be to provide a
> generic way to call the cleanup routine, since the backend could
> handle the disassociation.
> 

Let's say that the cleanup routine for map is indeed called delete, as
it is now. What's wrong with doing this:

public procedure delete(object o)
    if atom(o) and o = 0 then
        return -- This map has already been deleted
    end if

    -- cleanup
end procedure
register_cleanup(map, routine_id("delete"))

Now the user has one additional function to deal with, can call delete
if he/she wants. The above checking is pretty standard in most languages,
even in OO syntax.

Jeremy