Re: Core commands as ensembles...
- From: Fredderic <my-name-here@xxxxxxxxxx>
- Date: Sat, 26 Jan 2008 03:36:41 +1000
On Sun, 13 Jan 2008 21:23:55 -0800 (PST),
"tom.rmadilo" <tom.rmadilo@xxxxxxxxx> wrote:
On Jan 13, 7:49 pm, Fredderic <my-name-h...@xxxxxxxxxx> wrote:
Yeah, I think there is a little extra care you need to take whenThis is simply moronic. You seem intent on adding confusing commands
redefining [namespace]. I did it myself to add a [namespace prefix]
command that does much the same as [namespace code], except that it
simply adds the fully qualified namespace from whence it was called
to Tcl, who cares about your additions? Why not just write your own
language?
Nah. Did that once already. Turned out rather entertaining, really.
Not really much use, but very entertaining. The main point of it was
to be able to express structures that C had difficulty with, back in
the XT/AT days, and thereabouts, where the thought of using a 32-bit
int to count from 1 to 10 was something akin to a mortal sin.
Clue yourself in here: 'much the same' means 'not the same' as in
'completely different'.
What is your problem. Usually you seem half-way intelligent, but
you're a little off the rocker today...
We all get that you are not satisfied with ordinary Tcl. Still, we
have no evidence of any code which demonstrates your ideas. Put up, or
shut up. It is really very tiring discussing vapor-ware. Seriously, is
there a single line of code anywhere we can look at?
If it makes you happy...
proc call {args} {
set ns [uplevel 1 namespace current]
if { $args eq {} } {return $ns}
set cmnd [lindex $args 0]
if { [namespace qualifiers $cmnd] ne "" } {return $args}
if { $ns eq "::" } {set ns ""}
return [lreplace $args 0 0 ${ns}::[lindex $args 0]]
}
That's the present invocation of the function. Not that it should
matter. I wasn't actually talking about how great and wonderful that
function is, or how suitable it was to any given purpose. I was
describing the basic technique of adding functionality to non-ensemble
commands, and offering an example as one such place where I have used
the technique I was referring to.
Further, that style results ultimately from the rather C-esque callback
mechanism used in the first two applications I ever used which contained
TCL as their scripting/console engine. The first of them was an
industrial-strength electonics CAD package, and both of them had an
obvious C feel to the way they used TCL. I've always had the distinct
impression that both applications originally were built around an
extremely basic DOS-like command line, and TCL was only plugged in
later to make it actually remotely useful. I still do odd jobs on
software that hasn't really changed much since then, so most of that
code really isn't applicable. And being from an embedded systems
background, I do tend to feel more comfortable with using that style in
my own home-brew code. Although I apply it with more thought to
TCL-ness than those ancient applications did, it's still a very clean
(to my way of thinking) mechanism. Especially if at some point in the
future I decide to translate it back into a compiled language.
Lastly, most of my questions on here, relate more to my own personal
home-brew bits and pieces, in which I will use TCL in any way that I
damn well want to use it. When I'm working on code that has a price tag
attached, or which I intend to distribute, I'll use all due care and
something resembling decent style. But when I'm stuffing around with my
own code, I'll take any shortcut I feel like, to get the job done, and
get on with doing what I would rather be doing. It serves its purpose
perfectly well, whether you like it or not, and if you must know, the
main reason I don't generally bang around code snippits is EXACTLY
because I don't advocate using my slack home-brew style of coding for
real jobs that might actually matter to someones wallet. Plus, my
general home-brew scripts make frequent use of other home-brew script
libraries, TCL "adjustments", and occasionally extensions, none of which
will make a whole lot of sense to anyone else. The code snippits I do
include in my posts, are generally re-written on the spot to exhibit
the key points, in as general a context as possible, and with as
little cruft and/or confusing optimisations as possible (unless, of
course, that's the main point being made).
So to be quite frank, I really couldn't give a *** what you think
about this particular example. It wasn't even the point of the message.
Fredderic, I would love nothing more than for you to prove me wrong,
but without code, your words are just words. Words are words, code is
code. No code = bs.
Ahhh..... So you would describe that thread on backrefs as bull***
too? As far as I'm aware, there's no actual code there. But I think
you might rub more than just me the wrong way by labelling it such.
No one, not me, nor anyone else, needs to prove themselves to you. So
next time you feel the need to stand on your soap box, at least try to
do it on-topic. But in the meantime, I do hope I've answered your
questions. At least, as far as I think you're worth answering. Good
day to you Sir, and do have a nice life.
Fredderic
.
- Follow-Ups:
- Re: Core commands as ensembles...
- From: Alexandre Ferrieux
- Re: Core commands as ensembles...
- References:
- Core commands as ensembles...
- From: Fredderic
- Re: Core commands as ensembles...
- From: Gary
- Re: Core commands as ensembles...
- From: Fredderic
- Re: Core commands as ensembles...
- From: tom.rmadilo
- Core commands as ensembles...
- Prev by Date: Re: Obstacles for Tcl/Tk commercial application development ?
- Next by Date: Re: Core commands as ensembles...
- Previous by thread: Re: Core commands as ensembles...
- Next by thread: Re: Core commands as ensembles...
- Index(es):