Check-in [a023e48805]

in the same hash tables) so that there are no ambiguities.

Since every method has at most one declaring class or object (and not both
simultaneously) there is at most one private method that can be on any call
chain. External calls (e.g., from the top level of Tcl, from a **namespace
eval**, from a procedure) will never have a private method on thir call
chains.

Once the call chain is created, the execution is handled as prior to this TIP;
the implementation of the first element on the call chain is executed,
whatever that is, and that can dispatch to later items on the call chain using
**next** and **nextto**.

A private method on a class (or object) may not have the same name as another
method on that class; all methods of a class (or object) are part of a single
space of names. When resolving a method call of a subclass of the class that
has the private method, even if the method names match, the private method
does not participate in the call chain; only an exact match from exactly the
right context counts.







In particular:

    oo::class create Top {
        method Foo {} {
            puts "This is Top::Foo for [self]"
        }
................................................................................
        }
    }

That is, the **private** declaration command described above (for methods)
also impacts the **variables** slot declaration in **oo::define** and
**oo::objdefine**, causing it to introduce this more complex mapping
pattern. Note that the variable resolver already is class-scoped.

In the above example, a subclass of _Foo_ that refers to variables _x_ and _y_
will not see the variables defined by _Foo_, but will instead see either the
current standard variable scheme or their own _x_ and _y_. (If the creation ID
of _Foo_ is `123`, then _Foo_'s _x_ and _y_ will really be called `123 : x`
and `123 : y`, respectively.)

Introspection is via adding an extra option to **info class variables** and
**info object variables**, **-private**, which causes these commands to list
the private variables. Without the option, the non-private (i.e., direct
mapped) variables are listed.

A supporting introspector is also added, **info object creationid**, which
returns the creation ID of any existing object. It also applies to classes.
Again, note that creation IDs are _always_ system-allocated and are _never_
guaranteed to be unique between interpreters, either in multiple processes or
in the same thread or process; they are only ever locally unique.

# Examples

in the same hash tables) so that there are no ambiguities.

Since every method has at most one declaring class or object (and not both
simultaneously) there is at most one private method that can be on any call
chain. External calls (e.g., from the top level of Tcl, from a **namespace
eval**, from a procedure) will never have a private method on thir call
chains.

Once the call chain is created, the execution is handled as prior to this TIP;
the implementation of the first element on the call chain is executed,
whatever that is, and that can dispatch to later items on the call chain using
**next** and **nextto**.

A private method on a class (or object) may not have the same name as another
method on that class; all methods of a class (or object) are part of a single
space of names. When resolving a method call of a subclass of the class that
has the private method, even if the method names match, the private method
does not participate in the call chain; only an exact match from exactly the
right context counts.
Applying **export** or **unexport** to a private method will make that method
cease to be private, but it must be used on the same context (class or
instance) that defined the method; subclasses or instances cannot export or
unexport a private method defined by their superclass/class (respectively).
There is no mechanism for making an existing method private; that needs to be
done at method creation time.

In particular:

    oo::class create Top {
        method Foo {} {
            puts "This is Top::Foo for [self]"
        }
................................................................................
        }
    }

That is, the **private** declaration command described above (for methods)
also impacts the **variables** slot declaration in **oo::define** and
**oo::objdefine**, causing it to introduce this more complex mapping
pattern. Note that the variable resolver already is class-scoped.

In the above example, a subclass of _Foo_ that refers to variables _x_ and _y_
will not see the variables defined by _Foo_, but will instead see either the
current standard variable scheme or their own _x_ and _y_. (If the creation ID
of _Foo_ is `123`, then _Foo_'s _x_ and _y_ will really be called `123 : x`
and `123 : y`, respectively.)

Introspection is via adding an extra option to **info class variables** and
**info object variables**, **-private**, which causes these commands to list
the private variables. Without the option, the non-private (i.e., direct
mapped) variables are listed.

A supporting introspector is also added, **info object creationid**, which
returns the creation ID of any existing object. It also applies to classes.
Again, note that creation IDs are _always_ system-allocated and are _never_
guaranteed to be unique between interpreters, either in multiple processes or
in the same thread or process; they are only ever locally unique.

# Examples