On 10/28/2010 05:17 AM, Karl Lehenbauer wrote:
If the request is simply to weigh in, then I've got some rhymes for the house.
Regarding the supposed Itcl compatibility of Tcl 8.6, having to invoke methods
in the same object with either $this or [self] is a non-starter for us
(FlightAware) -- we have way too much Itcl code for that plus it just smells.
Surely it's temporary.
Object systems let you build bigger programs without losing control of them. I
think it's a really natural idea -- code and data are defined together and you
can have multiple instances of something with all the data for each instance
nicely grouped and easily accessed. Upvar is heavily (ab)used as a sort of
pseudo-object system. Look at tcllib for lots of examples. For example with
the http package, code accesses instances of data using upvar. It works but
it's better to support it in a first order and non-kludgey way, i.e. built into
the language.
I hope I'm not getting it wrong, but it seemed to me that the problem
Clif is struggling with is the lack of support in TclOO for marshaling
functions of public member variables. In that specific case I can make
out a common situation: handling together a list of <attribute> <value>
pairs that wouldn't be sensible to take apart as they are meant to end
up in the same tag. Before 8.5 (and 'dict') I extensively used the
constructs "array set ..." "array get ..." (at the cost of having
not-so-efficient code) to pass around lists that are thus guaranteed to
have even length and keep the association <attr>-<value>. I even ended
up writing an Itcl class around an array that enabled me to add some
extra features to the parameters processing of a form.
I agree that the 'upvar' abuse as a way of having pseudo-objects should
be avoided but in the specific case quoted by Clif we could get around
it changing the interface and changing the container from an array to a
dictionary
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
