I have noticed, in discussions of OO under tcl, a tendency to confuse Objects and [Megawidget]s. This page is to discuss similarities and differences betwee n the two concepts. While it's tempting to see the similarities (e.g. encapsulation,) there are also possibly significant differences (e.g. composition.) ---- [MSW] Mind explaining how megawidgets differ in composition from objects ? Actually our (plain) widgets -are- objects (you create an instance and use an instance-command approach to talk to them, while the behaviour is defined inside the 'class') ... ---- It's my belief that if a given OO system happens to be perfect for Megawidgets, that's a happy coincidence, but I have a nagging suspicion that one of the historical reasons OO hasn't taken off in tcl is that it keeps getting confused with the needs of Megawidgets. If there was an excellent OO and an excellent Megawidget system, it wouldn't bother me as much as if one had to be distorted to suit the other. -- 4Dec04 [CMcC] ---- 4Dec04 [SRIV] A question to those of you that have made OO or megawidget frameworks, is it possible to have a unified system that can create objects AND widgets AND types while maintaining the feel of tcl? Discuss.. 4Dec04 [CMcC] almost all of the well developed OO systems are extended to provide megawidgets, so I don't think you can answer your question before asking what 'maintaining the feel of tcl' means, and that's a very big question. The question, here, is about significant differences between what the perfect OO system needs, and what the perfect megawidget system needs. I think that question needs an answer before we can really talk about ''unification''. 2004-12-04 [MSW] For OO Systems, I think the answer is that the system should be flexible enough to allow mapping the different styles of OO thinking within the very same system (as e.g. OTcl / [XOtcl] do) -- kind of like said about [Lisp] at [http://www.paulgraham.com/avg.html]. For Megawidget systems, what else is needed but being able to both use megawidgets the same as you do with plain widgets (create them, use a method like approach to access commands in the instances [[ like for plain tk widgets ]]) as well as being able to build bigger megawidgets with plain tcl code ``or`` OO code from existing mega- as well as plain widgets ? ---- Question by [SRIV] re-added by [MSW]: Another question: If I define a widget in a tcl OO system, why do I have to use the "method" keyword instead of proc? Can't it "do the right thing" and know that I'm defining a method and make it behave as such, without having to use a redundant keyword? The proc would be private to the widget/object, unless explicitly exported, as in namespaces. [MSW] answers: "method" (or "instproc" or whatever) is needed for the distinction of instance vs. class methods / state. ---- [SRIV] mentions that the nomenclature of OO systems (specifically [method]) can be intrustive if what you want to do is define a megawidget ... perhaps thinking of a name which is more connotatively consonant for a widget would emphasise some of the differences in thinking about megawidgets and conventional objects. [MSW] answers: why ? If you're defining megawidgets in an oo-system, why would you want to not use the oo-system to define the megawidget ? [SRIV] Because there is no official OO for tcl yet, so, why cant tcl's future OO be smarter than whats available today? I understand that conventional OO languages or tcl extensions "need" instproc or method, I'm just trying to get a consensus on whether a future tcl OO system can be made lighter, more coherent and more tk like. Either I, as a non-OO programmer other than tk, am oversimplifying OO, or OO programmers are blinded by their past learnings. I find it hard to believe that theres only one paradigmn for OO in this world. 2005-03-29 [SRIV] I just tried out itcl to see if I could make a tk widget. Using gButtons as an example, I found that I can make something that almost works like a Tk widget. In looking at the megawidget building commands in tclkib and mkWidgets and my guess is that someone could easily re-implement them using itcl at the core class mechanism. The advantages would be : * high speed due to a c based OO core * low memory usage compared to tcl based class system like snit * itcl has been TIP'ed into the tcl core * itcl is already in tclkit