class.n

这是一个Linux下的集成开发环境

The \fIcommand\fR is usually \fBmethod\fR, \fBproc\fR,
\fBvariable\fR or\fBcommon\fR, and the remaining \fIarg\fR's
complete the member definition.  However, \fIcommand\fR can
also be a script containing many different member definitions,
and the protection level will apply to all of the members
that are created.

.SH CLASS USAGE
.PP
Once a class has been defined, the class name can be used as a
command to create new objects belonging to the class.
.TP
\fIclassName objName\fR ?\fIargs...\fR?
Creates a new object in class \fIclassName\fR with the name \fIobjName\fR.
Remaining arguments are passed to the constructor of the most-specific
class.  This in turn passes arguments to base class constructors before
invoking its own body of commands.  If construction is successful, a
command called \fIobjName\fR is created in the current namespace context,
and \fIobjName\fR is returned as the result of this operation.
If an error is encountered during construction, the destructors are
automatically invoked to free any resources that have been allocated,
the object is deleted, and an error is returned.
.sp
If \fIobjName\fR contains the string "\fB#auto\fR", that string is
replaced with an automatically generated name.  Names have the
form \fIclassName<number>\fR, where the \fIclassName\fR part is
modified to start with a lowercase letter.  In class "Toaster",
for example, the "\fB#auto\fR" specification would produce names
like toaster0, toaster1, etc.  Note that "\fB#auto\fR" can be
also be buried within an object name:
.CS
fileselectiondialog .foo.bar.#auto -background red
.CE
This would generate an object named ".foo.bar.fileselectiondialog0".

.SH OBJECT USAGE
Once an object has been created, the object name can be used
as a command to invoke methods that operate on the object.
.TP
\fIobjName method\fR ?\fIargs...\fR?
Invokes a method named \fImethod\fR on an object named \fIobjName\fR.
Remaining arguments are passed to the argument list for the
method.  The method name can be "constructor", "destructor",
any method name appearing in the class definition, or any of
the following built-in methods.
.SH BUILT-IN METHODS
.TP
\fIobjName\fR \fBcget option\fR
Provides access to public variables as configuration options.  This
mimics the behavior of the usual "cget" operation for Tk widgets.
The \fIoption\fR argument is a string of the form "\fB-\fIvarName\fR",
and this method returns the current value of the public variable
\fIvarName\fR.
.TP
\fIobjName\fR \fBconfigure\fR ?\fIoption\fR? ?\fIvalue option value ...\fR?
Provides access to public variables as configuration options.  This
mimics the behavior of the usual "configure" operation for Tk widgets.
With no arguments, this method returns a list of lists describing
all of the public variables.  Each list has three elements:  the
variable name, its initial value and its current value.
.sp
If a single \fIoption\fR of the form "\fB-\fIvarName\fR" is specified,
then this method returns the information for that one variable.
.sp
Otherwise, the arguments are treated as \fIoption\fR/\fIvalue\fR
pairs assigning new values to public variables.  Each variable
is assigned its new value, and if it has any "config" code associated
with it, it is executed in the context of the class where it was
defined.  If the "config" code generates an error, the variable
is set back to its previous value, and the \fBconfigure\fR method
returns an error.
.TP
\fIobjName\fR \fBisa \fIclassName\fR
Returns non-zero if the given \fIclassName\fR can be found in the
object's heritage, and zero otherwise.
.TP
\fIobjName\fR \fBinfo \fIoption\fR ?\fIargs...\fR?
Returns information related to a particular object named
\fIobjName\fR, or to its class definition.  The \fIoption\fR
parameter includes the following things, as well as the options
recognized by the usual Tcl "info" command:
.RS
.TP
\fIobjName\fR \fBinfo class\fR
Returns the name of the most-specific class for object \fIobjName\fR.
.TP
\fIobjName\fR \fBinfo inherit\fR
Returns the list of base classes as they were defined in the
"\fBinherit\fR" command, or an empty string if this class
has no base classes.
.TP
\fIobjName\fR \fBinfo heritage\fR
Returns the current class name and the entire list of base classes
in the order that they are traversed for member lookup and object
destruction.
.TP
\fIobjName\fR \fBinfo function\fR ?\fIcmdName\fR? ?\fB-protection\fR? ?\fB-type\fR? ?\fB-name\fR? ?\fB-args\fR? ?\fB-body\fR?
With no arguments, this command returns a list of all class methods
and procs.  If \fIcmdName\fR is specified, it returns information
for a specific method or proc.  If no flags are specified, this
command returns a list with the following elements:  the protection
level, the type (method/proc), the qualified name, the argument list
and the body.  Flags can be used to request specific elements from
this list.
.TP
\fIobjName\fR \fBinfo variable\fR ?\fIvarName\fR? ?\fB-protection\fR? ?\fB-type\fR? ?\fB-name\fR? ?\fB-init\fR? ?\fB-value\fR? ?\fB-config\fR?
With no arguments, this command returns a list of all object-specific
variables and common data members.  If \fIvarName\fR is specified, it
returns information for a specific data member.  If no flags are
specified, this command returns a list with the following elements:  the
protection level, the type (variable/common), the qualified name, the
initial value, and the current value.  If \fIvarName\fR is a public
variable, the "config" code is included on this list.  Flags can be
used to request specific elements from this list.

.SH CHAINING METHODS/PROCS
Sometimes a base class has a method or proc that is redefined with
the same name in a derived class.  This is a way of making the
derived class handle the same operations as the base class, but
with its own specialized behavior.  For example, suppose we have
a Toaster class that looks like this:
.CS
class Toaster {
    variable crumbs 0
    method toast {nslices} {
        if {$crumbs > 50} {
            error "== FIRE! FIRE! =="
        }
        set crumbs [expr $crumbs+4*$nslices]
    }
    method clean {} {
        set crumbs 0
    }
}
.CE
We might create another class like SmartToaster that redefines
the "toast" method.  If we want to access the base class method,
we can qualify it with the base class name, to avoid ambiguity:
.CS
class SmartToaster {
    inherit Toaster
    method toast {nslices} {
        if {$crumbs > 40} {
            clean
        }
        return [Toaster::toast $nslices]
    }
}
.CE
Instead of hard-coding the base class name, we can use the
"chain" command like this:
.CS
class SmartToaster {
    inherit Toaster
    method toast {nslices} {
        if {$crumbs > 40} {
            clean
        }
        return [chain $nslices]
    }
}
.CE
The chain command searches through the class hierarchy for
a slightly more generic (base class) implementation of a method
or proc, and invokes it with the specified arguments.  It starts
at the current class context and searches through base classes
in the order that they are reported by the "info heritage" command.
If another implementation is not found, this command does nothing
and returns the null string.

.SH AUTO-LOADING
.PP
Class definitions need not be loaded explicitly; they can be loaded as
needed by the usual Tcl auto-loading facility.  Each directory containing
class definition files should have an accompanying "tclIndex" file.
Each line in this file identifies a Tcl procedure or \fB[incr\ Tcl]\fR
class definition and the file where the definition can be found.
.PP
For example, suppose a directory contains the definitions for classes
"Toaster" and "SmartToaster".  Then the "tclIndex" file for this
directory would look like:
.CS
# Tcl autoload index file, version 2.0 for [incr Tcl]
# This file is generated by the "auto_mkindex" command
# and sourced to set up indexing information for one or
# more commands.  Typically each line is a command that
# sets an element in the auto_index array, where the
# element name is the name of a command and the value is
# a script that loads the command.

set auto_index(::Toaster) "source $dir/Toaster.itcl"
set auto_index(::SmartToaster) "source $dir/SmartToaster.itcl"
.PP
The \fBauto_mkindex\fR command is used to automatically
generate "tclIndex" files.
.CE
The auto-loader must be made aware of this directory by appending
the directory name to the "auto_path" variable.  When this is in
place, classes will be auto-loaded as needed when used in an
application.

.SH C PROCEDURES
.PP
C procedures can be integrated into an \fB[incr\ Tcl]\fR class
definition to implement methods, procs, and the "config" code
for public variables.  Any body that starts with "\fB@\fR"
is treated as the symbolic name for a C procedure.
.PP
Symbolic names are established by registering procedures via
\fBItcl_RegisterC()\fR.  This is usually done in the \fBTcl_AppInit()\fR
procedure, which is automatically called when the interpreter starts up.
In the following example, the procedure \fCMy_FooCmd()\fR is registered
with the symbolic name "foo".  This procedure can be referenced in
the \fBbody\fR command as "\fC@foo\fR".
.CS
int
Tcl_AppInit(interp)
    Tcl_Interp *interp;     /* Interpreter for application. */
{
    if (Itcl_Init(interp) == TCL_ERROR) {
        return TCL_ERROR;
    }

    if (Itcl_RegisterC(interp, "foo", My_FooCmd) != TCL_OK) {
        return TCL_ERROR;
    }
}
.CE
C procedures are implemented just like ordinary Tcl commands.
See the \fBCrtCommand\fR man page for details.  Within the procedure,
class data members can be accessed like ordinary variables
using \fBTcl_SetVar()\fR, \fBTcl_GetVar()\fR, \fBTcl_TraceVar()\fR,
etc.  Class methods and procs can be executed like ordinary commands
using \fBTcl_Eval()\fR.  \fB[incr\ Tcl]\fR makes this possible by
automatically setting up the context before executing the C procedure.
.PP
This scheme provides a natural migration path for code development.
Classes can be developed quickly using Tcl code to implement the
bodies.  An entire application can be built and tested.  When
necessary, individual bodies can be implemented with C code to
improve performance.

.SH KEYWORDS
class, object, object-oriented