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[1]. 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:Salvatore SanfilippoSarnold: (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 :) - RTdavidw: 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 eXoTickleMAK: 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.Neil Maddenramsan: 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 xotclVincent 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 OOjoh: 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:
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:-
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:
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. [12]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.
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[1]. 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:
- TIP #6
- Include Incr Tcl in the Core Tcl distribution (Rejected) [2]
- TIP #50
- Bundle incr Tcl with the Core Tcl distribution (accepted but Deferred) [3]
- TIP #81
- incr Tcl Functional Areas for Maintainer Assignments (Deferred) [4]
- TIP #180
- Add a Megawidget Support Core Package (Draft) [5]
- TIP #257
- Object Orientation for Tcl (Draft) [6]
If you agree (YES!), write your name here:Salvatore SanfilippoSarnold: (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 :) - RTdavidw: 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 eXoTickleMAK: 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.Neil Maddenramsan: 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 xotclVincent 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 OOjoh: 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:
- having OO in the core does not force anyone to use it, nor prevent anyone from using something else
- having one OO always available will definitely help simplify other parts, as well as help modularize it
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:-
- Kept the existing, primarily command-oriented, traditional Tcl - with optional OO extensions - as it is, and;
- Created a new combined Tcl+OO language - Tcl++, for example - that combines the two concepts. Like C and C++, for example.
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:
- A constructor for a class is a proc that creates the object's namespace, arranges for its alias, and does what other constructors do (initial settings).
- A dispatcher is a proc aliased to from object's names that either contains the methods in its belly, or really dispatches it to separate method procs.
set ob1 [myClass] ;#-- constructor $ob1 sing Hallelujah $ob1 dance polka namespace delete $ob1 ;#-- destructorMR: 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 [10] which has a BI install, which has Snit [11].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. [12]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.
