I have noticed, in discussions of OO under tcl, a tendency to confuse Objects and Megawidgets. 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 [L1 ]. 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 ?