TclOO internals and introspection

[ted brown]

Does anyone know of a good paper or video from a conference on the
layout of memory use in TclOO? In particular what sorts of introspection
is available to find things. And what are all the namespaces used for,
especially the ::oo namespace?

I've been playing with [namespace children] a bit and I found on 8.7a4
under the ::oo::Obj11 and ::oo::Obj13 namespaces (after I've defined a
new class) that there are some namespaces which look kinda funny, such as

% namespace children ::oo::Obj11::
{::oo::Obj11:: oo }

where there's actually spaces in the namespace name. Is there some
special use for that? On 8.6 I don't run across that even with the same
TclOO code.

I'm interested in developing some debugging tools so I can see what's
going on at a bird's eye level. I know of a few object browsers, but I
want to know how to get at it at the tcl internal level.

Or does TclOO store things you just can't see from the outside?

[Arjen Markus]

There have been several TIPs on improving the introspection capabilities of TclOO, from a quick look at the overview it seems most of that work has been completed.

That said, I am not at all an expert on the subject ;). So, my suggestion is to use Ashok's book, notably section 14.11 on TclOO introspection, if you haven't done so already.
See https://wiki.tcl-lang.org/page/BOOK+The+Tcl+Programming+Language

Regards,

Arjen

[ted brown]

Yes, Ashok's book is a treasure. It's in fact the only significant
information I've studied on TclOO.

I've also been reading his blog at

https://www.magicsplat.com/blog/tcl87-oo/

and he mentioned that there's work being done on private variables and
methods.

To academics who design programming languages with the goal of enabling
program correctness proofs (once quite the popular rage), private data
is needed to assure that some algorithm, either by design or error,
cannot have clobbered your data.

For example, in C, this is impossible since I can do such things as get
the address of a local variable and then through *p walk up the stack
frames possibly with evil intent. Many such tricks are commonly used in
exploits today.

And so with TclOO, I was wondering if that is part of the goal for
upcoming enhancements. I believe that outside of TclOO, I can pretty
much find any data (created at script level) if I know how to look. And
even an object's data can be accessed if you know the namespace it's in.

Starting with an example from Ashok's book,


oo::define Account {
variable AccountNumber Balance
}

I then discovered using these sorts of statements:

namespace eval ::oo::Obj52:: {info vars}

from a console (or using a tk widget -textvariable) I can monitor those
variables:

% set ::oo::Obj52::Balance
1000000

Anyway, I am attempting to see if my namespace debugging tools can be
applied to TclOO as well.

So, I guess a question I have is: will tcl remain tcl, where programs
will continue to be able to have access to pretty much everything if you
know where and how to look.

[Schelte]

On Mon, 18 Jan 2021 11:31:43 -0800, ted brown wrote:
> And even an object's data can be accessed if you know the namespace it's
> in.

You can get the namespace of an object using: info object namespace $obj


Schelte

[ted brown]

That's useful to know thanks.

I was wondering where the data about the class itself is stored, before
any objects are created (if I have the terminology correct). I've
searched every namespace looking and haven't found anything until it
returns, as in this,

set acct [Account new 3-14159265]
puts "acct= $acct "

where the output here was acct= ::oo::Obj52 And then I have a namespace
for the new object (though possibly this will not remain the case, and
the above info object is the correct approach).

But where is all the data about Account? In say,

oo::define Account {
variable AccountNumber Balance
}

Before I create an object, I haven't been able to track down anything
about those 2 variables.

Forgive me if I am asking dumb questions, I don't write OO myself, but
my friend was asking if I could adapt a tool for his use.

thanks

[Schelte]

On Mon, 18 Jan 2021 15:36:25 -0800, ted brown wrote:
> But where is all the data about Account? In say,
>
> oo::define Account {
> variable AccountNumber Balance
> }
>
> Before I create an object, I haven't been able to track down anything
> about those 2 variables.
>

A class is an object itself (of the ::oo::class class). So you can still
use [info object namespace Account] to find its namespace.

The reason you can't find the variables is that they don't exist yet
because they haven't been assigned a value. In fact, it hasn't even been
determined if they are arrays or scalar variables.

It's similar to doing:

namespace eval ns {
variable var
}

At this point you won't be able to find anything about ns::var either.


Schelte.

[ted brown]

Ah, thanks, It's slow going for me, but each time I reread Ashok's
chapter on introspection, I think I absorb another 5-10%. I have been
able now to find the method definitions and can see how to instrument
them with breakpoints.

I think what has been confusing me is that unlike other languages,
declarations such as variable, need to be dynamically executed. I'm
still thinking old school static "compile time" declarations, where
those other languages don't define new data types at runtime. Tcl truly
is a dynamic language. And I've been able to modify methods at runtime.
I doubt you can do that in C++ or Java, for example.

I think I need to give my brain a rest. But you've pointed me in the
right direction, so thanks so much for that.

[Donal K. Fellows]

On Monday, 18 January 2021 at 23:36:29 UTC, tedbr...@gmail.com wrote:
> I was wondering where the data about the class itself is stored, before
> any objects are created

It's in a C structure in memory (called 'Class', unoriginally); it's not a namespace as such (despite the fact that classes, as they're objects themselves, do have a namespace each) as things have different semantics. [info class] should be able to pick the various bits and pieces out of it that [info object] doesn't see.

In the case of this:

oo::define Account {
variable AccountNumber Balance
}

what you're actually doing is programming the variable resolver used inside methods declared by that class so that any variable name (except for an argument) ends up actually referring to an instance variable. The field of the C structure that holds the information is called 'variables' (and there's a separate one called privateVariables in 8.7).

If you're coming at TclOO from experience with C++, the big weird thing is that TclOO is a single-rooted class system, with every class being a subclass of oo::object and an instance of oo::class. Yes, this means that oo::class is an instance of itself. Don't think about it too hard. Also, all instance creation is done by calling the factory methods of a class object; that's called 'create' when you give it a name and 'new' when you don't. And that's the difference there.

If you're coming at TclOO from Java and C#, being able to subclass oo::class is the weird thing. That's got deep consequences.

If you're coming at TclOO from [incr Tcl], the main thing is that you can change things and customise things far more. Yes, the default flavour is deliberately close, but the details are not.

If you're coming at TclOO from XOTcl, the main thing is that you don't use methods of classes and instances to change them. Instead the (re)configuration is via a little language because Tcl itself is good at those.

Donal.

[ted brown]

Thanks for the detailed explanation. I will next try out [info class]
and see what I get :)