Purpose: to define what a 'nice object system' should look like, if included
in the Tcl core.

Initially, here are some comments, dated Jan 22, 2001, by Donal K. Fellows:

  lvirden@yahoo.com wrote:
  > According to William H. Duquette <William.H.Duquette@jpl.nasa.gov>:
  > :For Tcl to catch up, it needs two things:  a nice object system,
  > :and a substantial standard library that's pre-installed.
  >
  > Okay, let's start the work on defining what these two things should look like,
  > what gets included, work out the details to get these to build cross platform
  > and DO IT.

  Agreed.  (And I agree with Will; those two are enabling technologies,
  much more so than many other things.)

  > 1. What constitutes a 'nice' object system?  What needs to be present, what
  > shouldn't be present?  What could we put into Tcl to make the jobs of the
  > N Tcl OO extension writers easier and that, when used, won't irrevocably
  > break Tcl for them?

  I think that whatever we settle on, it should be class-based and it
  should have support for both anonymous and named objects.  Objects must
  be able to have both methods and variables.  It is probably a good idea
  to have constructors (I've worked without them, and it is a pain) but
  I've no idea if we need destructors or just plain deletion traces.  No
  method, constructor or destructor invokation that causes an error inside
  itself should make that error vanish.  It should be easy to [vwait] or
  attach using -textvariable to an object variable.

  Why class-based?  Because that's what almost everyone wants in an OO
  system.  I know they aren't strictly needed, but meeting everyone's
  expectations here is probably a good idea.

  Why both anonymous and named objects?  Both have their uses; named are
  at their most useful when working with interactive input, and anonymous
  are ideal inside scripts, particularly if they can be automatically
  garbage collected (though that requires substantive improvements to the
  interpreter.)

  Why constructors?  Well, if you omit them, you just have to reimplement
  them in an ad hoc fashion.  :^(

  Why not destructors?  It all comes down to whether a destructor can be
  called multiple times and whether it can abort object destruction.  By
  comparison, an object deletion trace has none of this nasty conceptual
  baggage.

  Why must errors not vanish?  Debugging.  'Nuff said.  Any exceptions?
  Class deletion.  Maybe.

  Why easy variable traces/linking?  Experience shows that this is a
  very useful feature indeed, particularly for properties dialogs.  No
  sense in requiring yet another ad hoc reinvention of the wheel.

  I'm not at all sure that class "static" methods and variables are a
  good idea.  Maybe, but maybe not.  They can cause a lot of trouble.
  Allowing objects to have extra variables not listed in the class
  definition seems to be a much more useful feature to me, and more in
  keeping with Tcl's current philosophy, as expressed by procedures.

  We need good introspection; listing of all classes, listing of all
  objects in a class, listing of all methods in a class, listing of all
  variables in an object, etc.

  And whatever we do, it should become the One True Way Of Doing Objects
  In Tcl.  Anything else will just produce yet another irritatingly
  incompatible OO extension.  Like we need extra.

  > 2. What constitues a 'substantial' library?  I assume this must be some
  > number of functions larger than tcllib, right?  How many?  And, next, as
  > for 'standard', what does standard mean?  What standard?  POSIX?  Or do
  > you mean, by standard, "commonly available"?  If the latter, what common
  > needs are currently unmet by what comes with Tcl ?  I know what that
  > involves for me - but I don't know if that is the same as for you.  Are
  > we talking about taking a set of existing extensions, modifying them
  > until they all 'play nicely' and then shipping one monster sized tar file?
  > Or what?

  Must-have: Easy way of using a large collection of packages (maybe even
  hierarchically named packages.)  Perl seems to have some good ideas in
  this area (I don't know Python) and I see no reason not to learn from
  their experience.  Must be fairly easy to write a package.

  Nice-to-have: Way of downloading packages from the 'net.  Standardized
  indexed documentation scheme.  Masses of stuff, platform-independent,
  platform-dependent, even OS-dependent; the more the merrier!  A way to
  combine documentation and code in a single file (like POD) would be
  good.

  > The faster and more specific we get, the sooner someone can write up TIPs,
  > begin working, etc.

  Absolutely.

  Donal.

----

I recommmend that OOP Tcl support the following standard OOP features:

   * Inheritance
   * Interfaces
   * Constructors (Constructors with multiple signature support is preferred)
   * Destructors or somekind of finalize method call when the object is unloaded from memory.
   * Multiple method signature support or method overloading. This is support for methods of the same name but with different input parameters.
   * Method overriding. This is when an inherited class overwrites a method in the superclass. This is known as polymorphism.
   * Finalize support. This adds security to prevent an inherited method from overwriting a superclass variable or member when needed.

Scott Nichols