Check-in [a023e48805]

Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to [email protected]
or submit via the online form by Sep 9.

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:A few more notes on exporting, and lengthen some very short paragraphs by combining them.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: a023e48805c0279ea10288ae2211bcb26337f285d8eeed2ebdfc3d711ec645ef
User & Date: dkf 2018-05-27 10:43:06
Context
2018-05-27
10:50
Fix markdown formatting issue check-in: 230d2e87e1 user: dkf tags: trunk, minor change
10:43
A few more notes on exporting, and lengthen some very short paragraphs by combining them. check-in: a023e48805 user: dkf tags: trunk
10:35
Add some titles to the examples check-in: 8b7522e1b5 user: dkf tags: trunk
Changes
Hide Diffs Unified Diffs Show Whitespace Changes Patch

Changes to tip/500.md.

97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115






116
117
118
119
120
121
122
...
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
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






<











>
>
>
>
>
>







 







<










<







97
98
99
100
101
102
103

104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
...
294
295
296
297
298
299
300

301
302
303
304
305
306
307
308
309
310

311
312
313
314
315
316
317
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