namespace glob expansion
vit...@gmail.com
Is it possible/desirable to extend TCL core to make the (namespace)
environment more transparent?
Example:
----------------------------------------------------
I have these namespaces: x::y1::z, x::y2::z, x::y3::x
If I want to see all commands in namespaces x::y1::z, x::y2::z,
x::y3::z
info commands x::*::z
In namespace x::y1::z
info commands x::*1::z
Find ALL namespaces below x::
namespace children x::*
Find all namespaces below x::y1 and x::y2
namespace children x::y*
----------------------------------------------------
Basically, add glob expansion to namespace and it's associated
commands (where it makes sense). IMHO, that would make programming
with TCL much easier for a lot of people (including the humble
me). :)
Bruce Hartweg
How? and Why?
Is this just a simple laziness/typing thing? (I know I need these namespaces
but I don't feel like typing all of them all out) - As Neil already showed
it is quite simple to add this at the script level for your own use.
If that's not the case, can you please describe a use case that this addition
solves? Generally if you are coding, then you knowm what namespace you need to
get the commands you want, - and for just general introspection, I think the
current commands provide anythiong you would need - again you can wrap syntactic
sugar at the script level.
Bruce
vit...@gmail.com
How? -- In the source code of TCL, of course.
Why? -- I use namespaces a lot for code abstraction/separation/
tidiness. Simulating directories, web links, you name it.
Laziness? --- most definitely. :) If it wasn't for laziness, I would
be coding in machine language/assembly code. ;)
I use the shell a lot in Linux, that's where the idea came from. I
just love the idea where I can use "find ./" and see the entire layout
of the directory hierarchy in a glance, instead of going into each
directory and doing "ls". Also "ls ./*/*" does something similar.
Those conveniences exist for a reason. Saves a ton of time and typing.
In TCL, for example, when doing "package require" of some unfamiliar
package that uses namespace(s), it would be nice to see the entire
hierarchy of that package's namespace(s) and commands in a glance.
Bruce Hartweg
I meant how does it make it easier, not how to implement it ;)
> Why? -- I use namespaces a lot for code abstraction/separation/
> tidiness. Simulating directories, web links, you name it.
> Laziness? --- most definitely. :) If it wasn't for laziness, I would
> be coding in machine language/assembly code. ;)
>
I agree - i didn't mean laziness as necessarily a bad thing.
> I use the shell a lot in Linux, that's where the idea came from. I
> just love the idea where I can use "find ./" and see the entire layout
> of the directory hierarchy in a glance, instead of going into each
> directory and doing "ls". Also "ls ./*/*" does something similar.
> Those conveniences exist for a reason. Saves a ton of time and typing.
> In TCL, for example, when doing "package require" of some unfamiliar
> package that uses namespace(s), it would be nice to see the entire
> hierarchy of that package's namespace(s) and commands in a glance.
>
OK, you seem to be talking about interactive manual introspection, not
features needed for writing apps directly. (unless you are writing IDEs
of other tools that need extra amounts of introspection).
For this use case, I think doing it at the script level is easier and
quite sufficient. Neil already gave nice example starter points for this.
And Donal noted that making the changes in the core are a bit more of a
change that might seem at first glance - so I would suggest using a script
level wrapper to add the functionality you want, and if it really seems
to be as great an additiona as you think, submit a feature request, include
the tcl wrapper with it to demonstrate the functionality, and then look into
making a patch for the core itself (or finding someone willing to do that)
Bruce
vit...@gmail.com
I am talking about both, interactive and for writing apps.
>
> For this use case, I think doing it at the script level is easier and
> quite sufficient. Neil already gave nice example starter points for this.
I agree, doing it at the script level is easy. But I would have to
include that code in each file, on every system etc. I don't mean to
push for it, I was hoping that other people might find it as useful as
it is to me.
> And Donal noted that making the changes in the core are a bit more of a
> change that might seem at first glance - so I would suggest using a script
> level wrapper to add the functionality you want, and if it really seems
> to be as great an additiona as you think, submit a feature request, include
> the tcl wrapper with it to demonstrate the functionality, and then look into
> making a patch for the core itself (or finding someone willing to do that)
I do hope that someone is willing to do that because I can't program
in C. I did take the C programming class in college long time ago and
don't remember much, plus, I think the learning curve is quite steep
for me to do it within next year or so. I did submit a feature
request, so, may be someone will be kind enough to do it.
>
> Bruce
Cameron Laird
<vit...@gmail.com> wrote:
.
.
.
>I use the shell a lot in Linux, that's where the idea came from. I
>just love the idea where I can use "find ./" and see the entire layout
>of the directory hierarchy in a glance, instead of going into each
>directory and doing "ls". Also "ls ./*/*" does something similar.
.
.
I'm lazier than you. I type
find .
Cameron Laird
>in C. I did take the C programming class in college long time ago and
>don't remember much, plus, I think the learning curve is quite steep
>for me to do it within next year or so. I did submit a feature
>request, so, may be someone will be kind enough to do it.
.
.
Along with all the other wonders Tcl performs for us,
it can help practice C: <URL: http://wiki.tcl.tk/critcl >.
Alexandre Ferrieux
Finding C skills is certainly a necessary condition, but not a
sufficient one !
Not every random addition to the core makes it just because one person
finds it cool.
There's a repulsive force in action too: call it "Ockham's razor",
"inertia", or whatever, but it helps keep it simple. As long as
something is doable in pure script with no noticeable speed penalty,
it is hard to justify bloating the core.
-Alex
USCode
[snip]
> As long as
> something is doable in pure script with no noticeable speed penalty,
> it is hard to justify bloating the core.
>
> -Alex
bloat as one of their primary concerns ... otherwise we'd have a 10MB+
core, just like Java, AdobeAir, etc. ... yuck. Tcl would lose one of
it's primary attractions ... it's lean and mean!
Donal K. Fellows
> [Tcl]'s lean and mean!
There are times when it feels fat and bloaty to me...
Donal.
Alexandre Ferrieux
Seconded !
-Alex