No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] XOTcl: Introspection bug (?) and Dynamic Object Aggregation consideration
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Sat, 1 May 2004 02:57:10 +0200
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
Date: Sat, 1 May 2004 02:57:10 +0200
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