All commands are equal, but some are more equal than others.
Mark Janssen
Fast forward 2 years. Our happy new Tcl coder AH (Anonymous Hacker) has
just finished implementing a HTTP webcrawler using the http package
when the phone rings.
<PHB> AH we are having some problems with connections being dropped.
Can you do some debugging?
<AH> No problem, I will get to it straight away.
AH renames the http command to http_ and creates a subclass http which
overrides the connect method, to trace when connections are made. After
restarting his application again AH notices that he is opening way too
many connections. He fixes the bug and leaves in the debug code so he
can trace the connections being set up. After that he goes home feeling
very happy.
FF 2 months
In his free time AH is writing a scrabble application and he wants to
be able to scramble a string. With his new found knowledge he is
confident this should take no more than 30 minutes and starts writing.
% <some oo command to create a method> string scramble {} {# scramble
string}
error string is not an object.
Very surprised AH starts searching the Tcl wiki to find out what might
be going on here, when he stumbles upon namespace ensembles.
Thinking he found the way to do it AH happily goes to work again:
% <command to add subcommands to namespace ensemble> string scramble {}
{# scramble string}
error string is not a namespace
Getting a little bit annoyed now, AH decides to take the more involved
way (everything is cmd args after all) and renames string to _string
creates a new string command that checks if the first arg is scramble
and otherwise calls _string with {something here}$args.
After getting it to work after almost a day of hacking, AH is a bit
annoyed but happy it is working.
FF 6 months
After upgrading the http package to a newer version for even better
HTTP2.0 support, suddenly the phone rings, it's PHB.
<PHB> AH what did you do?! All our webcrawler scripts are crashing.
AH quickly rolls back to the older http version and starts to
investigate (of course he should have tested first but thats why he is
_A_H)
As it turns out the new maintainer of the http package really dislikes
OO and has rewritten everything using namespace ensembles, breaking
AH's code to trace connect attempts.
Very annoyed, AH starts up his Perl installation he had still lying
around to see how that worked again.
----
In the story above I have tried to demonstrate what my worries are
about some of the currently evolving functionality that is being put
into Tcl.
Up until now a command was just a command. Some commands you could see
the args and body of (defined with proc) and some not (internal
commands).
However in Tcl 8.5 there seem to be some commands that are more command
than the old fashioned Tcl commands. These commands (objects and
namespace ensembles) offer exciting new introspection capabilities
(such as finding out the defined subcommands). However because they
have overlapping functionality some choose one way and others choose
another.
I can see several problems with this:
1) Tcl user experience: you will have to know what type of command a
command is and use the appropriate way to extend it. TIMTOWTDI
2) Package maintainers/developers. Even though TIMTOWTDI, once you have
chosen one way you cannot change because your users are probably using
implementation details (is it OO, is it namespace)
My question is, are there any plans to:
1) Migrate all internal commands accepting subcommands to one of the
two scheme's (string chan etc.) to make the user experience more
uniform. (If it looks the same, it acts the same)
2) Is there any pressing reason for the seemingly overlap in OO and
namespace ensembles and is it a good idea to introduce this in the
first place?
I understand that 1 is a Herculean task, I am just wondering if it is
being considered.
Mark
Donal K. Fellows
> 1) Migrate all internal commands accepting subcommands to one of the
> two scheme's (string chan etc.) to make the user experience more
> uniform. (If it looks the same, it acts the same)
Yes, but only once we figure out how to "compile into ensembles".
Without that, the effects on everyone's code would be horrible; we don't
want 8.5 to be slower than 8.3. :-)
> 2) Is there any pressing reason for the seemingly overlap in OO and
> namespace ensembles and is it a good idea to introduce this in the
> first place?
You can do a "poor man's OO" quite easily using ensembles. It's just
hard to get high-performance and sophistication (e.g. inheritance that
doesn't work by completely replacing the method) in there at the same
time; all the extra processing needed for the complicated bits just gets
in the way.
This is an inadequate answer to your question. I'll need think very
carefully to write a better one.
Donal.
Don Porter
> Up until now a command was just a command.
Or a proc. Or an alias. Or an import. Or a widget. Or some other
kind of command provided by a package. All of which can have some
things done to them and not to other command types.
You generally raise a good point, but the notion that Tcl is in some
virgin state of innocence that it's in danger of losing doesn't hold up.
The nice thing is that even with some differences, all the command
varieties present and future do have in common the fact that they *are*
commands, so anything you do with/to them that treats them simply *as
commands* will apply universally.
DGP
Larry W. Virden
Mark Janssen wrote:
> 1) Tcl user experience: you will have to know what type of command a
> command is and use the appropriate way to extend it. TIMTOWTDI
It seems, to me, that things are in flux right now - not only have
namespace ensembles been created, but now we have the possibility that
an object oriented system may be added.
I suggest that the appropriate response, by developers who want to
extend commands, is to start a discussion about updates to the Tcl
engineering guide to state the "tcl best practice" for this, then to
begin submitting code changes to the tcl.sf.net project converting
commands to that format as you have need for them. That way, you end up
getting what you need, when you need it.
> 2) Package maintainers/developers. Even though TIMTOWTDI, once you have
> chosen one way you cannot change because your users are probably using
> implementation details (is it OO, is it namespace)
Which is a good reason to get the "best practices" hammered out and
documented, so people can do them the same way, as much as possible.
>
> My question is, are there any plans to:
>
> 1) Migrate all internal commands accepting subcommands to one of the
> two scheme's (string chan etc.) to make the user experience more
> uniform. (If it looks the same, it acts the same)
> 2) Is there any pressing reason for the seemingly overlap in OO and
> namespace ensembles and is it a good idea to introduce this in the
> first place?
>
> I understand that 1 is a Herculean task, I am just wondering if it is
> being considered.
Has the introspective commands of Tcl been upgraded appropriately so
that one can get all the info one needs without having to squirrel
around with a dozen different commands just to figure out what a
command is, etc.?
Scott
Donal K. Fellows wrote:
> Mark Janssen wrote:
> > 2) Is there any pressing reason for the seemingly overlap in OO and
> > namespace ensembles and is it a good idea to introduce this in the
> > first place?
>
> You can do a "poor man's OO" quite easily using ensembles. It's just
> hard to get high-performance and sophistication (e.g. inheritance that
> doesn't work by completely replacing the method) in there at the same
> time; all the extra processing needed for the complicated bits just gets
> in the way.
I sort of assumed (without much thought) that an object *was* an
ensemble, and the various object system were (more or less) just
convenient shortcuts for creating a new ensemble with various
subcommands (methods) and variables preinstalled.
In fact, I was even hoping some of the more esoteric OO concepts
(method interception & chaining) would be exposed to non-OO code so you
could intercept and chain regular Tcl commands, ensemble or not.
But it sounds like this isn't true? I agree with Mark that it's quite
unfortunate to have two concepts (objects and ensembles) that are
simultaneously indistinguishable and incompatible. Are there any core
abstractions that are common to both that can be factored out?
Robert Heller
>
>
> Donal K. Fellows wrote:
> > Mark Janssen wrote:
> > > 2) Is there any pressing reason for the seemingly overlap in OO and
> > > namespace ensembles and is it a good idea to introduce this in the
> > > first place?
> >
> > You can do a "poor man's OO" quite easily using ensembles. It's just
> > hard to get high-performance and sophistication (e.g. inheritance that
> > doesn't work by completely replacing the method) in there at the same
> > time; all the extra processing needed for the complicated bits just gets
> > in the way.
>
> I sort of assumed (without much thought) that an object *was* an
> ensemble, and the various object system were (more or less) just
> convenient shortcuts for creating a new ensemble with various
> subcommands (methods) and variables preinstalled.
The difference from between class object and an ensemble command is that
classes have instances and ensembles do not. At least that is how snit
defines things. Think of the difference between the 'string' command in
Tcl and, say, the canvas command. The string command has a pile of
'subcommands' (snit would call them 'typemethods' -- they would be like
static methods in C++ or Java). The canvas command in Tcl/Tk creates an
instance of a cancas widget, which has its own instance methods.
>
> In fact, I was even hoping some of the more esoteric OO concepts
> (method interception & chaining) would be exposed to non-OO code so you
> could intercept and chain regular Tcl commands, ensemble or not.
>
> But it sounds like this isn't true? I agree with Mark that it's quite
> unfortunate to have two concepts (objects and ensembles) that are
> simultaneously indistinguishable and incompatible. Are there any core
> abstractions that are common to both that can be factored out?
If what is being implemented is much like snit, there should not really
be any problems. Snit has both objects (instances of types [classes])
and ensembles (types without instances, but with lots of typemethods).
>
>
--
Robert Heller -- 978-544-6933
Deepwoods Software -- Linux Installation and Administration
http://www.deepsoft.com/ -- Web Hosting, with CGI and Database
hel...@deepsoft.com -- Contract Programming: C/C++, Tcl/Tk
Scott
> The difference from between class object and an ensemble command is that
> classes have instances and ensembles do not.
My simple (and apparently incorrect) mental model was that when a class
created an instance, it would create a new ensemble command and
populate the new ensemble with the appropriate subcommands (methods).
In other words, objects would be implemented on top of ensembles, not
in a parallel structure to them.
Note that a class could be an ensemble that has the appropriate object
creation subcommands/method. This would make metaclasses very clean.
> If what is being implemented is much like snit, there should not really
> be any problems. Snit has both objects (instances of types [classes])
> and ensembles (types without instances, but with lots of typemethods).
As I understand the initial posting, the problem is that ensembles and
the OO system look the same but are implemented differently so you
can't extend an ensemble with the OO system and vice versa. So if
someone wants to extend someone else's code,they're required to know
how the code was implemented. I think that's unfortunate and will prove
to be an ongoing source of frustration.
Robert Heller
No, this should not be the case. One just renames the existing ensemble
command to something else and then you define a new ensemble command
that uses the renamed ensemble command, plus any additional functions.
This is how snit implements widgets and widgetadapters (but with widget
objects, but the principle is the same.
Or once could just use snit to do all of this for you. Note: snit is
written entirely in Tcl -- Tcl already has the sorts of low-level
features and functions to do all of this, cleanly. Snit is in fact an
OO extension system than can be used to extend *other* OO systems,
*without* knowing anything about these other OO systems. Snit works
quite well at extending both base Tk widgets and BWidgets. I see no
reason snit cannot be used in other contexts. Or at least the
methodologies of snit.
Larry Smith
> At 28 Oct 2006 16:27:08 -0700 "Scott" <sgar...@comcast.net> wrote:
I see no
> reason snit cannot be used in other contexts. Or at least the
> methodologies of snit.
For whatever it's worth: after watching this whole discussion I guess
I've come around to the same idea: bless snit as "official", and let
other systems live in tcllib. I think we are adding too much ginger-
bread to get this idea nailed down, and it's making Tcl uglier. Let's
not add ::any::more::warts. We should be looking for ways to make
Tcl smaller and sleeker, not larger and funkier.
--
.-. .-. .---. .---. .-..-. |Experts in Linux: www.WildOpenSource.com
| |__ / | \| |-< | |-< > / |"Making the bazaar more commonplace"
`----'`-^-'`-'`-'`-'`-' `-' |Check out my new novel: "Cloud Realm":
http://www.smith-house.org:8000|<this+/books/Larry_Smith/CloudRealm.html