Xotcl May 2004

xotcl@alice.wu.ac.at

8 participants
9 discussions

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

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

04 May '04

1 0

Re: Incoming Message
by h8853209＠wu-wien.ac.at 03 May '04

03 May '04

1 0

XOTcl: Introspection bug (?) and Dynamic Object Aggregation consideration
by Attilio Dona` 01 May '04

01 May '04

Hy, In 1 I report an introspection bug, in 2 an ahestetic bug and in 3 a personal consideration about a possible XOTcl improvement. 1. Introspection: "info methods" duplicated entry In the following I report e test case that shows the problem: Class MetaClass1 -superclass Class -parameter {{a "v1"} {b ""}} Class MetaClass2 -superclass MetaClass1 -parameter {{a "v2"} {c ""}} MetaClass1 Class1 MetaClass2 Class2 lsort [Class2 info methods] result: __next a a abstract .... expected: __next a abstract .... Class2 info methods a result:a a expected: a 2. Usage string Object n n info children -class Interface wrong # args: should be {::n info children ?pat?} I expect: wrong # args: should be {::n info children} or there is somethig missing in the language reference documentation? 3. Dynamic Object aggregation improvement issues I think would be useful, especially for performance reasons, that dynamic object aggregation have more introspection functionalities at core language level: for example at the info children command could be added options that returns children filtered by children class (and object names and ... ?) More in general,an useful feature could be returning all children that match some assertions (something like an invariant list) Attilio -------------------------------------------------------------------- CONFIDENTIALITY NOTICE This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to webmaster(a)telecomitalia.it. Thank you www.telecomitalia.it --------------------------------------------------------------------

2 1

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 May 2004