Euphoria Programming Language

Quoting Matt Lewis <matthewwalkerlewis@...>:
> I've implemented some backend code to call a user defined cleanup
> routine.  I haven't hooked it up to the front end, though.  Basically,
> I wrote a custom shared library that I could call to hand jam in the
> structure, in order to test out the backend part.  I expect to
> associate a cleanup structure with any UDT that has one, so that
> there's no dynamic allocation for those, unlike with backend cleanup
> structures.
> 
> We just need to come up with the syntax.  I was thinking perhaps
> something a little different:
> 
> release my_type with routine_name
> 
> release my_obj as my_type
> 
> These are a bit of a departure, of course...
> 

Hm. They are a bit different than what we are use to seeing in the middle
Euphoria code. They are similar to with xyz ... type code. Maybe it's
not that far of a departure.

So, I understand release my_type with routine_name, but what is the
release my_obj as my_type for? Just another way of saying it? If so,
I think the first (with) is much clearer.

Here is another that we have talked about as well:

register_cleanup(my_type, routine_id("routine_name"))

that is a little more euphorian. I am thinking:

=======================================

public type my_type(object o)
    return sequence(o)
end type

procedure my_type_cleanup(object o)
    -- cleanup
end procedure

register_cleanup(my_type, routine_id("routine_name"))

=======================================

vs. the apperance of:

=======================================

public type my_type(object o)
    return sequence(o)
end type

procedure my_type_cleanup(object o)
    -- cleanup
end procedure

release my_type with my_type_cleanup

=======================================

I'm not dead set on either, just giving other examples.

Jeremy

On Tue, 17 Mar 2009 08:50:42 +1100, Matt Lewis  
<matthewwalkerlewis@...> wrote:

> I've implemented some backend code to call a user defined cleanup
> routine.  I haven't hooked it up to the front end, though.  Basically,
> I wrote a custom shared library that I could call to hand jam in the
> structure, in order to test out the backend part.  I expect to
> associate a cleanup structure with any UDT that has one, so that
> there's no dynamic allocation for those, unlike with backend cleanup
> structures.
>
> We just need to come up with the syntax.  I was thinking perhaps
> something a little different:
>
> release my_type with routine_name
>
> release my_obj as my_type

Hmmm... I was thinking of a more generic approach with the long term view  
of supporting general type-methods.

type m_type(object x)

    . . . standard code to validate assignments ...

    method dtor do
       . . . code for releasing resources.
       . . . Either called explicitly or when last reference is removed.
    end method

    method ctor(args...) do
       . . . code for initializing
    end method


end type

my_type X = my_type(args ...)  -- ctor method used.
my_type Y = abc                -- assignent checking done.

Y.dtor()  -- Destructor explicitly called on Y's data.


-- 
Derek Parnell
Melbourne Australia
skype:derek.j.parnell

On Mon, Mar 16, 2009 at 7:20 PM, Derek Parnell <ddparnell@...> wrote:
> On Tue, 17 Mar 2009 08:50:42 +1100, Matt Lewis
>
> Hmmm... I was thinking of a more generic approach with the long term view
> of supporting general type-methods.

See, I knew if I proposed something weird, I'd get some opinions quickly. :)

> type m_type(object x)
>
>    . . . standard code to validate assignments ...
>
>    method dtor do
>       . . . code for releasing resources.
>       . . . Either called explicitly or when last reference is removed.
>    end method
>
>    method ctor(args...) do
>       . . . code for initializing
>    end method
>
>
> end type
>
> my_type X = my_type(args ...)  -- ctor method used.

How would we do an explicit type check?  I suppose if we have a
constructor like this, we can apply the destructor to the object.

> my_type Y = abc                -- assignent checking done.
>
> Y.dtor()  -- Destructor explicitly called on Y's data.

Presumably, Y is still a valid euphoria object at this point, except
that any external resources acquired would be released.

What if we used 'new' and 'delete' instead of ctor and dtor (and do we
need the 'method' declaration?  So:

type my_type(object x )
   -- ...validation
  return something

new do

end new

delete do

end delete

end type
my_type X = my_type.new(args...)
if my_type( X ) then ... end if -- explicit type check

Also, do we want the OO-style destructor call: X.delete() , or
my_type.delete( X )?  The latter is still OO-like, though it's more
like calling a static method.

-- 
Matt Lewis

> Hmmm... I was thinking of a more generic approach with the long term view  
> of supporting general type-methods.
> 
> type m_type(object x)
> 
>     . . . standard code to validate assignments ...
> 
>     method dtor do
>        . . . code for releasing resources.
>        . . . Either called explicitly or when last reference is removed.
>     end method
> 
>     method ctor(args...) do
>        . . . code for initializing
>     end method
> 
> 
> end type
> 
> my_type X = my_type(args ...)  -- ctor method used.
> my_type Y = abc                -- assignent checking done.
> 
> Y.dtor()  -- Destructor explicitly called on Y's data.

I don't think something this complex is needed. The above looks like
make-shift, but not really, OO. Items such as above should wait until
we get OO in Euphoria.

For now, all we need is the ability to clean up UDT's and we will always
need that, even after OO is introduced. So, it's not as though it's
a temporary crutch, it's a very valuable addition, just the simple
syntax outlined by Matt.

Jeremy

On Mon, Mar 16, 2009 at 8:30 PM, Jeremy Cowgar <jeremy@...> wrote:
>
> I don't think something this complex is needed. The above looks like
> make-shift, but not really, OO. Items such as above should wait until
> we get OO in Euphoria.
>
> For now, all we need is the ability to clean up UDT's and we will always
> need that, even after OO is introduced. So, it's not as though it's
> a temporary crutch, it's a very valuable addition, just the simple
> syntax outlined by Matt.

At a minimum, we need a way to associate an object with a routine for
cleanup.  Also, it must be either a double or a sequence.  Integers
won't work, for obvious reasons.  If we use a built-in function, we
can promote integers to doubles.

-- map.e

public procedure free( map m )
   -- .. free it up
end procedure

public function new()
    map m = ...
    m = cleanup( free )
    return m
end function

-- 
Matt Lewis

On Tue, 17 Mar 2009 10:38:52 +1100, Matt Lewis  
<matthewwalkerlewis@...> wrote:

> On Mon, Mar 16, 2009 at 7:20 PM, Derek Parnell <ddparnell@...>  
> wrote:
>> Hmmm... I was thinking of a more generic approach with the long term  
>> view
>> of supporting general type-methods.
>>
>> type m_type(object x)
>>
>>    . . . standard code to validate assignments ...
>>
>>    method dtor do
>>       . . . code for releasing resources.
>>       . . . Either called explicitly or when last reference is removed.
>>    end method
>>
>>    method ctor(args...) do
>>       . . . code for initializing
>>    end method
>>
>>
>> end type
>>
>> my_type X = my_type(args ...)  -- ctor method used.

> How would we do an explicit type check?  I suppose if we have a
> constructor like this, we can apply the destructor to the object.

Good point. This is a future item anyway, but the concept of a constructor  
should be catered for and not locked out.


>> my_type Y = abc                -- assignent checking done.
>>
>> Y.dtor()  -- Destructor explicitly called on Y's data.
>
> Presumably, Y is still a valid euphoria object at this point, except
> that any external resources acquired would be released.

I was thinking that after the dtor was used that Y would be set to  
UNASSIGNED.

> What if we used 'new' and 'delete' instead of ctor and dtor (and do we
> need the 'method' declaration?  So:
>
> type my_type(object x )
>    -- ...validation
>   return something
>
> new do
>
> end new
>
> delete do
>
> end delete
>
> end type
> my_type X = my_type.new(args...)
> if my_type( X ) then ... end if -- explicit type check

I chose 'ctor' and 'dtor' because they are unlikely to be already used in  
programs whereas 'new' and 'delete' are already in use in other contexts.

I think we need the 'method' or similar keyword so we can IN FUTURE allow  
the coder to name additional type-methods.

So in general the syntax would be along the lines ...

    method <name> [(args)] do
     . . .
    end method

The 'do' is required because '(args)' could be omitted. The 'ctor/dtor'  
names would be reserved I guess.

> Also, do we want the OO-style destructor call: X.delete() , or
> my_type.delete( X )?  The latter is still OO-like, though it's more
> like calling a static method.

In future we a likely to have object method calls and not just static  
methods.

I'm trying to get the big picture here so that any syntax that gets put  
into 4.0 won't need changing in 4.1. That's one reason why I'm a bit  
hesitant to rush UDT cleanups before we really think through all the  
issues.


-- 
Derek Parnell
Melbourne Australia
skype:derek.j.parnell

On Tue, 17 Mar 2009 11:30:31 +1100, Jeremy Cowgar <jeremy@...>  
wrote:

>> Hmmm... I was thinking of a more generic approach with the long term  
>> view
>> of supporting general type-methods.
>>
>> type m_type(object x)
>>
>>     . . . standard code to validate assignments ...
>>
>>     method dtor do
>>        . . . code for releasing resources.
>>        . . . Either called explicitly or when last reference is removed.
>>     end method
>>
>>     method ctor(args...) do
>>        . . . code for initializing
>>     end method
>>
>>
>> end type
>>
>> my_type X = my_type(args ...)  -- ctor method used.
>> my_type Y = abc                -- assignent checking done.
>>
>> Y.dtor()  -- Destructor explicitly called on Y's data.
>
> I don't think something this complex is needed. The above looks like
> make-shift, but not really, OO. Items such as above should wait until
> we get OO in Euphoria.

And yet I'm thinking the exact opposite. I think we do need something this  
"complex" and the earlier suggestions look makeshift to me.

> For now, all we need is the ability to clean up UDT's and we will always
> need that, even after OO is introduced. So, it's not as though it's
> a temporary crutch, it's a very valuable addition, just the simple
> syntax outlined by Matt.

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.

-- 
Derek Parnell
Melbourne Australia
skype:derek.j.parnell

On Mon, Mar 16, 2009 at 9:37 PM, Derek Parnell <ddparnell@...> 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?  Perhaps the first step is to
introduce something that's still more procedural in nature.  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.

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.

If we make these built-in routines, then the risk of breaking code is
reduced, since users can still override them, and access the built-ins
using the eu: namespace:

sequence puts = "Hello, World\n"
eu:puts(1, puts )

Suppose #2 becomes delete().  I think it would be perfectly reasonable
to re-use this once we add OO (assuming that we do, of course).

-- map.e
function new(...)
    ...
    attach_cleanup( m, map_cleanup )
    return m
end function

....
map:map my_map = map:new(...)
...
delete( my_map )

I think that the call to delete probably shouldn't affect the object
itself, other than to remove the association with the cleanup routine.
 Suppose the call looked like this:

delete( maps[i] )

The implementation of sequences relies on NOVALUE (the special,
uninitialized value) marking the end of a sequence.  Also, you'd no
longer be able to assume that everything from maps[1..$] was a valid
object.

-- 
Matt Lewis

Quoting Derek Parnell <ddparnell@...>:
> 
> > For now, all we need is the ability to clean up UDT's and we will always
> > need that, even after OO is introduced. So, it's not as though it's
> > a temporary crutch, it's a very valuable addition, just the simple
> > syntax outlined by Matt.
> 
> 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.

I'm saying that this solution is *not* temporary and that cleanup of
UDT's will be required even after OO is implemented. Euphoria will never
be an OO or nothing language (I sure hope not!). While OO will have
the means of cleaning up some types like these, users should not be
required to use OO to do so. A Euphoria program should be able to be
developed and have no OO code in it. OO is great in some places, in
other places, it's just overkill.

UDT cleanups are not a form of OO functionality, not any more than a
user defined type is. In my book, UDT cleanup is essential and has
nothing do to with OO, nor will it, nor will it change when OO is
introduced. I think they are *totally* different.

Adding in UDT's today in no way will affect OO programming and they
will be used for years and years after OO is introduced.

Jeremy

Quoting Matt Lewis <matthewwalkerlewis@...>:
> On Mon, Mar 16, 2009 at 9:37 PM, Derek Parnell <ddparnell@...> 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

> From: Jeremy Cowgar
> 
> Quoting Matt Lewis <matthewwalkerlewis@...>:
> >
> > 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?

No, we'll be asking for bugs if we don't do #2.  I'll explain below.
 
> > 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.

Remember that we're adding something in the backend implementation that
has the potential to stick around.  Suppose we had your scenario.
Consider:

procedure foo(map the_map)
    -- ...do stuff
    delete(the_map) -- 
end procedure

procedure main()
    map main_map = new()
    foo( main_map )
end procedure
main()

So within foo(), the_map (which is the same map as main_map in main)
gets cleaned up by the delete routine in map.e.  However, the atom that
represents main_map gets dereferenced at the end of main(), and
map:delete() is called again.  

Now we're trying to clean up the same data multiple times.  Maybe it
will cause an out of bounds error, or maybe it will clobber some other
map that was created in between the call to foo() and the end of main().
Either way, it's an error.

So we either need a way to strip the auto-cleanup magic, or instead of
allowing the user to call the cleanup directly, we provide an automatic,
built-in way to call the cleanup and strip out the cleanup requirement.
This has the benefit that deleting any object takes the same syntax, and
can be a no-op for anything that doesn't have a cleanup attached to it.

I'm also suggesting that we stop talking about these as UDT specific,
even though that's basically what they are.  To take your example:

register_cleanup(map, routine_id("delete"))

I assume the intention here is to associate the delete routine with all
maps.  But how do we make that connection to instances of maps?  There's
really no way to do it.  We'd have to do it within the constructor.

Instead, we can change this to:

-- map.e
procedure delete_map( map m )
    -- de-allocation stuff...
end procedure
constant map_cleanup_rid = routine_id("delete_map")

public function new()
    map new_map
    -- ..allocation stuff
    register_cleanup( new_map, map_cleanup_rid )
    return new_map
end function

-- app.ex
include std/map.e as map
map:map m = map:new()
-- ...
delete(m)

So what we'll have is a generic way for users to handle the manual or
'natural' freeing of any resources associated with a double or sequence.

Matt

I see your points Matt. Makes sense. What kind of development timeframe
are we looking at?

Jeremy

> From: Jeremy Cowgar
> 
> I see your points Matt. Makes sense. What kind of development
timeframe
> are we looking at?

Probably a day or two.  The backend framework is basically there, we'd
just need to add the built-ins, which should be pretty straightforward.

Matt

What happens if you have an object with a value of 4 that is a file 
object and another also with the value of
4 which means something different.  Then will the file object destructor 
run when the other 4 goes out of scope?  Then we call close(4) twice.  
Such a thing must work at the object's pointer level not its value.

Shawn Pringle

> From: Shawn Pringle
> 
> What happens if you have an object with a value of 4 that is a file
> object and another also with the value of
> 4 which means something different.  Then will the file object
> destructor run when the other 4 goes out of scope?  Then we call
> close(4) twice.

No, that's not how it works.

> Such a thing must work at the object's pointer level not its value.

Yes, it works on the actual object in memory, which may be pointed to by
multiple object pointers from the symbol table, or in the guts of
sequences.

Matt

On Tue, 17 Mar 2009 23:25:54 +1100, Lewis, Matthew W.  
<MATTHEW.W.LEWIS@...> wrote:

> Suppose we had your scenario.
> Consider:
>
> procedure foo(map the_map)
>     -- ...do stuff
>     delete(the_map) --
> end procedure
>
> procedure main()
>     map main_map = new()
>     foo( main_map )
> end procedure
> main()
>
> So within foo(), the_map (which is the same map as main_map in main)
> gets cleaned up by the delete routine in map.e.  However, the atom that
> represents main_map gets dereferenced at the end of main(), and
> map:delete() is called again.
>
> Now we're trying to clean up the same data multiple times.  Maybe it
> will cause an out of bounds error, or maybe it will clobber some other
> map that was created in between the call to foo() and the end of main().
> Either way, it's an error.

I would have thought that any 'cleanup' routine that was run against an  
item that had already been cleaned up would be in effect be a NOP. I  
suppose would could make explict calls to the cleanup routine produce a  
fatal error in this case, but the automatic invocation should just ignore  
it.

> I'm also suggesting that we stop talking about these as UDT specific,
> even though that's basically what they are.  To take your example:
>
> register_cleanup(map, routine_id("delete"))
>
> I assume the intention here is to associate the delete routine with all
> maps.  But how do we make that connection to instances of maps?  There's
> really no way to do it.  We'd have to do it within the constructor.
>
> Instead, we can change this to:
>
> -- map.e
> procedure delete_map( map m )
>     -- de-allocation stuff...
> end procedure
> constant map_cleanup_rid = routine_id("delete_map")
>
> public function new()
>     map new_map
>     -- ..allocation stuff
>     register_cleanup( new_map, map_cleanup_rid )
>     return new_map
> end function
>
> -- app.ex
> include std/map.e as map
> map:map m = map:new()
> -- ...
> delete(m)
>
> So what we'll have is a generic way for users to handle the manual or
> 'natural' freeing of any resources associated with a double or sequence.

I'm uneasy with both these suggestions.

Jeremy's idea looks like a "special case" syntax and is not very generic.  
It only associates one type of method - a cleanup - with the data type. In  
future, assuming that a form of OO is incorported into Eu, we will be  
associating all sorts of methods with a datatype (aka class/type). The  
"register_XXXXX()" notation is not very expandable.

Matt's idea is kinda the same but extends to atoms and sequences. But I'm  
thinking that this cleanup ( and future methods) should be regarded as  
advanced programming that only applies to UDTs. If we need to have a smart  
pointer (atom type) that auto-frees itself, we can wrap it in a UDT.

Another issue that might arise with the above syntax is that a coder might  
be able to hijack a type's cleanup routine by coding their own  
"register_cleanup" routine.

I think that the cleanup and other methods need to be tightly associated  
with the data type definition, and the tightest is to incorporate it into  
the actual definition itself. For now we can start with the cleanup/dtor  
method and later enable other methods on the pathway to implementing the  
OO aspect of Euphoria.

Something (and I do mean something) along the lines of ...

  -- map.e
  type map(object x)

    procedure delete()
      -- de-allocation stuff...
    end procedure

    function new()
      object m
      -- ..allocation stuff
      return m
    end function

    function validate()
      -- ensure 'x' is a valid map
      return 1
    end function
end type

  -- app.ex
  include std/map.e as map
  map:map m = map:new()
  -- ...
  map:delete(m)

-- 
Derek Parnell
Melbourne Australia
skype:derek.j.parnell

Derek Parnell wrote:
> Another issue that might arise with the above syntax is that a coder might  
> be able to hijack a type's cleanup routine by coding their own  
> "register_cleanup" routine.
>   

I don't think this is an issue but a benefit. Why not allow someone, who 
needs to, to hijack a cleanup of a certain object? Maybe its a database 
handle and when the main applications database is closed, they want to 
popup a file dialog to choose a new sqlite database file to access? I'm 
not sure that would be the best way of doing it, but I can see where 
some people would like to be able to "hijack" the cleanup process.

> I think that the cleanup and other methods need to be tightly associated  
> with the data type definition, and the tightest is to incorporate it into  
> the actual definition itself. For now we can start with the cleanup/dtor  
> method and later enable other methods on the pathway to implementing the  
> OO aspect of Euphoria.
>
> Something (and I do mean something) along the lines of ...
>
>   -- map.e
>   type map(object x)
>
>     procedure delete()
>       -- de-allocation stuff...
>     end procedure
>
>     function new()
>       object m
>       -- ..allocation stuff
>       return m
>     end function
>
>     function validate()
>       -- ensure 'x' is a valid map
>       return 1
>     end function
> end type
>
>   -- app.ex
>   include std/map.e as map
>   map:map m = map:new()
>   -- ...
>   map:delete(m

That just seems overly complex w/no benefit. I'm sorry to take that 
stance, but I really see no benefit. Further, when we do move to OO, it 
really blurs the lines between things. As for my short example (which I 
really don't have strong ties to the syntax of) and Matt's, you have 
mentioned that it is not very versitile. That is because it's not trying 
to be the precursor to OO. It's only function is to cleanup when a ref 
count = 0. That's all it needs to do. It does not need to be able to 
register other methods.

To me, it would be a mistake to develop the UDT cleanup (as we are 
calling it right now) with the idea of expanding it in the future for 
OO. OO should be developed 100% on it's own, free of any baggage that 
may come from UDT's and UDT cleanups.

Jeremy

> From:  Derek Parnell
> 
> I would have thought that any 'cleanup' routine that was run against
an
> item that had already been cleaned up would be in effect be a NOP. I
> suppose would could make explict calls to the cleanup routine produce
a
> fatal error in this case, but the automatic invocation should just
> ignore it.

Either I haven't communicated clearly enough, or you're not following it
through all the way, or we're talking past each other.  My point was
that if we allow the user to directly call the cleanup routine, we need
a way to tell the backend that it shouldn't do its auto-cleanup when the
time comes.  Otherwise, the backend won't be able to tell that it's been
cleaned up already.  The regex cleanup does this, but being part of the
back end, it has easy access to the low level details of the object,
which is something that native euphoria code doesn't have.

Right now, there's a pointer that's stored on a double or sequence.  If
it's null, then nothing happens when the object is freed.  If it's not
null, then the backend calls the appropriate cleanup routine.

 
> I'm uneasy with both these suggestions.
> 
> Jeremy's idea looks like a "special case" syntax and is not very
> generic. It only associates one type of method - a cleanup - with
> the data type. In future, assuming that a form of OO is incorporated
> into Eu, we will be associating all sorts of methods with a datatype
> (aka class/type). The "register_XXXXX()" notation is not very
> expandable.
> 
> Matt's idea is kinda the same but extends to atoms and sequences. But
> I'm thinking that this cleanup ( and future methods) should be
regarded
> as advanced programming that only applies to UDTs. If we need to have
a
> smart pointer (atom type) that auto-frees itself, we can wrap it in a
> UDT.

Here's the question which neither Jeremy's proposal nor yours have
covered:  How do we actually associate the object with the cleanup
routine?  By which I mean, when and how do we add that cleanup pointer?

Ultimately, a UDT is just a piece of euphoria data, with some occasional
additional type checking.  If you put it into a sequence, then all
information about the UDT-ness of it is lost.  As has been remarked
before, euphoria UDTs are pretty weak constructs.

I'm talking about a general way to attach cleanups to euphoria objects.
Those objects might be UDTs.  In the future, they might be some sort of
OOP construct.  Or some other structured data.  I believe that whatever
new paradigms we introduce could be grafted onto this structure.  The
register_XXX() doesn't have to be expanded to OOP.  But it *is* a way to
implement the functionality that we want in a straightforward way, that
I think will be easily understandable, and not unlike current euphoria
code.

> Another issue that might arise with the above syntax is that a coder
> might be able to hijack a type's cleanup routine by coding their own
> "register_cleanup" routine.

Yes, I've played with the thought of allowing cleanups to chain
together, similarly to how destructors are called in C++, for instance.

> I think that the cleanup and other methods need to be tightly
> associated with the data type definition, and the tightest is to
> incorporate it into the actual definition itself. For now we can start
> with the cleanup/dtor method and later enable other methods on the
> pathway to implementing the OO aspect of Euphoria.

I think that for OO to work, the ctor/dtor needs to be tightly coupled
with the data type definition, but I also think that we're jumping the
gun by trying to use OOP here.  And, as I said above, I think that it
will be pretty easy to extend this method to whatever OO features
euphoria might end up with.

> Something (and I do mean something) along the lines of ...
> 
>   -- map.e
>   type map(object x)
> 
>     procedure delete()
>       -- de-allocation stuff...
>     end procedure
> 
>     function new()
>       object m
>       -- ..allocation stuff
>       return m
>     end function
> 
>     function validate()
>       -- ensure 'x' is a valid map
>       return 1
>     end function
> end type
> 
>   -- app.ex
>   include std/map.e as map
>   map:map m = map:new()
>   -- ...
>   map:delete(m)

This approach still needs to answer my original #2: How do we strip off
the cleanup when delete() is explicitly called by the coder?  I suppose
that we have hard coded the delete, new and validate names to have
special meanings, so I suppose that we could do some special magic
inside the new routine under the covers to get the pointer onto the
object.

Matt

Lewis, Matthew W. wrote:
> Here's the question which neither Jeremy's proposal nor yours have
> covered:  How do we actually associate the object with the cleanup
> routine?  By which I mean, when and how do we add that cleanup pointer?
>   

I'd like us to stop talking about my proposal as it is incorrect and 
does not handle the situation correctly. I withdraw my proposal :-)

Jeremy

> From: Jeremy Cowgar
> 
> Lewis, Matthew W. wrote:
> > Here's the question which neither Jeremy's proposal nor yours have
> > covered:  How do we actually associate the object with the cleanup
> > routine?  By which I mean, when and how do we add that cleanup
> pointer?
> >
> 
> I'd like us to stop talking about my proposal as it is incorrect and
> does not handle the situation correctly. I withdraw my proposal :-)

Sorry, I wasn't trying to pick on you, and I knew that it was just sorta
notional.  I was just using it as an example that did a good job of
illustrating the issues.

Matt

Lewis, Matthew W. wrote:
>> I'd like us to stop talking about my proposal as it is incorrect and
>> does not handle the situation correctly. I withdraw my proposal :-)
>>     
>
> Sorry, I wasn't trying to pick on you, and I knew that it was just sorta
> notional.  I was just using it as an example that did a good job of
> illustrating the issues.
>   

Don't care about that, it's fine to continue to reference it if for that 
reason, I just didn't want people to think they are choosing between 
Jeremy's, Matt's or Derek's proposal.

Jeremy

So far, three people (including me) have weighed in on this topic, and
even among us three, we don't have a consensus.  Here is a quick recap
of the two ideas that have been presented (Derek, please correct me if
I get something wrong here).  I suppose that if we can't get a larger
collection of opinions, then perhaps we could take this topic to
euforum to resolve.  Perhaps we could put competing ideas up on the
wiki.

The purpose of this enhancement is to allow automatic or manual
cleanup of resources associated with some euphoria object, such as
opened file handles, allocated memory, or other euphoria objects.

The first idea uses an Object Oriented approach, and associates a
constructor and destructor within the definition of a type.  This
approach anticipates OOP being added to euphoria in a future release.

type my_thing( object m )

    method validate( object m )
        -- standard UDT type checking
    end method

    method new(...params...)
        -- acquire resources, initialize, etc
    end method

    method delete( my_thing m )
        -- release resources
    end method
end type

my_thing thing = new()
my_thing:delete(thing)

The delete method would also be called when the object was
dereferenced and freed.

The second idea adds a more generic concept of cleaning up euphoria
objects.  It would add two built-in routines:

function delete_routine( object obj, integer delete_rid )
procedure delete( object obj )

delete_routine() would be used to associate a destructor routine (a
procedure taking one argument) with a euphoria object, returning the
same object, or, if an integer were passed, the integer would be
promoted to an atom in order to keep track of its references.

The delete() routine could be called on any object, with any
associated delete_routine(), or none.  If an object that is not
associated with a delete procedure, then nothing happens.

If delete is called for either version, then the delete routine is
disassociated with the object.  Another option which could be
implemented with either version would be to allow multiple associated
delete routines, such that the last associated routine is the first
delete routine called, and then the rest would be called in the
reverse order of which they were added.

-- 
Matt Lewis

I know I am one of the parties who have already responded, but for the 
record, I'll respond again. I think we should go with Matt's suggestion. 
The reasons are numerous, but to make my point I'll make a short list:

1. Euphoria is a procedural language right now and even when OO is 
introduced, it should continue to be able to write applications 100% 
procedural. For something as as simple as type cleanup, an OO approach 
should not be required.
2. We should not try to put OO into 4.0, as it should contain many 
months of discussion before even starting one piece of code to implement 
it. Too much is at risk to quickly toss OO into 4.0, even if it is a 
mere pre-cursor. Trying to base future OO on what is laid in UDT clean 
up, I think would be a huge mistake.
3. The proposal by Matt in no way would change when OO is introduced, 
nor would it conflict. When OO is introduced, UDT cleanup would be just 
as valid, just as usable and would have no affect on OO in the future 
Euphoria.
4. UDT cleanup is necessary on all sorts of variables that have no need 
of OO programming. Sure, anything can be put into OO, but not everything 
requires OO.  Currently Euphoria cleans itself up on everything that is 
a native type yet no native type is an Object, in the sense of OO 
programming.

I really want to stress #2. Any form or hint of OO in 4.0 would be doing 
a great dis-service to Euphoria due to the lack of planning. To me it 
would be like closing our eyes, throwing the corner stone of a new sky 
scraper into the air and where it landed is where the building would be 
built, w/no regard for the landscape. I cannot possibly see how we could 
get it even remotely correct without a few months of discussion and 
anything we do today will either lay this foundation and cause many 
hurdles, regretted future design decisions or it would cause us to scrap 
what we do today with the OO type cleanup and cause another major 
breakage in subsequent Euphoria versions.

The simple 2 method type UDT cleanup is valid today, tomorrow and for 
the future of Euphoria, regardless of OO.

Jeremy

On Fri, 20 Mar 2009 09:11:43 +1100, Matt Lewis  
<matthewwalkerlewis@...> wrote:


> The purpose of this enhancement is to allow automatic or manual
> cleanup of resources associated with some euphoria object, such as
> opened file handles, allocated memory, or other euphoria objects.

My concern is that we will end up having two different syntaxes for  
cleaning up things once OO features are added to the language. So I'd like  
to see implemented that which can be later extended seemlessly for OO  
purposes. I'm not wedded to any specific syntax example discussed so far,  
just so long as we aren't forced into confusing future syntax.

-- 
Derek Parnell
Melbourne Australia
skype:derek.j.parnell

Derek Parnell wrote:
>> The purpose of this enhancement is to allow automatic or manual
>> cleanup of resources associated with some euphoria object, such as
>> opened file handles, allocated memory, or other euphoria objects.
>>     
>
> My concern is that we will end up having two different syntaxes for  
> cleaning up things once OO features are added to the language. So I'd like  
> to see implemented that which can be later extended seemlessly for OO  
> purposes. I'm not wedded to any specific syntax example discussed so far,  
> just so long as we aren't forced into confusing future syntax


Derek,

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? 
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.

Jeremy

On Fri, 20 Mar 2009 12:50:52 +1100, Jeremy Cowgar <jeremy@...>  
wrote:

> Derek Parnell wrote:
>>> The purpose of this enhancement is to allow automatic or manual
>>> cleanup of resources associated with some euphoria object, such as
>>> opened file handles, allocated memory, or other euphoria objects.
>>>
>>
>> My concern is that we will end up having two different syntaxes for
>> cleaning up things once OO features are added to the language. So I'd  
>> like
>> to see implemented that which can be later extended seemlessly for OO
>> purposes. I'm not wedded to any specific syntax example discussed so  
>> far,
>> just so long as we aren't forced into confusing future syntax
>
>
> Derek,
>
> 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.

> 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.

-- 
Derek Parnell
Melbourne Australia
skype:derek.j.parnell

On Thu, Mar 19, 2009 at 9:50 PM, Jeremy Cowgar <jeremy@...> wrote:
>
> 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?
> 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 suspect that they will use the same delete(obj) syntax, and mostly
the same backend code to make it all work.  In fact, the use of
delete() should be the exception, rather than the rule.  All it takes
is for the refcount to drop to zero, and the cleanup is triggered.
The main difference will be the way in which we determine the delete
routine.

OO code should simply define a delete() method (like Derek's proposal)
and the backend will automatically pick that up.  Procedural code
doesn't have the same structure, and needs the extra delete_routine().

-- 
Matt Lewis

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@...>
> wrote:
>>
>> 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
process.

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:

-- std/memory.e
constant FREE_RID = routine_id("free")
public function auto_ptr( integer size )
    atom ptr = allocate( size )
    return delete_routine( size, FREE_RID )
end function

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:

procedure foo()
    atom ptr = auto_ptr( 4 )
    -- do stuff
    delete( ptr ) -- calls free(ptr) and clears its destructor
end procedure

procedure bar()
    atom ptr = auto_ptr( 4 )
    -- do stuff
    -- ptr's ref count drops to zero, and free(ptr) is called
end procedure

>> 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
done.

-- 
Matt Lewis

Quoting Matt Lewis <matthewwalkerlewis@...>:
> 
> >> 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
> done.
> 

Where are we on this? UDT cleanup is the last real thing to do before we
release beta 1. I'd hate for this to stall any more than it already has.

I personally am in favor of Matt's proposal.

Jeremy

No more discussion on this? I don't think we have reached an answer?

Jeremy

We must have an answer before beta 1 is released. If there is no more
discussion on this, then let us call this to a vote.

On Wed, Mar 25, 2009 at 12:31:06PM -0400, Jeremy Cowgar wrote:
> No more discussion on this? I don't think we have reached an answer?
> 
> Jeremy
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Rapideuphoria-develop mailing list
> Rapideuphoria-develop@...
> https://lists.sourceforge.net/lists/listinfo/rapideuphoria-develop
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Jim C. Brown wrote:
> We must have an answer before beta 1 is released. If there is no more
> discussion on this, then let us call this to a vote.
>   

I take it because no one has responded that we are done discussing?

Jeremy

On Thu, Mar 26, 2009 at 12:55 PM, Jeremy Cowgar <jeremy@...> wrote:
> Jim C. Brown wrote:
>> We must have an answer before beta 1 is released. If there is no more
>> discussion on this, then let us call this to a vote.
>>
>
> I take it because no one has responded that we are done discussing?

Actually, I have a few more things to say...some refcounting issues
occurred to me.  I'll post about it later.  I want to run some actual
tests.

BTW, I put a branch up (branches/mwl_delete) with my code, so others
can play with it, too.  The first commit didn't build on windows.
I've just updated a patch for that.  Beware that euphoria.h has
changed, so if you try to translate something, you need to set EUDIR
or EUCOMPILEDIR to make sure that the newer version is picked up, or
you'll segfault.

-- 
Matt Lewis

On Thu, Mar 26, 2009 at 12:59 PM, Matt Lewis
<matthewwalkerlewis@...> wrote:
>
> Actually, I have a few more things to say...some refcounting issues
> occurred to me.  I'll post about it later.  I want to run some actual
> tests.
>

Ok, the issue I was having was with putting a delete routine with a
sequence that was composed of other objects that need to be cleaned
up.  Suppose you had a sequence that had multiple pointers that need
to be freed.  If the deletion were attached to the sequence, then any
changes to the sequence could trigger the delete routine.

Think if you pass the sequence to a routine, and some changes are
made.  At this point, the ref count of the sequence is 2, so it gets
copied.  Now suppose that it returns the changed value, and it gets
assigned to the original variable.  The original sequence gets garbage
collected, and the pointers freed. This would be bad, because the
coder believes the pointers to be valid, but they aren't.

The solution is not to put the deletion on the sequence, but on the
pointers themselves.  I made an example that is a simple wrapper for a
C struct.  Rather than use free() directly, I used an extra routine to
print out the fact that it's freeing the pointers.

-- foo.e
namespace foo

include std/machine.e

/*
Wrapper for a C struct:

struct foo{
	int a;
	int *b;
};

*/
public enum
	a,
	b,
	ptr,
	b_ptr


type foo_struct( object f )
	if atom(f) then
		return 0
	end if
	if length(f) != 4 then
		return 0
	end if
	for i = 1 to 4 do
		if not atom(f[i]) then
			return 0
		end if
	end for
	return 1
end type

procedure free_autoptr( atom ptr )
	printf(1,"Freeing %0x08x\n", ptr )
	free( ptr )
end procedure
constant FREE = routine_id("free_autoptr")

function auto_ptr( integer size )
	return delete_routine( allocate( size ), FREE )
end function

public function new()
	foo_struct foo = repeat( 0, 4 )
	
	foo[ptr]   = auto_ptr( 8 )
	foo[b_ptr] = auto_ptr( 4 )
	
	return foo
end function

public procedure poke( foo_struct f )
	poke4( f[ptr], f[a] )
	poke4( f[b_ptr], f[b] )
end procedure

public function peek( foo_struct f )
	f[a] = peek4s( f[ptr] )
	f[b] = peek4s( f[b_ptr] )
	
	return f
end function

procedure main()
	foo_struct bar = new()
	bar[a] = 1
	bar[b] = 2
	? bar
	foo:poke( bar )
	bar = foo:peek( bar )
	? bar
end procedure
main()

-- 
Matt Lewis

Matt,

I played around with mwl_delete today but I'm having a problem, is this 
correct usage:

procedure person_free(object o)
    printf(1, "%s %s is being free'd\n", o)

    o[1] = ""
    o[2] = ""
end procedure

function person_new(sequence first_name="", sequence last_name="")
    sequence p = { first_name, last_name }
    return delete_routine( p, routine_id("person_free") )
end function

if 1 then
    object p = person_new("John", "Doe")
    printf(1, "New person is: %s %s\n", p)
end if

puts(1, "All Done\n")

When this program runs, I get:

John Doe is being free'd
New person is:
All Done

Jeremy

On Fri, Mar 27, 2009 at 1:20 PM, Jeremy Cowgar <jeremy@...> wrote:
> Matt,
>
> I played around with mwl_delete today but I'm having a problem, is this
> correct usage:


> When this program runs, I get:
>
> John Doe is being free'd
> New person is:
> All Done

No, that's not what it should be doing.  I think that delete_routine()
is missing a RefDS somewhere.

-- 
Matt Lewis

On Fri, Mar 27, 2009 at 1:20 PM, Jeremy Cowgar <jeremy@...> wrote:

> if 1 then
>    object p = person_new("John", "Doe")
>    printf(1, "New person is: %s %s\n", p)
> end if
>

I just committed r1552 (you probably got an email), but note that this
code probably still won't do what you expect it to do, because while
'p' goes out of scope, it's not cleaned up when it does.  For now, you
can either assign something else to it, or put it in a procedure.

I previously put this issue as #4 on the optimization list:
http://openeuphoria.org/wiki/euwiki.cgi?Roadmap40

However, with destructors being triggered on dereferencing, this
should perhaps be considered a bug.



-- 
Matt Lewis

Matt Lewis wrote:
> No, that's not what it should be doing.  I think that delete_routine()
> is missing a RefDS somewhere.
>   

Ok, after your last commit, it now prints "John Doe", however, it never 
says it's being free'd. I changed it to read:

if 1 then
    object p = person_new("John", "Doe")
    printf(1, "New person is: %s %s\n", p)
    p = person_new("Jane", "Doe")
    printf(1, "New person is: %s %s\n", p)
end if

And now it states John Doe is being free'd but not Jane Doe.

If I do this:


procedure hi()
    if 1 then
        object p = person_new("John", "Doe")
        printf(1, "New person is: %s %s\n", p)
    end if
end procedure

hi()

Then it says John Doe is being free'd.

Thoughts?

Jeremy

Matt Lewis wrote:
> I just committed r1552 (you probably got an email), but note that this
> code probably still won't do what you expect it to do, because while
> 'p' goes out of scope, it's not cleaned up when it does.  For now, you
> can either assign something else to it, or put it in a procedure.
>
> I previously put this issue as #4 on the optimization list:
> http://openeuphoria.org/wiki/euwiki.cgi?Roadmap40
>
> However, with destructors being triggered on dereferencing, this
> should perhaps be considered a bug.
>
>   
Ha! Guess I was too quick w/an email. You explained my email w/o reading 
it at all I am sure.

Jeremy

On Fri, Mar 27, 2009 at 1:47 PM, Jeremy Cowgar <jeremy@...> wrote:
> Matt Lewis wrote:
>> I just committed r1552 (you probably got an email), but note that this
>> code probably still won't do what you expect it to do, because while
>> 'p' goes out of scope, it's not cleaned up when it does.  For now, you
>> can either assign something else to it, or put it in a procedure.
>>
>> I previously put this issue as #4 on the optimization list:
>> http://openeuphoria.org/wiki/euwiki.cgi?Roadmap40
>>
>> However, with destructors being triggered on dereferencing, this
>> should perhaps be considered a bug.
>>
>>
> Ha! Guess I was too quick w/an email. You explained my email w/o reading
> it at all I am sure.

Yeah, I've been thinking way too much about reference counting lately.
 One possible benefit is the change I made to RIGHT_BRACE_2/N, that
doesn't add a ref for a temp.  This could lead to extra copy on
writes.

Another issue that is worth talking about is reference counting with
respect to literal sequences and atoms.  They start off life with a
positive reference count (created by the parser).  So if you, for
instance, assign them directly to a variable, then you end up with a
refcount of 2.  Something like:

atom a = delete_routine( 1.5, RID )

Will never be cleaned up except through an explicit delete() call.  We
could force a copy in this case, which would allow it to be possibly
freed through normal refcounting, allowing the delete to be called.

Obviously, there's a performance penalty there, but it's probably
worth it to get it to work in what seems (to me) the most obvious way
that most people would expect.

PS  Derek, are you seeing this conversation or has the spam filter eaten it?
-- 
Matt Lewis