Mochael J. McLennan
top 10 Myths about incr Tcl
10. only good to building toasters
good for packaging
9. If I don't need it I don't need it
Namespaces - declare namespace and declare local variables inside it e.g. help::topics ( help is the namespaces)
conmpose namespace from inporting existing ones (public or protected mode)
Ensembles- supports complex command structures, extended with new options
8. Multiple interpreters are running rampant
proper namespaces instead of multiple interpreter
7. Too slow and requires too much memory
improved
6. Can't integrate c/c++ code
not true anymore
5. Doesn't support interactive development
separate interface and implementation
4. Just another megawidget package
help-page object plus inheritance to create useful object like html
3. Inheritnace is silver bullet
2. Composition is a silver bullet
both are needed, use where appropriate
1. Johs say it's going into the core!
Pedja Bogdnovich
ann oo extendsion to tcl modeled after objC, NExtStep object based on ObjC
ObjC- smalltalk paradigm, small extension to C, dynamic message dispatching (message bound at runtime)
basic functionality - access obj from interpreter, create classes and implement methods in the interpreter
ObjC is compiled. Otcl extends ObjC at runtime.
Tcl "message" statement - $obj msg , $obj msg: $param
Registering objects
"Object" creates a object and returns a handle: set obj [[Object something] init]
Creating classes and implementing methods
four new commands: class class superclass ivars methods
category clsname categoryname methods
method rettype methodname+ args ... body
super message
Types are required for methode prototype
Runtime support: multi-interprter support
provision for associating object with interpreters
errror system
passing error fro objc to tcl
debugging support
unhandled error catching
crash catching of compiled code
dynamic loading (compiled code)
load classes
intermixing tcl classes and ObjC classes
autoloading (compiled and interpreted code)
object persistence and typed stream support
I interactors and shells (tty and AppKit)
David Wetherall, Christopher J. Lindbald
The VuSystem & Otcl
vusystem developed by cjl and TNS group
compute-intensive media application,
uses to Tcl to combine C++ media objects
interactive interface needs led to Otcl
a visual programming interface
Otcl features:
program styles
inheritance
per object specialization, class meta object
aautomatic method combination
allows true mixins (uses topological sort)
use next pointer to combine classes without dependency
object specialization
can add methods, instance variables to each object
class meta objects
classes are objects too
classes also managed
implementation
object == command stored in interpreter
method == tcl proc + three hidden variables
instance variable == tcl upvar to hidden location
Mixing Tcl and C/c++
C interface to object
prior version tied C++ classes to Tcl
autoloading aside
shadowed methods, superclasses want to be autoloaded
demand load methods and classes
oo programming in tcl should look and feel like tcl
ftp://ftp.tns.lcs.mit.edu/pub/otcl
Dean Sheehan
mission
make C++ classes available to interprted language
subclassing
member function invocation
object creation and deletion
use tcl
provide oo concepts
component
CDL - class description languague
Otcl - Object Tcl Language
CDL - basially an IDL
describe construtor (argument types), member functions, static member functions
Otcl
extends tcl with the basic oo concepts of classes, object, etc.
Otcl - Interface
separateds a class's interacr from implementation, describe public accessible
features, supports multiple inheritance
Otcl - Implementation
describe internal behaviour constructors, destructor method attributes
Otcl Objects
otclNew creates objects return objRef
otclDelete deletes a reference
Otcl Methods
Class methods
$objRef methods
Miscellaneous
this is available
public or private methods
inherit from c++ classes exported to otcl via CDL
multiple inheritance
methods are inherited
methods may be redefined
version 1.0 imminent
Otcl-DP
marries C/++ and tcl and maintain benefies of both
Mark Roseman
not yet another oo extension!
Groupkit Environments
shared data structures btw mutiple conference processes (replicated)
need some for of concurrency control
tcl-level oo api e.g. tk widgets
desired extensibility -
analog to Tcl_CreateCommand for C
analog to proc for Tcl
fluid nix of tcl and c as appropriete
highy dynamic
deep customization
Typical extension structure
extensible extension structure
subcmd handler table - primitive and user-level handlers
core data and operations
build user level operation in terms of primitives
manipulation subcommands
held in internal table
commands to inspect and change
adding subcommands via tcl
spcify code, env_exists
myEnv command set exists env_exists
radical changes
add new subcommands
wrapper around existing subcommands
delete existing subcommands
replacing underlying implementation
objects can be individually extend at runtime
what about abstration??
Meta-level architecture in dynamic languages
abstraction can hide details but often speed or space considerations
keep abstraction but allow getting inside
traditon api
adjustion api -- command set, etc
building objects need not involve objects
extension should be customizable