From: Rene Z. <r.z...@fr...> - 2013-11-14 21:15:39
|
Am Mittwoch, 30. Oktober 2013, 09:20:40 schrieb Donal K. Fellows: > Sorry for not replying sooner; I've been a little bit occupied with > coding for work. It happens sometimes. :-D > > On 10/10/2013 20:24, Rene Zaumseil wrote: > > currently we have all object variables inside an object namespace. > > It is possible to make all these variables available in methods. > > Alternatively we can access variables with 'my variable ..'. > > But the variables are in the class and in all superclasses of an object > > the same. It is not possible to define and use private variables, > > with possible the same name and different meaning, in class methods. > > This was a deliberate decision, in that having highly varying variable > names is very confusing when it comes to telling people what's going on. > I am open to looking again at that, but delicately. :-) > > I do want shared-across-all-instances-of-a-class to be easier, but that > may just be a case of standardizing some syntax. > I have some code on the wiki at http://wiki.tcl.tk/38910 I have extended the existing variable command of TclOO. May be we can add something along this into TclOO? It should not break exsisting scripts. And putting private variables in the namespace of the object will make deletion simple. > I also want there to be an easier way of making parameters to methods > and the current resolver-based mechanism to be easier. (It's awfully > messy and unintuitive right now; utterly terrible.) > > Finally, I want there to be a more formal way of defining properties, > where they are to consist of an explicitly-declared variable, initial > value (optional), and a method to expose the property via a standard > method (configure?) with discoverability, etc. Also probably optional > explicit handlers for getting and setting, to deal with "interesting" > updates when someone accesses a property. > > On the other hand, allowing classes to control variable binding and > method message dispatch (i.e., the assembly of the method call chain) > would be nice. Those are currently features that are coded directly in C > without real opportunity for interception. (There's an internal API that > itcl uses, but it's not very pleasant.) > Please have a look on http://wiki.tcl.tk/38916 Options and component handling is relatively simple to build on top of TclOO. The problems start when you are try to use private variables and components. I have done it with a internal function _zz_trace which is included in every object. Then I can select the class context with the nextto function. But it feels not so good. I'm also still experimenting with syntax and naming of commands. In the option handling part I have made o distinction between simple object options and widget options. In my opinion the tk option handling is a relict from the past and we should find a more general approach. But I may be wrong in this area. rene |