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:
[email protected] wrote: > According to William H. Duquette <[email protected]>: > :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:
Scott Nichols
NEM This sounds suspiciously like java. Interfaces are nice in Java, but I'm not sure of there usefulness in Tcl. For a start, interfaces seem to be a concept that only really applies in typed languages. In Tcl it seems easier to just document interfaces. If an object doesn't supply a particular method, then trying to access it will throw an error which can be dealt with. Interfaces in Java tend to be most useful as a compile-time check to make sure that you've done everything you were supposed to. I don't see how Tcl could do that (having no separate compile phase), and so the interface checking would have to be done (and throw any errors) at runtime -- which is pretty much the situation we currently have.
Having multiple method/constructor signatures seems to be mostly used for passing different sets of arguments. Tcl has a couple of ways of solving this:
There are probably other methods. "Method signatures" conjures up images of a typing system again, which isn't Tcl.
Finalize support -- I assume you mean the Java "final" keyword here? I always thought this was just to allow compiler optimizations, and had little practical value? RS: We have simple ways of guaranteeing constants - again, only at runtime, of course.
As for inheritance, I've become quite attached to snit recently, which prefers delegation over inheritance. Both seem to be useful in places.
The original quoted posting from Will Duquette stated that we needed two things: an object system, and a standard library. Will has created snit, which is an excellent object system (but maybe not the best object system), and that is now in tcllib - which is an effort to create a standard library. So, I think Tcl isn't quite so far behind other languages, except in perception.
Actually, the original statement from Will, quoted about, says "> :For Tcl to catch up, it needs ... a > :substantial standard library that's pre-installed." > :^^^^^^^^^^ ^^^^^^^^^^^^^
Tcllib, unfortunately, only meets one of the 3 criteria in this statement - it is considered, by many, to be a standard library. It does not come pre-installed with Tcl (the topic which was at hand) and what is there, while greatly appreciated, has a ways to go before it has the amount of substance that Perl or Python's libraries have. However, that is really a topic for another wiki page.
Some good examples for object system. Not C++ and Java that are really not good example for Tcl.
They all are not typed languages.
Peter Lewerin: the languages in this list use dynamic instead of static typing, but they are certainly typed languages.
Artur Trzewik I confes it is true. Smalltalkers say: "It is implicit typed". The interpreter tests internal every object call (by doing so called method dispatching). In opposite: "not typed langauge" is for example assembler. C,C++ programms can access with pointers not proper memory or send call to nirvana. In this way Tcl or Smalltalk are more "typed" or better "type safe" as C or C++.
I do not expect that "Tcl'ers first days guy" could develop new good OO-System for Tcl. They are absolutly C oriented (or C++ polluted) and most of them says that Tcl do not need OO. (consider theory of paradigm change). On the other side there are enough good external Tcl OO-System (in my opinoin the best one is XOTcl) that suffice more then most Tcl'ers can image (see above). It is absolutly possible to develop OO in Tcl now, but I would not expect it will be put in Tcl Core. It were also not good.