Re: [agtk-devel] AGLIB tcl binding

[Steve C. <ste...@mq...>]

On Mon, 11 Feb 2002 21:52, Haejoong Lee wrote:
> > We're making use of the tcl binding just now. I'm wondering why it
> > doesn't use namespaces, eg AG::CreateAG rather than AG_CreateAG? 

> I think I'm the person who is responsible for most of the suggestions.
> I can't see exactly how "undo" stuff works. However, having a namespace
> sounds great.  To be honest, I didn't even know that Tcl support
> namespace. I'm not a Tcl programmer :)

I've attached a version of ag.tcl which uses namespaces fyi.  I've put 
everything into an AG namespace, including the AGF functions, I don't know 
what the argument is for having them separate.  I've also capitalised 
AG::Load and AG::Save for consistency with the rest of the interface. 

I did also put together an incr tcl class based interface but I'm currently 
thinking again about the best way to do that. 

The undo stuff works by redefining some of these procs to store an inverse 
command or set of commands on an undo stack. When you want to undo an 
operation in the editor you just run the commands of the stack and things are 
as they were.  Namespaces make things neater (so we can get a list of the 
commands in the interface easily) but our current implementation is based on 
an itcl class which defines all of the operations as methods. 

> I agree with you. Since we have multiple wrappers (currently two),
> the following would be better:
>
>     ag_wrapper/
>         tcl/
>             ag.tcl
>             ag_tcl.so
>             pkgIndex.tcl
>         python/
>             ag.py
>             ag_python.so
>

This wouldn't work at least with tcl since tcl will only look for packages in 
sibling directories to it's own installation dir (eg all dirs in 
/usr/local/lib). I imagine that python is similar.  The main thing is to get 
the tcl package files into one directory that can be installed in the right 
place or bundled up to form a binary extension package.

> > How hard (and desirable) would it be to combine the libraries into a
> > smaller number of shared objects.  
>
> So we have some options here:
>
>     (libag + libagf), (tcl wrapper), (python wrapper)
>     (libag + libagf + tcl wrapper), (libag + libagf + python wrapper)
>     (libag + libagf + tcl wrapper + python wrapper)
>
> I guess you meant the first choice. 

Yes, and even the second choice as a compile time option. This would give me 
one big shared object I could deliver with my application if I only use AG 
vial the tcl (or python) interface.  



Steve