Hi,

Will & DFK wrote:
> >> * Automatic declaration of type and instance variables in  
> >> typemethod and
> >>   method bodies
> >>       
> > By this you mean making available all variables defined in an instance
> > to every method invoked upon that instance, wherever it is defined?  
> > I've
> > done that in the past (e.g. a few years ago when I gave a talk on new
> > elemental features of 8.5) but I've found it's a problem when scaled  
> > up
> > as you easily get clashes between formal parameters to methods on a
> > class and variables defined on a sub(sub)class or instance. Explicit
> > naming of vars is both more like a normal procedure, and far less
> > inclined to blow up at unexpected times because of this problem.
> >     
>  I agree that name collisions are an issue when you add inheritance  
>  into the mix.  On the other hand, I hate explicit naming of vars,  
>  which is why Snit doesn't work that way.  A reasonable compromise  
>  would be that instance variables declared by a type would be  
>  automatically visible in the methods defined explicitly by that type,  
>  but not elsewhere, i.e., you'd need to explicitly declare them in  
>  subclasses.
>    
For what it's worth I think that implicit access to member variables 
from within a method body is distinctly un-Tclish.  We don't have 
implicit access to global variables, namespace variables, or any of the 
other implicit variable scoping that you find in other languages; why 
start with objects?  I don't think that making instance variables 
available implicitly in any context is a reasonable compromise.

That said I recognise that there are developers who find implicit 
variable access an advantage, and I can respect that (even if they are 
wrong ;) ).  I believe the following code inserted at the start of a 
method will accomplish the desired functionality?
  foreach v [info object vars [self object]] {
    my variable $v
  }

To make it simple perhaps a proc import_object_vars that uplevels that 
code snippet.

How this could be extended to automatically import the object variables 
(without rewrite the body of the method, which I believe SNIT 1.x does) 
I'm not sure.

---
Slight change of topic (Warning: Radical Ideas Ahead!)

Would it be worth considering an additional "meta" parameter to a method 
definition (before or afeter the argslist).  Such a parameter could be 
used in future to extend the functionality of methods without breaking 
the interface.
For example:
  - oo::define c method my_func {autovars true} {args} { ... }
In this case meta is treated as a dict, and TclOO knows about the 
"autovars" value which will cause the object's variables to be 
implicitly brought into scope (like import_object_vars above)
  - oo::define c method my_func {pointtag t} {args} { ... }
In the future some support for Aspects is added.  If an enter/leave 
action is associated with any of the listed pointcut tags (in this case 
"t") then that action will be executed in the context of the method 
before the body (in the case of enter) or at the point of return (leave).
  - oo::define c method my_func {pointcut [list ::mycallback arg1]} 
{args} { ... }
Also for Aspect support, define a specific method to invoke rather than 
a tagged action.  This specific case is equivalent to trace enter / 
trace leave.

I know it may be a bit late in the dev cycle to be raising new ideas, 
but I didn't think of it before ;p  Is there any merit in this?

Regards,
Trevor





-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core