Hello,
my name is Arnulf Wiedemann (see APW in wiki.tcl.tk). I am new to this list 
but not new to Tcl/Itcl. I am working with Itcl for about 10 years building 
commercial applications for use within the company I work for.

You may have read some postings from me on c.l.t concerning the new OO system 
in Tcl and how to eventually build a new version of Itcl on top of that.

At the moment I am thinking on how to implement classes/variables for being 
able to mostly use Tcl core functionality together with one of the OO TIPs # 
257 or # 279.

I am also in contact with Miguel Sofer to find out how to avoid the need for 
implementing a lot of the Itcl functionality in an own C-extension. Maybe it 
is possible to perhaps extend the existing Tcl core interfaces to allow to 
get rid of a lot of the Itcl C-written functionality.

I am thinking on a different internal representation of the Itcl classes and 
variables to do that. I would like to present my current ideas and would be 
happy to get some feedback (especially where you see troubles).

Here are my ideas ideas:
what about adding the protection levels private/protected/public  for 
variables also to normal Tcl. As that's an enhancement no existing code will 
break. The handling of visiability (resolving) could be made like in Itcl in 
that case only related to the namespaces of the current namespace. The 
current implementation to have a variable command without a protection level 
stays as it is right now.

So a private variable is only visible in the namespace where it resides, a 
protected variable in the name spaces where it resides and in all namespaces 
which are subnamespaces of the current namespace and within the current 
namespace, a public variable then I think should be visible also in other 
namespaces, if you fully specify the namespace in front of the variable i.e.:
 
namespace eval ns1 {
public variable v1
}

namespace eval ns1::ns2 {
protected variable v2
private variable v3
}

namespace eval ns1::ns2::n3 {
protected variable v4
private variable v5
}

v1 accessible in ns1 as v1 or else as n1:v1
v2 is accessible within n1::n2 as v2 as well as from within n1::n2::n3 as v2 
(as the protection level is protected)
v3 is accessible within n1::n2 as v3
v1 accessible in ns1::n2 as v1 or as n1:v1
v3 is accessible within n1::n2::n3 as v3 (as that is a subnamespace of n1::n2)
v1 accessible in ns1::n2i::n3 as v1 or as n1:v1
v4 is only accessible within n1::n2::n3 as v4 (as there is no subnamespace)
v5 is accessible within n1::n2::n3 as v5

Having that, I think for Itcl one could do the following:
in principle use the rules as above and in instanciating an object from a 
class hierarchy where the classes are like the namespaces above but within a 
special namespace for example:
::itcl::objects::my_object name::class_name1::class_name2::class_name3 
for the example above my_object name would be the "command name" for the itcl 
object to bring that in the normal namespace hierarchy

This would mean there is some internal mechanism in the Tcl Core to use the 
namespaces below ::itcl::objects::my_object name:: for doing variable name 
resolution as stated above  (if within an Itcl namespace).
All described in the last 2 paragraphs would be transparent for the "normal 
user" of Itcl.

For building the class hierarchies I would like to try to use the oo::* 
commands/classes as a base und to wrap that with some Tcl code to parse the 
Itcl class syntax.

Cheers and thanks for any comments,
Arnulf

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Incrtcl-users mailing list
Incrtcl-users@[...].net
https://lists.sourceforge.net/lists/listinfo/incrtcl-users