Am Sonntag, 4. Mai 2008 16:13:17 schrieb Donal K. Fellows:
>  Hi everyone
> 
>  This is a warning that I think we're close to the point when I'll call a
>  vote on TIP#257, i.e. the merger of TclOO into Tcl. While it still has
>  its warts, they're largely implementation issues and we can sort them
>  out later (indeed, some may need full core integration to get completely
>  knocked on the head; it's difficult to really make methods efficient)
>  and the rest can get their own TIPs. But are there any really critical
>  problems left that can't be dealt with later? Hence this message.
> 
>  I'd like to remind people that TclOO strives for minimality in many
>  respects (I didn't want to get sucked into writing a class library!) and
>  it tries to leave state (i.e. variables) to conventional Tcl namespace
>  variables (slotted access could be built on top of this foundation, but
>  I'm not doing it at this stage). What it does do is provide a proper
>  inheritance model, mixins, filters, and mechanisms to allow things (new
>  method types, new data structures) to be plugged in from the C level. I
>  believe I've demonstrated that Self-like objects can be built on top,
>  and I think that something like both iTcl and XOTcl can work too (the
>  former wouldn't have actually worked with the proposal from 18 months
>  ago; the extra time allowed a number of key refinements of some internal
>  APIs). It's also being used already for building some of the reference
>  implementation of TDBC.
> 
>  In short, if there's a problem with TclOO, do speak up now!

concerning Itcl-ng I see the following points mostly for speeding up execution 
speed of itcl-ng methods:

- a clientData field in the Class structure (C-level)
- a clientData field in the Object structure (C-level)
- a clientData field in the CallContext structure (C-level)
- some additional optional calls for extensions (itcl-ng)

I know, there is the possibility for Metadata in Class and Object, but I have 
the feeling the function call overhead for extracting the Metadata is a lot 
for beeing used on calling a method (speed argument!).
As it's only a pointer of some otherwise also used data, there is no need for 
a deletion proc.

In the CallContext there is the need for itcl-ng specific ItclCallContext 
info, I could set  that  field in the preCallProc. As it's only a pointer of 
some otherwise also used data, there is no need for a deletion proc.

Additionally an optional call for checking itcl-ng specific protection issues 
just before or after mapNethodNameProc, to be able to give itcl-ng specific 
error message and direct return in case of error (protection violation). That 
cannot be done in GetCallContext, as there is some itcl-ng specific knowledge 
necessary for checking.

Additionally an optional call for checking itcl-ng specific parameter 
correctness just before or after mapNethodNameProc, to be able to give 
itcl-ng specific error message and direct return in case of error. It may be 
a still better idea to have a user specific function call for "parameter 
error" checking in the normal Tcl code to satisfy that need

An optional call for cleaning up itcl-ng class/object specific info when 
deleting a class/object just before the TclOO code is starting work.

Just for being able to use filters and mixins also for mapNethodNameProc calls
would be helpfull that instead of skipping the "not used" classes in the call 
chain and start after that, to mark the "not used" classes in the call chain 
as "TO_BE_SKIPPED" and to skip them when invoking/handling the call chain.

I think nothing of these features should/will force somebody to vote with no 
(I also suggest to vote with yes :) ), but that will be the topics coming up 
for itcl-ng. And these issues should not prevent TclOO to be integrated into 
Tcl core!

Arnulf Wiedemann (apw)
 
> 
>  Donal.
> 
>  -------------------------------------------------------------------------
>  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/java
> one _______________________________________________
>  Tcl-Core mailing list
>  Tcl-Core@[...].net
>  https://lists.sourceforge.net/lists/listinfo/tcl-core



-------------------------------------------------------------------------
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