This page is now obsolete: TclOO is part of Tcl 8.6.
Do you desire that a single OOP system will be distributed with the core Tcl distribution? (This page is the result of the top-page exchange at Odys Object System.)
Your vote is important!
No, it's not.
This vote will have no lasting impact at all.
Larry Smith: Maybe, maybe not. The man asking the questions, IIRC, is the author of "Jim". Presumably this information will guide his development. That may well have long-term effects on Tcl.
This is all pointless bloviating[L1 ]. Coding matters. Talk is cheap.
You want an OO package as part of Tcl? Start working on a patch.
LV: I agree with this last poster. Both the itcl and xotcl communities have, in the past, discussed getting their packages into the core. However, to date, no one from these communities have taken actions to get the job started.
SS: there is a killer argument about this: if it was a question of a patch, there are already N OOP extensions available, there is nothing to patch, just to add this to Tcl, [package require http]-wise. If instead you argue that no one of the OOP extensions is ok, what is the sane thing to do in your point of view? To build an OOP system in my own without discussion, and provide a patch: I should be so lucky to meet the requirements that a *number* of OOP extensions appear to don't meet.
LV: By patch what is meant is the changes needed to include the extension in the source distribution tar file and have it configure and install when the tcl configure and make process is executed. As for the argument that none of the OOP is okay; my argument is that each OO system written to date has proponents and opponents. This seems to me to indicate that none of the existing OO systems are going to meet everyone's need. If that is the case, then how do we select one to go into the core. The previous attempt to do this appears based on the argument itcl is the oldest, the most used, the most stable, the most familar, the most documented; it should be the one that goes into the core. So a TIP was proposed, a vote was held, and the TIP vote succeeded. (Note that all this occurred quickly - certainly less than a month. So much for the argument that TIPs take too long.) What remains to be done is the actual implementation - the actual patch that sets things up. DKF has several times detailed what needs to be done - I expect the details are here on the wiki and perhaps someone will come along and insert the appropriate hyperlink [here]. I also seem to recall at least one other OO effort talking for a while about wanting their favorite extension in the core. I expect that when someone wants it badly enough to do the work that it takes to get it included, things will happen.
TIPs relevant for the discussion:
If you agree (YES!), write your name here:
Sarnold: (Stéphane Arnold) I use Snit, but am not certain it is the best candidate. I would like to say an OO system should be as simple as Tcl is.
TP: By the way, my Tcl distribution, Tclkit, already comes with a tried and true object system, incr Tcl. and ActiveTcl comes with several OO systems - snit, incr tcl, stooop, and XOTcl.
DKF: though with reservations. I'm not at all sure if I'd accept any currently mainstream offering. (SS: see my comment marked as (1))
Donal, you've mentioned here and below about each offering being somehow not adequate. Can you offer some specifics? The developers are certainly listening. And as you say you do have a vote :) - RT
davidw: I agree with whoever wrote the "don't waste energy" comment below, but in the end, it *must* be the TCT who decide what to do. jcw - (I did) It's not the TCT who decides what to do, I think it's more that they vote on what finished solution to adopt.
RFox: Yes I use snit.
SRIV: I want a blessed OO so I dont have to squint every time I have a need to tweak someone elses code. I want to be able to extend the language in a forward looking way. I use Snit now, and I'll use whatever is blessed. I want my code to outlive some transient OO system. (''so you want a decision made that prohibits anyone from using another OO system? Otherwise, won't you still have to squint every time you have a need to tweak someone else's code?) SRIV No, the existance of OO will encourage more folks to use it. I would not want an integrated OO to exclude the use of other OO systems.
SYStems - Yes but I want XOTcl it's more eXoTickle
MAK: Yes, but I'm not really interested in using a separate package for it. I'd be very happy if there were "standard" OO for Tcl and would very likely use it. But at my current consulting gig, I'm about to have to deal with Tcl code that uses both Itcl and XOTcl, and that's just silly. (So you won't be interested unless OO is available without a package require?)
Artur Trzewik: XOTcl with its features is sure investment for several years. XOTcl in core would make it even better because it could use own special bytecodes for better performance. XOTcl as extension works also very good and is already contained in the ActiveTcl distribution.
DPE: Yes, it would help in marketing Tcl. I've found snit easy to use.
RT: yes I want a "blessed" OO but it doesn't have to be an absolute blessing. Say just that it is the recommended and distribute it with the core and encourage tcllib authors who use OO to use that one. LV what does the term recommended mean in this sense? The XOTcl author has posted demo level code that simulates Itcl in XOTcl; I wonder, can snit be implimented using XOTcl to gain a speed advantage and then save the Tcl version as a fall back?
CLN: Snit works for me. Please, please don't make Tcl an OO language. Let me do OO if I choose (Snit's fine, other options are fine, I guess.). The core should enable (or at least not prohibit) things like megawidgets that appear to be first class widgets (e.g., for geometry and event management).
Vince: Yes, I'd love a standard oop in the core. I might not even use it that much, but making simple structures (stacks, maps, linked lists, etc) and megawidgets should be much easier, and standard -- so I can easily modify/improve someone else's such object without having to learn 5 different object systems.
Larry Smith: Yes. I'd suggest snit.
ZLM: I would use it if it was there... If you build it, they will come.
ramsan: I would like an OO extension very similar to snit, that was very tunned for creating easily megawidgets.
Volker: I'd like to see an object extension but purely for marketing reasons. Personally I have no need for one and I would prefer the extension included in such a way as not to bother us non-oop types.
Drive-By Poster: I vote for xotcl
Vincent Wartelle : Yes ; I use Incr Tcl. One OO extension bundled with core, allowing good OO performance, would be a marketing advance. And maybe through years, a benefit for Tcl reuseability (powerful OO components).
SL: IMHO we need a OO-package distributed with the core Tcl distribution. And this package should be a complete OO-system ready to use.
LV Tcl has existed for quite a while now without a distributed OO system. It has been bearable because of the ease of adding an OO system in. The different OO packages become a problem when one attempts to make use of code trying to use all the various OO systems. I've yet to actually see someone report a problem with this, but it is likely a problem in some cases. However, the current TclOO TIP may not fill all the expectations of someone expecting a "complete OO-system ready to use" they can use in place of Snit, itcl, xotcl, etc.
DKF: TclOO is an object system, but it is not a class library.
If you disagree (NO!), write your name here:
rdt (R. Dale Thomas)
JE: No. SNIT's already in tcllib, which is as close to ``being in the core as it needs to be. So is STOOOP. Should we kick that one out, to make sure there's only a single OO system? Nope, not about precluding multiple OO systems, but saying that one always ships with Tcl. You could get and use others if you want.''
PWQ: OOP has not delivered on any level. All it does is allow unskilled programmers to write crap. It has no place in TCL. (CLN I suppose that depends on how strictly OO you want to be. Surely Tk widgets are objects in some sense. Thank goodness I can do [$buttoninstance invoke] and don't have to do [button $instance invoke] or [button invoke $instance]. I want something (like Snit) that lets me do that with megawidgets. And to the extent that the core needs to be modified so geometry and event management work with add-on megawidgets, I think that the core should and has to be modified. I could care less if I could do OO Tcl (that is not Tk).)
LV: I personally have no desire to see one standard OO package for Tcl be promoted.
AEC: I believe OOP can be a good thing. I also think choice is a good thing. I have not seen an OO system that would satisfy all TCL programmers. My preference would be to leave things as they are. If I want to use someone's code I'll take the time to learn their OO system or convert it to the system of my choice. Yes, choice is a good thing. Does having one that's always available preclude choosing others? If you get the active state distribution you always have snit, stoop and itcl available. If you use tclkit, itcl is always available. Why do we need another OO system built in to the core? If it is built into the core we would risk clashes with the existing commonly used add-ons plus the many personalized OO systems unknown to most of us.
Jean-Luc Fontaine: I want choices. To me, OOP in the core means redesigning Tcl and making all commands OO, a la Tk, but then it would no longer be called Tcl. Not what we're talking about in this discussion; just having one that's always available. Others could still be installed.
Ian Bell: Definitely no. I want choices and flexibility. Having one always available doesn't mean you have to use it. You'd still be able to install and use another.
DDG: No, the core should be as small as possible thereof permitting support for as many platforms as possible. I remember my trouble with porting the Itcl to the starkits for my old OSF1-platform and now I am not using it. And as far as I observed there is no Itcl-support for the older tclkits for MacOS Classic. Adding an OO system to an application is easy. I use almost only Snit but I don't any favourite OO for the community. I like the broad discussion and new ideas. If one OO was in the core before like Itcl we would now not have Snit, Xotcl ... - because many of us would have to stop thinking about OO design. SS: an OO extension is among the most portable things you can put inside the Tcl core, there are no hardware-specific things. If Itcl is hard to port, it's Itcl that has some problem.
Lars H: As the question was posed, the answer has to be "no". I do not desire OO.
ZB - there's no need. "Obligatory" OO in scripting language? What for? There are many variants to choose from already; pay attention, that implementing particular OO system in the core, at the same time you'll depreciate the independent OO packages, those available in Tcllib - just because there'll be a dichotomy: "core OO system - and the rest".
Others:
Richard Suchenwirth: Not sure - I need OO maybe somewhat less than RPN: as playing object for weekends, but not for real paywork. Of all the OO approaches I've seen in Tcl, none has stricken me as fitting the language - in being very simple, yet very powerful.
elb: Richard - I am extremely impressed with the (concept of the) object system in the ical program; see the file class.tcl in the ical sources. It provides a complete object system (inheritance, polymorphism, etc. etc.) in pure Tcl. - ical OO
joh: I would like to see a very basic concept of OOP included with Tcl. Something that replaces (or supersedes) 'proc' with what Tk introduced: A 'widget' that has sub-commands and properties which can be queried and modified. This would give 90% of what you ever need from OOP without any of its troubles and would fit in very nice with what Tk offers. Everything beyond this could be handled by extensions and packages -- you can't get everyone agree on a particular OOP system anyway. The Tk model of pre-OOP objects is well known, easily understood and very easy to use on the other hand. For my taste Tcl should have had deprecated 'proc' with the introduction of Tk and should have offered such a 'widget' command instead for general Tcl (and not just Tk) programming. Well, this is history now, but it would still make a fine language construct useful to all and harmful to none. Including an OOP-extension that only 5% of all programmers use is useless. Make it simple and useful. SNIT is closest to that approach, by the way. SS: Yes, I tend to agree, but I think that Snit can be a starting point for something of better that can exploit the fact that is not implemented in pure Tcl, and use the extra-speed of C to win dynamicity.
SS: (1) in response to DKF: I agree with you, no one of the current offering is good for me. This is why this poll is generic. But if there is a general need for OOP, and at least part of the TCT is interested, maybe something of new/good will emerge.
MR: I think we should talk about this and try to gain consensus for another few years, because that approach has always served us very well in the past. :-)
jcw: Already have it (itcl and snit). Couldn't care less which one gets "blessed" because "$obj method ..." works with any of them. So my OO vote goes 100% to MR. It should be clear by now that any "OO choice for the core" will not happen because an author wants it to happen, but because an audience chooses it to happen. Don't waste energy on discussion or consensus, spend it on finishing the job 100% - if you get it right, you will be rewarded by adoption. If you get it wrong, you will have wasted your time (which is still better than wasting everyone's, IMNSHO).
Peter Newman: Depends what you mean by distributed with the core distribution. If you mean added to the existing monolithic core, the answer is NO (we should be breaking the monolithic core up; not making it bigger). If you mean distributing it as a stand-alone, optional package, the answer is WHY BOTHER?. If it's a stand-alone, optional package, those who want it can add it, whether it's distributed with the core or not.
MR: Peter (and others)... right now given any Tcl install I can pretty much guarantee "package require http" will work (even though its a separate package that could be easily removed). This is about a comparable situation for an object system. Tcllib, or a separate optional package, don't give you that.
LV: So in your mind, OO is more important than Tk; in other words, one cannot guarantee a package require Tk will work on any given Tcl install. It requires a second install. I certainly understand this viewpoint. In fact, if someone believed it enough to do the work, I would support their effort, if they go to the effort of presenting the case for the OO system they want to install.
SRIV: Tk is OO , sockets are tcl objects, so I gladly welcome an OO system that allows me to extend Tcl & Tk in a consistent way, while being fast and lean on memory.
I'm uncertain whether one can look at the results of this page and draw any conclusions, if every time someone adds a comment to their vote, someone else comes along and adds an argument against them. Seems like this would skew the polls results - what if the pollsters in a country ran around the country, asking how people liked the ruling bodies of the country, then argued every time they got an answer with which they disagreed? you would have the US political system.
DKF: Heh! Speaking as someone who actually has a vote that counts in this particular poll, my main reasons for wanting OO in the core are not because we overall lack for OO. It is because other people say we lack OO. (We've actually got embarrasingly many OO systems, most of which are not quite good enough in at least one way.) That we should gain a standard OO system is then not so much a matter of extending functionality, but rather a matter of marketing.
CLN: OK, here's another (slightly different) way to look at it. One of Tcl's great strengths is its extensibility. I've not worked in any other language where you can define your own control structures! So, the key thing for me is not to have an OO facility in the core (though if "other people" think we need one to be taken seriously, that's fine, as long as it doesn't burden me) but to make sure that the core doesn't inhibit or preclude an OO add-on. And (for the third time on this page, I think), I'll note that Tk is semi-object-oriented and it works really well. My comment about being able to implement control structures in pure Tcl has a corollary for Tk regarding creating (mega)widgets in pure Tcl. If I can do event and geometry management in pure Tcl, I'm happy. I don't think we're there yet.
10mar05 jcw - I agree with the above poster ("I'm uncertain" etc... a name would help <wink>) and that this page has become pretty chaotic. The least one can conclude is that it's a hot topic!
IMO, the question was phrased sub-optimally and plenty of people have subsequently mis-understood it. Two key points seem to have been missed, at least in some of the comments made above:
Frankly, I find the no votes quite surprising: "no" against something which you can so easily ignore? Yet which by its mere presence could drive generality and modularity so much further? Even those who do not care one bit about OO can benefit, via packages which evolve towards a more uniform API style - as well as giving package developers more options to tie in with other packages.
Adopting an OO convention will eventually make the core smaller because it helps modularize by supporting different / alternate implementations. Dramatically so in fact: imagine having a couple of hooks in the core, and the regex engine becoming an extension, or the event system, or the file system, or channels. Or list operations, string operations, array operations. It's all open to slicing and dicing once there is a convention.
It feels a bit weird to be arguing in favor of OO, while I'm not that much of an OO zealot... but in the case of Tcl, we really seem to have reached a limit: either one person goes all the way, and submits a ready-to-adopt complete OO system, or we will forever remain divided, indecisive, and arguing about what has then become a completely academic (non-)issue.
Let me summarize it all with - The choice of OO is an order of magnitude less important than the PRESENCE of OO. -jcw
RLH I had voted no above but I removed my comment because I so agree with the summarization of jcw. So say we decided "yes", which one gets blessed? Is it one of the current ones or does the TCT create another?
LV I voted no above, and continue to vote no. It seems to me that with a core OO system shipping, people would either attempt to try, explicitly or implicitly, to force people to use it instead of some other system, or people would ignore it and continue to use their preferred OO system. The first is certainly not an effect that most of the existing OO developers seem to want (unless it is their OO system that is chosen), and the second defeats one of the primary arguments for the OO system.
LV The TCT is NOT a development group; it is a technical administrative group. Certainly it consists of developers; but the intent isn't for people wearing a TCT hat to develop code, but instead to review TIPs for technical applicability. So, the TCT wouldn't create one. And so the question becomes If we do not choose one of the many many current OOs (to which fact so many advocating an OO in the core object), then who decides what goes into the new one, and who designs, writes, debugs, documents, and supports the new one? And of course, what do people think is going to happen to the thousands, or more, lines of code already written in the other OO systems?
MR I like Jean-Claude's summary, and agree with arguments about the network effects of standardization. My biggest argument in favor though is one which would affect few of us here, but it affects newcomers, who we've said we'd like to attract, but who we've done such a poor job with. If people are exposed to another language these days first, its likely OO. When they hit Tcl and ask how to do an object, they're told "there are twenty different ways, go pick the one you like best and use it". I'd run screaming at that point; I don't have the decision making tools to make those kind of decisions. If instead the answer was "package require whatever" (and it'd work because it was installed with Tcl) that's one less roadblock. To try to concisely summarize: Choice in OO is a very good thing (especially for those who are knowledgeable); being REQUIRED to make that choice is very bad (especially for newcomers).
davidw Agree 100% with MR's comments. Choosing between breakfast cereals or even cars is pretty easy. You have most of the information you need, and if worst comes to worst can sell it off. Having to pick a complex tool to use when you don't even know Tcl that well is very difficult, and the fact that you will be locked in to that choice for potentially years to come if you write a lot of code... well that makes it a very big risk indeed.
Here is some academic research that appears relevant: http://www.columbia.edu/~ss957/nytimes.html although they are talking about simple products that do not have network externalities, nor lock-in. My intuition says that the perceived risks in making the "wrong choice" mean that having to choose between OO systems makes some people go over their stress level pretty quickly.
Peter Newman Tcl++ Anyone? Tcl, as originally specified by John Ousterhout, is based on the idea that the first token on each program line is a command - and the remaining tokens are it's arguments. That's an essential feature of Tcl. And it means that Tcl is primarily a command or procedure oriented language.
Now I'm not objecting to OO. And I can't see anything wrong with extending the language to support OO features. But it seems to me that some people want a fully Tcl language - and a fully OO one - in the same package. And the question is, Is that Tcl?
Maybe it would simplify things if we:-
If the existing make system can be - without too much difficulty - reconfigured to allow either a Tcl, or a Tcl++, compile, I don't see why this would be that hard to do. And those interested could start evolving Tcl++ from the existing Tcl core, straight away.
The advantage of this, is that it keeps those of us who want a minimal core - and/or, aren't interested in OO at all - happy. And those who want OO are happy too. They can go for it, without restraint.
It seems to me that Tcl++ would also be good from the marketing point of view (of promoting Tcl). In that it seems to me that the world has gone OO. So Tcl++, a primarily object-oriented language, and an alternative to Python, for example, would surely promote traditional Tcl too. Better to have people switching to and/or using Tcl++, than to have them switching to/using Python or Mozart or Lua etc - and losing sight of Tcl altogether.
Just a thought.
SS The Tcl++ argument is off topic in this page, it is not the aim of this page to know if people want a modified version of Tcl with OOP inside. Instead the aim of the page is to poll the community to check if they are happy if an oop package, like the ones already we have like snit, xotcl, itcl and so on, (or one new, but still in form of optional addition), it's worth to include in the language as standard OOP system. Standard means: you can use what you want, but you are sure that every Tcl install is [package require <OOP-system-selected>] capable.
Peter, I'm not proposing a change to Tcl. Tcl is OO-able (Tk proves it). OO is a package, just like http. Adding it will not change Tcl. -jcw
RLH - Objective-C really didn't change "C" so much as add OO extensions to it. The same could be done with Tcl without changing Tcl itself.
MG adds his two-cents. Personally, I think splitting the language like that would be a mistake. Aside from the fact that I don't really see the need to do so, it sounds like what you're proposing for Tcl++ is a completely different language at the core level - if I'm misunderstanding, and that's not what you mean, though, then again I don't see the need. And if it is.. I see it as a bad thing. All it would really achieve is another language to be marketed, and to be developed, splitting the time and the resources going into Tcl. The OO systems in existence now prove that OO works fine as an addition to Tcl as it is now, without Tcl needing to be totally adapted to include it, don't they?
Personally, I've never used any OO system in my own code, and I probably never will do (though I've run a lot of programs that do use one). But I still think it's worth while adding a single system into the core. It's been said on this page countless times that none of the current OO systems out there are really sufficient - is it any wonder, when there's so damned many? Why not put one in the core and work to bring that single system up to scratch? It seems clear to me that sufficient people want an OO system (the length of this page alone states that, I think) and that it wouldn't really be a huge deal to add one into the core (realistically, I think it would bump the size of the core of very little?). If everyone who wanted an OO system could just 'package require oo' (or just start using it, without even needing to do that?), I think that more people would use it, and it would develop into a more widely usable feature of Tcl a lot quicker than any of the current OO systems are.
SS 11Mar2005: Ok... it's not why I started this page, but it is just a nice side effect: I think that this page shows that snit is the OO system that Tclers like more. Something to consider IMHO. I think there is a reason for this... it's the more Tclish of the available systems. RT - Agreed. Also it is pure Tcl and therefore entails zero platform and build risk which no C level extension can claim - except (to some degree) the "mythical" standard OO should that ever come to pass.
pwq 12 Mar 05, I don't know why people claim that Tk is OO, is it not. At best it is CO (command oriented). Maybe all this OO crap can be eliminated by extending aliases and namespaces to allow more sugar and crap.
LV What people refer to as OO in Tk is the fact that the model for using the extension is this: define an object as a type of class (text, canvas, etc.) and then most of the subsequent actions are invoked as methods of the specific object (text .t ; .t configure ...).
PWQ, not wishing to labour a point, but OO by definition requires a minimum level of features, eg inheritance, polymorphism, function overloading. Since nothing in Tk comes remotely close to achieving the above it would be erroneous to state that Tk is OO.
If People wish to debate OO in TCL then they should have a good understanding on what they are actually arguing for. There must be a consensus reality before the Poll can be meaninful.
SS: Of course PWQ is right, but I think that being Tk "object based", or "command oriented", or how we want to call it, i.e. widgets are some form of object unable to ihherit, but in some way resembles in the trivial case of what can be a method call in an OOP system for Tcl, i.e $obj method argument. After all command based interfaces in Tcl *are* polymorphic, i.e. if I pass to a Tcl procedure a command that can accept a given set of subcommands, I can implement this command in N different ways and algorithms but as long as the interface is the same the procedure can't tell the difference. Btw that's an interesting point: if Tk is already comfortable to use, without to be truly OOP, I think that a real OOP system if designed well (command oriented interface + simple + dynamic) can be a huge help for the Tcl programmer, when the problem to model is OO friendly. PWQ SS:, I would have to disagree. Polymorphism is the ability to dispatch to differing procs based on the arguments. This is not possible in TCL.
NEM: No it isn't. Polymorphism [L7 ] is the ability for the same code to work with arguments of different types. Tcl clearly handles this very well, as everything is a string. If you want to add strong typing to Tcl you could do so (for instance, via an OO system...), and there is absolutely nothing to stop you implementing type-based dispatch.
PWQ NEM:, Far be it for me to disagree with Wikipedia, but by that definition any language that allows variables of type variant (ie VB, PHP, unix shell, awk) are polymorphic, doesnt sound rigth to me.
NEM: Perhaps you'd prefer foldoc then? [L8 ] I think you are perhaps referring to ad-hoc polymorphism (or overloading [L9 ])? But, none of this is really relevant to this page.
SS: My impression is that the meaning of polymorphism changes as the context changes. It's not a precise term even if the origin appears to be what NEM said. I think that in the context of OO, polymorphism is the ability of multiple objects to have the same interface, but different implementations, and still the user (being it a function, or a programmer), don't need to know about the deatails of the implementation because as far as the interface is the same it can be used in the same way. In this regard, a command-based object system for Tcl is very important as objects and commands with the same interface are impossible to distinguish, and such an OOP system can use Tk widgets in objects composition in a very natural way. Even if Tk widgets are not real objects they "behave like" objects as long as one does not try to inherit from they, or to inspect the internal state using particular methods or commands of the object system.
CMcC 12Mar05 - this seems to me like a no-brainer, really. I think the benefits to tcl of standardising on a good OO system are great.
The closer a standard OO system comes to being pure tcl, the better: pure tcl implementation gives the OO system flexibility. However, tcl is not yet capable of supporting any efficient OO system because tcl ties a proc's variable resolution scope to its definition scope.
The most promising directions (politically and technically) seem to me to be extensions to tcl which facilitate pure tcl OO systems by solving the problems which all OO systems must necessarily overcome.
LV I agree with CMcC here. A similar useful thing is this - one of the most frequent requests within the scope of the 'need for an OO' discussion that occurs so frequently is 'so that megawidgets can be more easily created'. However, we've seen the discussions this week that Tk isn't really OO. So perhaps we don't really need OO to provide the megawidget structure so frequently desired.
RS: Also, I think "Tcl as it is now has no OO" is just a misconception. Apart from extra features (inheritance, dynamic change of classes) and syntax sugar, basic OO with classes, methods, objects, instvars can be had in Tcl without any fancy framework - witness Skeleton OO, A little IO stack, or Tiny OO with Jim.
CMcC Yes, Tcl has no OO is wrong. Tcl has as twice as many OO implementations as there are people with strong opinions on how best to do OO (each such person implements two OO systems on average :)
The best thing to do is find ways to make them all better.
MR: No. For newcomers to the language, who try to use it as part of whatever standard distribution is on their system, Tcl has no OO.
RS: As I wrote a bit higher up, zero-framework OO is easy with standard Tcl without any extension:
These two are needed for a class, and then you can merrily go:
set ob1 [myClass] ;#-- constructor $ob1 sing Hallelujah $ob1 dance polka namespace delete $ob1 ;#-- destructor
MR: Try to think like a newcomer to the language (who nowadays if they've done anything with another language probably expects OO is there). Understand you're asking them to build infrastructure to do this, use features like namespaces etc. Think how a newcomer would react to that. Sure, some might be ok with that. But most? Come on.
LV: Mark, I agree with you on this point - expecting a newcomer to develop the software on his/her own is not realistic.
The following is off-topic, I know. But from the worldview that MR describes, I would suggest that this user should only be using a Batteries Included distribution anyways. At least the two or three most popular BI distributions come with a small portion of the infrastructure that a developer would expect to already be there. And if they do use the BI, then of course they will have 3-4 OO systems from which to choose. So perhaps what is needed, in the BIs, is an article comparing/contrasting the OOs included.
MR: Yes this user should be using a BI distribution. Are most newcomers running into Tcl via a BI? (Not sure, but my guess is no.. e.g. Linux distributions, OS X). So, to not turn off the newcomers (as per above) our choice is either we get BI installed in such places by default, or make the standard distribution which is being installed now have a few more pieces. Third option is status quo of course. All have different consequences on different classes of users.
If they're already using BI, when they ask "how to do OO?" you just say "package require whatever"; later on after they've got their feet wet, they can choose if they want to. But as I said earlier, forcing them to choose up front is not a good thing.
RLH - Actually on OSX I use Tcl/Tk Aqua [L10 ] which has a BI install, which has Snit [L11 ].
LV Sounds like this is something productive - we need to get contributors to SuSE, Debian, RedHat (or whatever it is called these days) and a number of others to sync up to including a set of extensions; probably a set comperable to ActiveTcl and that Aqua distribution.
Then, perhaps, someone can write one or more special extension-oriented chapters for the new Tcl tutorial that's being worked on for Tcl 8.5. The chapters wouldn't, of course, ship with Tcl; they would be a part of the extensions but perhaps the installation process for the extensions could install them into the right spot.
CMcC There's no blessed OO system, sure. This is a problem (if it is a problem) with both technical and a political causes: technically there is no clear winner (because there are so many countervailing and orthogonal criteria of quality), politically it's a quagmire.
I think, though, the politics would be easier if the technics were solved.
DKF: If it wasn't for the political quagmire, I'd vote for leaving the technical quagmire well alone.
Sept 26,2005 SRIV Time to discuss "TIP #257: Object Orientation for Tcl"
IL: Is it me or did #257 just come out of nowhere? My vote is for, "I don't know?" From practical experience, most of my object modeling doesn't go beyond 2 layers deep, and how you use it really depends on the language. I appreciate the flora that is object-based programming in general. I think Javascript's prototype construct is a nice happy medium that gives you something to encapsulate with, without drenching you in the overrought architecture that can be OO programming.
I think any discussion of OO needs to address exactly how this system will work conceptually with Tcl. How does it enrich its essence as opposed to just clutter it? Maybe that's done here, maybe it's described in the TIP, maybe an Xotcl user implicitly understands it all, but I'd like to see one concrete item that says to me, this is indispensable as a feature. If it isn't, why bother?
I'd suggest looking at the following for those who are unfamiliar with how prototype works. As far as an object system, I'd be happy with the inclusion of a TCL prototype. [L12 ]
LV It's just you! ;-) Seriously - people have argued about including OO in Tcl for years. And when people have proposed taking the code from one of the OO extensions and integrating it into the core, proponents of competing OO extensions have protested.
The new TIP seems, to me, to be a compromise - get functionality into the core, so that existing a new OO extensions can be more cleanly developed. Leave the door open for including OO in the tcl distribution for a year.
RLH: You know, hooks into the core might be the way to go actually. I wonder if the OO extensions would get a speed boost using something like that?
escargo - It now seems to me that a prototype-based object system is closer to the Tcl way of doing things than a class-based object system. I have wanted an object system for polymorphism and inheritance-like behavior.
If I wanted a class-based system, I'd probably be using Smalltalk.