On Thu, Mar 19, 2009 at 9:57 PM, Derek Parnell <ddparnell@...> wrote:
> On Fri, 20 Mar 2009 12:50:52 +1100, Jeremy Cowgar <jeremy@...>
>> Do you think Matt's syntax is conflicting with a future OO syntax? I see
>> it as pretty simple, procedural routines having nothing to do with OO?
> So do I and that is my concern.
I'm not quite sure I understand your concern. Thinking out loud...
When we implement OO, we're going to need to have a way to construct
and delete an Object (to differentiate from normal euphoria objects).
Your proposal seems to merge OO and UDTs. There will probably need to
be a convention for defining the OO-based destructor. You've chosen
to have a method named delete.
Also, based on your proposal, I'm not sure whether the destructor
would be triggered by garbage collection, to allow for RAII style
programming. It very definitely seems to allow (if not encourage)
users to directly call the specific destructor for an object. One
thing that I did not see in the proposal was a way to 'flag' the
object as already having gone through the destructor.
There are other OO issues that we'll have to decide eventually, such
as inheritance. I'm not sure how your proposal fits into that
specifically, or for associating multiple destructors with an object.
I'll compare to C++ here (in part because it's what I'm familiar with,
but I think it illustrates the issue well).
A C++ class can define a destructor. Subclasses may have their own
destructors. Deletion is done with the delete operator, which
automatically calls the destructors in order, from the most super to
the most sub class. Every single object is cleaned up using that same
mechanism (OK, there are exceptions, such as for wxWidgets, where
you're supposed to call the object's destroy method, but that's an
implementation detail to ensure that the widget clears out all of its
messages), so you never have to know anything about an object in order
to delete it.
Of course, that's for objects created on the heap, as opposed to the
stack, which are automatically garbage collected when the function
returns. But there are other constructs, such as auto_ptr, and boost
provides a reference counting pointer that handles the garbage
collection for you. These would be analogous to having the backend
call the appropriate cleanup routines just before the memory is freed
after the reference count on the object drops to zero.
Sorry, you probably already knew this stuff, but I just want to make
sure we're on the same page, or that you at least see my thought
I agree that it would be bad to have multiple ways to delete an
object. I'm proposing possibly having multiple ways to tell the back
end how to clean up after the object, but a single [explicit] way to
tell it to do so. In fact, delete_routine() could be used when we get
to OO. I don't think we should, but we could. But I think that "pure
procedural" code should have access to the cleanup mechanism, too.
I suspect that forcing OO paradigms into this, which isn't an OO topic
would be negatively received. It also reminds me of a Java-like
philosophy where everything must be a class. It just gets bulky after
a while. Consider the following:
constant FREE_RID = routine_id("free")
public function auto_ptr( integer size )
atom ptr = allocate( size )
return delete_routine( size, FREE_RID )
Now we have a pointer that is automatically freed when you're done
using it, and it doesn't create any additional type checking. It's
very lightweight. Two equivalent ways to use it:
atom ptr = auto_ptr( 4 )
-- do stuff
delete( ptr ) -- calls free(ptr) and clears its destructor
atom ptr = auto_ptr( 4 )
-- do stuff
-- ptr's ref count drops to zero, and free(ptr) is called
>> Maybe the word delete() might conflict with delete(obj). I'm not sure
>> how our OO syntax is going to look. I don't see a problem with sharing
>> the word delete between OO and UDT cleanup, if we would even choose that
>> for the OO system.
> I guess time will tell then.
Again, I'd recommend that we use a built in delete(obj) for anything
cleanup related, and let the back end figure out what needs to be