[Xotcl] XOTcl: Introspection bug (?) and Dynamic Object Aggregation consideration

[Gustaf Neumann]

Dear Attilo,
thanks for your suggestions and report

On Friday 30 April 2004 15:05, Attilio Dona` wrote:
> 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
> ...
> lsort [Class2 info methods]
> result: __next a a abstract ....
> expected: __next a abstract ....

 well, there is a simple fix :), use
 lsort -unique [Class2 info methods]

 i have fixed the xotcl code such it does not return duplicates.
 the fix slows down "info methods", since it performs 
 a linear search for each method (quadratic behavior),
 but in most apps, it is not called too often, so it might be ok.

> 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?

 correct. it was a documentation bug, the pattern was not described. 
 you can specify a pattern for matching the name for "info children"
 and "info classchildren"

> 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)

 This is a more complex issue, i have thought about a couple of times.
 In general it would be quite nice to have a object query interface
 that allows you to say "find me the objects having these and that
 instance variables set, that are children of some other object,
 have these or that classes, mixins, or whatever". It would be
 certainly quite nice to use e.g. XPath as a query language for this
 purpose. An easy approach would be to produce an xml tree
 using tdom from the interesting objects and use tdoms xpath
 implementation. tdom is very nice and fast, and i would not
 be suprised if that would be sufficiently efficient for many apps.

 most proably this would not sufficient for your app, since you
 are already concerned about looping over the info children 
 list. maybe you can use the following to approaches:

   - if you have less class instances than aggregations,
     use info instances with a match pattern instead. e.g.:

       Dog info instances ::stable::* 
       Cow info instances ::stable::* 
  
     these command will return you the Dogs or Cows wich are
     in the container stable.

   - If you have a huge number of container and a huge number of 
     instances, use an index in form of an associate array. you can
     maintain it whenever you create/destroy/reclass an object (e.g.
     through constructor/destructor)
           
 i'll send you a fixed version with a separate file.

 all the best
-gustaf

-- 
Univ.Prof. Dr.Gustaf Neumann
Abteilung für Wirtschaftsinformatik
WU-Wien, Augasse 2-6, 1090 Wien