Xotcl

xotcl@alice.wu.ac.at

2 participants
653 discussions

Updates for XOTclIDE and Xdobry
by Artur Trzewik 13 Jul '04

13 Jul '04

Hi There is new version 0.61 of XOTclIDE ready on: http://www.xdobry.de/xotclIDE Changes: - new plug-in. I18N (Internationalization) Helper that can scan sources after msgcat-library expresions, helps by translation and produce msg-catalogs. - support of Oracle and MS Sql Server as version control database - small bug-fixes - requires Tcl8.4 Xdobry (database tool) in version 0.40 contains new features: - can be used as database schema creation and manipulation tool - can migrate data between all supported databases - can dump databases to xml-dump and import it to every supported database. - many bug fixes and refactoring - supports: MS Access, Oracle, MS SQL Server - updated documentation - requires Tcl8.4 - deployed also as starkits for windows and linux. Artur Trzewik

1 0

Checking to see if a class is defined
by Adam Turoff 25 Jun '04

25 Jun '04

I'm creating a test suite for an XOTcl class I'm writing, and I want to test this sequence: (1) MyClass is undefined (initial state) --- package require MyClass succeeds (2) MyClass is defined (expected state after loading the package) (3) MyClass isa ::xotcl::Class (4) MyClass has methods x, y, z However, I am not having any luck in testing #1 and #2. Is there any kind of introspection that can help me determine if a class is defined? Using [info exists MyClass] doesn't seem to work. Thanks, -- Adam

3 3

RE: XOTcl as a megawidget framework
by Schofield, Bryan (GE Transportation) 10 Jun '04

10 Jun '04

For anyone that is interested, I've been working on the option handling stuff a little more. The original method of adding tk configurable options is still available, but is now done via the [tkoption addexplicit] command. The new [tkoption add] takes a type and a source object (XOTcl, TK, or other depending on the type) and a series of options. This allows options to be added more easily. tk option add tkwidget $widgetpath.foo \ -except { yscrollcommand xscrollcommand } \ -translate { background listbackground } As I'm thinking about this, I think it might be a good idea to extract the tk option handling code in to it's own class for better reusability, maybe ConfigurableOptionManager or something. -- bryan > -----Original Message----- > From: Schofield, Bryan (GE Transportation) > Sent: Tuesday, June 08, 2004 8:53 AM > To: 'xotcl(a)alice.wu-wien.ac.at' > Subject: XOTcl as a megawidget framework > > > Hullo - > > This is my first posting to this mailing list. I recently > started playing around with XOTcl. I had been using IncrTcl > for quite a while, but XOTcl has seemed to get a lot > publicity in a few other mailing lists, so I decided to give it a try. > > My first impression of XOTcl is very good. I'm finding myself > growing very fond of how classes are defined in XOTcl and I'm > loving the dynamic nature of classes and objects in general. > Though I have to admit, the "instproc", "instvar", and "my" > took a little getting used to and I do miss the protection > levels available in IncrTcl, but only a little. Anyway, > that's not the real reason I'm posting. > > Has any work gone into making a TK megawidget framework with > XOTcl? I spent a little time and came up with a couple of > classes that make this possible. Even though this is just a > prototype, I'd be very interested in getting some XOTcl'ers > feed back on this. > > I've attached a file called xowidget.tcl that contains the > megawidget framework package and an example of using it, > SearchableListbox.tcl. > > This package, which I've cleverly been calling "xowidget", > provides the ability to create an XOTcl object that behaves > like a TK widget. It also provides Snit-like method & option > delegation to the basewidget, subcomponents, and other > objects. Furthermore, the method & option delegation can be > multiplexed such that a method or option is propogated to > multiple objects and/or tk widgets. I've tried to document > how to xowidget in source file, but if something is missing > or not clear, please feel free to ask me. Here is a small > example of what the syntax is like. > > > > WidgetClass LabeledButton \ > -tkwidget frame \ > -parameter { {foo bar} } > LabeledButton instproc init args { > next > my instvar widgetpath > # create a label and button in the frame > label $widgetpath.l > button $widgetpath.b > pack $widgetpath.l $widgetpath.b -side left > > # make the foo parameter an configurable option > my tkoption add foo parameter -object [self] > # add borderwidth & relief option for the basewidget > my tkoption add frameborderwidth widgetproc \ > -object [self] -asoption borderwidth > my tkoption add framerelief widgetproc \ > -object [self] -asoption relief > # add option for the text on the label > my tkoption add labeltext tkwidget \ > -widgetpath $widgetpath.l -asotion text > # multiplex background option to the frame, label, and button > my tkoption add background widgetproc -object [self] > my tkoption add background tkwidget -widgetpath $widgetpath.l > my tkoption add background tkwidget -widgetpath $widgetpath.b > # wildcard all other options to the button > my tkoption add * tkwidget \ > -widgetpath $widgetpath.b > > # make the foo parameter command available > my tkcommand add foo > # wildcard all other commands to the button > my tkcommand add * "$widgetpath.b" > } > pack [LabeledButton .lb -labeltext Foo -text "Press me" > -command doSomething] > puts [.lb configure] > .lb invoke > .lb foo "ack" > > > > I'm very open to suggestions and comments, critical or > otherwise. If there is some interest, I'd be open to > enhancing this expiriment to something more. > > Thanks in advance. > > -- bryan >

1 0

XOTcl as a megawidget framework
by Schofield, Bryan (GE Transportation) 08 Jun '04

08 Jun '04

Hullo - This is my first posting to this mailing list. I recently started playing around with XOTcl. I had been using IncrTcl for quite a while, but XOTcl has seemed to get a lot publicity in a few other mailing lists, so I decided to give it a try. My first impression of XOTcl is very good. I'm finding myself growing very fond of how classes are defined in XOTcl and I'm loving the dynamic nature of classes and objects in general. Though I have to admit, the "instproc", "instvar", and "my" took a little getting used to and I do miss the protection levels available in IncrTcl, but only a little. Anyway, that's not the real reason I'm posting. Has any work gone into making a TK megawidget framework with XOTcl? I spent a little time and came up with a couple of classes that make this possible. Even though this is just a prototype, I'd be very interested in getting some XOTcl'ers feed back on this. I've attached a file called xowidget.tcl that contains the megawidget framework package and an example of using it, SearchableListbox.tcl. This package, which I've cleverly been calling "xowidget", provides the ability to create an XOTcl object that behaves like a TK widget. It also provides Snit-like method & option delegation to the basewidget, subcomponents, and other objects. Furthermore, the method & option delegation can be multiplexed such that a method or option is propogated to multiple objects and/or tk widgets. I've tried to document how to xowidget in source file, but if something is missing or not clear, please feel free to ask me. Here is a small example of what the syntax is like. WidgetClass LabeledButton \ -tkwidget frame \ -parameter { {foo bar} } LabeledButton instproc init args { next my instvar widgetpath # create a label and button in the frame label $widgetpath.l button $widgetpath.b pack $widgetpath.l $widgetpath.b -side left # make the foo parameter an configurable option my tkoption add foo parameter -object [self] # add borderwidth & relief option for the basewidget my tkoption add frameborderwidth widgetproc \ -object [self] -asoption borderwidth my tkoption add framerelief widgetproc \ -object [self] -asoption relief # add option for the text on the label my tkoption add labeltext tkwidget \ -widgetpath $widgetpath.l -asotion text # multiplex background option to the frame, label, and button my tkoption add background widgetproc -object [self] my tkoption add background tkwidget -widgetpath $widgetpath.l my tkoption add background tkwidget -widgetpath $widgetpath.b # wildcard all other options to the button my tkoption add * tkwidget \ -widgetpath $widgetpath.b # make the foo parameter command available my tkcommand add foo # wildcard all other commands to the button my tkcommand add * "$widgetpath.b" } pack [LabeledButton .lb -labeltext Foo -text "Press me" -command doSomething] puts [.lb configure] .lb invoke .lb foo "ack" I'm very open to suggestions and comments, critical or otherwise. If there is some interest, I'd be open to enhancing this expiriment to something more. Thanks in advance. -- bryan

1 0

xotcl namespace auto-import
by Neil Madden 27 May '04

27 May '04

Hello all, Small feature request: could XOTcl be made to automatically [namespace import] the ::xotcl::* commands into every object it creates? I'm trying to write a package using XOTcl, and so don't want to import XOTcl into the global namespace. As Tcl's command resolution rules are current namespace then global namespace only, I can't just import it into my package namespace, as all objects (which are sub-namespaces, AIUI) would skip the containing namespace when resolving. So, I have two options: 1) Fully qualify everything - lots of xotcl::my, xotcl::self etc everywhere 2) Import xotcl namespace manually into each object namespace. 2 is better than 1, but is still a bit of a pain to remember to do, and I seem to remember trying it and it not always working (I could be wrong about that). So, my feature request would be that all Objects [namespace import] the xotcl namespace automatically.[1] Cheers, Neil. [1] [namespace import] is actually quite expensive as it creates commands in each namespace which forward on to the originals. Possibly if XOTcl is already hooked in to Tcl's resolver APIs for method dispatch/inheritance, then the xotcl namespace could just be added as a final search path (after xotcl::Object).

3 4

Re: [Xotcl] Mixins in XOTcl
by Adam Turoff 24 May '04

24 May '04

Uwe Zdun wrote: > what about just extending the usually interfaces with new > arguments, such as: > > A mixin X > A mixin add Z 3 > A mixin add Y end > A mixin delete Y > A instmixin add T 1 > A superclass B > A superclass add C That's pretty much what I was thinking: A mixin X ;# current behavior A mixin -set X ;# A mixin X A mixin -set X Y Z ;# A mixin {X Y Z} A mixin -add X ;# A mixinappend X Using -set, -add and -delete feels more Tcl-ish. Also, it is somewhat bad style to name a class 'add', but even worse style to name it '-add'. By using options, I can still mixin a class 'add' into a definition. Preventing me from mixing in a class '-add' is a good idea, for other reasons. -- Adam

2 1

Re: [Xotcl] Mixins in XOTcl
by Adam Turoff 22 May '04

22 May '04

You wrote: > > Object instproc insert_mixin {mixin_list} { > > my mixin [append mixin_list " " [my info mixin]] > > } > > with names like mixinappend, mixinprepend for mixins, filters, > instmixins, instfilters we would introduce a large number of > methods, which do more or less the same. Yes. That is certainly a problem. > what do you people think about the following "interceptor" > method: it is more verbous, but much more powerful as well; it > allows appending/prepending/inserting at a certain position and > deletion of all kinds of interceptors: Hm... One minor niggle is the use of the term 'interceptor'. The term is quite overloaded. First, this instproc manages two kinds of 'interceptor' interfaces for an object: mixins and filters. Second, the proc itself is an interceptor -- it traps calls to manage the mixin and filter lists. Third, as you have written this proc, it manages both mixins and filters, which makes them appear more similar than they really are. That said, I do think you are on to something. The core problem is that both filters and mixins are a list of classes, and there are no good primitives to manage that list in a natural manner. It would be nice if [my info mixin] and [my info filter] were mutable with list commands, but... So, for the sake of argument, let us assume that there are two new instprocs - one to manage the list of filters, and one to manage the list of mixins (again, better naming ideas greatly appreciated): Object instproc mixin_list args { set op [lindex $args 0] set classes [lrange $args 1 [llength $args]] switch -exact $op { append { my mixin [concat [my info mixin] $classes] } prepend { my mixin [concat $classes [my info mixin]] } set { my mixin $classes } get { my info mixin } delete { ... } } } Class A Class B Class C A a a mixin_list append B a mixin_list prepend C a mixin_list get ================ ::C ::B Adding new primitive operations (like a mixin_list length; a mixin_list sort; a mixin_list contains classname; etc.) is simple and obvious. I haven't played with filters yet, but this idiom should work well there, too. I'll leave it to you to determine whether this method should work use instmixin for Classes, and mixin for Objects. -- Adam

6 11

Dynamic dispatch and subclasses
by Neil Madden 21 May '04

21 May '04

Hello all, Just noticed the following behaviour in XOTcl: Class Base Base instproc foo {} { puts "Foo in Base" } Base instproc bar {} { # Just call foo my foo } Class Sub -superclass Base Sub instproc foo {} { puts "Foo in Sub" } (Desktop) 56 % Sub a ::a (Desktop) 57 % a foo Foo in Sub (Desktop) 58 % a bar Foo in Sub I was kind of expecting the last to say "Foo in Base", as the method call of "foo" was dispatched from the Base class level. This is an interesting problem, as I can see reasons why you might want to do the current behaviour. However, I'm worried about some of the implications of implementation details and name clashes. Suppose I implement some class Base, which as part of it's implementation has a (private) method DoStuff. Now suppose someone else sub-classes my class, and in their implementation, they also happen to have a DoStuff method - this is going to break my implementation. It seems like this is breaking encapsulation somewhat. It seems like the cases where this dynamic dispatch could be useful could also be solved by passing in an explicit callback - that way you aren't relying on an implementation detail. Am I missing a good reason for this? My OO theory is perhaps lacking in this area. I can see that I can get around it easily by prefixing my private methods: Base instproc BaseDoStuff {...} { ... } but this seems a bit ugly (reminds me of pre-namespace Tcl). Does XOTcl have some other cool feature that I'm missing. Cheers, Neil.

2 1

Mixins in XOTcl
by Adam Turoff 18 May '04

18 May '04

Hi, I'm a long-time Perl programmer who recently started using XOTcl on a new project. Support for mixins has been a tremendous boon for productivity on this project. However, the standard idioms for managing mixins (mixin and mixinappend) both feel a little broken. For example, with "obj mixin list_of_classes", I need to know the full set of mixins for an object (or a class) each time I mutate it. Using mixinappend helps, but appending new classes to the end of the mixin list seems wrong, because the newly added classes will be found *last*. Here is why I think these idioms don't work well: in most other languages, an object is created through successive refinement. In C++/Java, we start with a base class and derive more and more specific variants on that definition through subclassing. I use XSLT a lot, and in XSLT, the most specific templates are found after templates of lesser specificity. Surely there are other examples; these are just the first two that come to my mind. The underlying idiom seems universal, at least to me. To remedy this, I've added this primitive into my system. Suggestions for better names greatfully appreciated: Object instproc insert_mixin {mixin_list} { my mixin [append mixin_list " " [my info mixin]] } With this new operation, I can now derive an object through mixins in a very natural manner: Car mycar mycar insert_mixin Volkswagen mycar insert_mixin NewBeetle mycar insert_mixin AutomaticTransmission mycar insert_mixin Turbo mycar insert_mixin WasabiGreen .... If I were to start calling methods like "max_rpm", "engine_size", "color", or "transmission", they can all get intercepted at the right point in the mixin chain, wrapping/superceding more generic methods. Instant separation of concerns. ;-) Additionally, I can dynamically refine my object: if {$add_roof_rack} { mycar insert_mixin RoofRack } if {$has_sunroof} { mycar insert_mixin SunRoof } Thanks for the excellent programming environment. Hope this helps, -- Adam

3 2

Re: Document
by h8853209＠wu-wien.ac.at 04 May '04

04 May '04

1 0

← Newer
1
...
39
40
41
42
43
44
45
...
66
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

Xotcl