Re: [TCLCORE] TIP #257: Object Orientation for Tcl

[Zoran V. <zv...@ar...>]

Am 28.09.2005 um 14:25 schrieb Donal K. Fellows:

> I've been thinking a bit more about automated lifetime management of
> objects and I'd like to try running an idea up the flagpole to see
> whether you shoot it or salute it. :-)
>

I'd salute an automatic, hands-free lifetime management, if possible.

In Tcl, I (mostly) do not care about when/how *something*
(there are exceptions to that, rather) is allocated or
deallocated.  The Tcl does this for me == I'm more productive.
Why would OO objects be different?

A kind of simple refcounting mechanism?

We have that already on the Tcl_Obj level. I'm wondering if we
can employ such when dealing with OO objects? An Tcl_OO thing?
Or am I leaning too much out of the window? Needless to say that
I didn't think of the implementation yet. Just the idea seems very sexy.

Would that be doable at all?
I could supply you with couple of examples to illustrate what
I mean if you need more details, that is, if you don't see a
No-Can-Do because of This-And-That.

Zoran

> The problem I have with Class::volatile (quite apart from the way that
> it is tangled in with the constructor/configure system in ways that  
> I do
> not propose to duplicate in the core OO system) is that I don't see  
> how
> you could turn off volatility or decide that a volatile object  
> should be
> returned to the caller of its declaration scope. This makes me  
> wonder if
> it is possible to come up with a better way of doing lifetime  
> management
> that allows these more advanced capabilities.
>
> My idea is that there should be a class that provides these sorts of
> things that can be mixed in, so you could do something like this:
>
>   # Make a barobj
>   fooclass barobj
>
>   # Add this orthogonal capability to barobj
>   oo::define barobj mixin volatility
>
>   # Now barobj is deleted automatically...
>
> where "volatility" is this class that provides the functionality.
>
> I'm not sure how to handle all the details of volatility; perhaps we
> would want to have methods like:
>
>   volObj return
>      Makes the object non-volatile in the current owning scope,  
> volatile
>      in the caller's scope, and causes the caller to actually  
> return the
>      name of the object.
>
> I'd imagine that generalized container behaviour could be handled in a
> similar sort of way.
>
> Any opinions?
>
> Donal.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads,  
> discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>