Re: [Repast-developer] custom charts question + properties

[Laszlo G. <gu...@la...>]

Hi,

I'll comment on this in some more detail soon. Currently, I am
in somewhat of a hurry. Anyhow, I've also been thinking, or rather,
experimenting. I've started to put together a prototype version of
the builder (except for actually generating the dynamic chart) to
show you how I think it should work. I'm almost ready with it and
I'll mail it to you soon.

In short, I am not worried too much about private/protected methods.
If we can do something about them, fine, but otherwise, I would think
that can be required of the users. Even if this would lead to making
all of their fields public. (My students do it that way, anyway, as
they only had a crash-course on Java, so we didn't bother with
visibility...)

As for the non-model classes: you have a point there, but the
situation is better than you describe, I think. In my prototype,
you start out browsing (via a JTree) from the Model (or from any
class now). If you pick a field with double/float/.../etc., then
you're fine. So you are, if you pick a method that returns such
a value and takes no parameters. If you pick a field that has an
object for a value (of a method that returns such a thing) then
it 'opens up', showing the internals and you go on as above.

However, you can also pick an array or a collection object.
If it's an array, we are in pretty good shape: the type can
be determined. On the other hand, if it's a collection, you are
also required to pick another, the 'element' source. Here you
need to pick a class/interface first and then, everything goes
as in the browsing panel above, except that you cannot pick an
array/collection anymore.

Now, the tricky part is picking a class/interface. The simplest
solution is to require the user to type in the name, but I'm currently
working on to provide a browser for this, too. In principle, this should
be possible as JBuilder and all the IDE's have boxes like this. Well,
more on that later.

I know, this scheme is not perfect, but (at this point? :-)) I'd be
perfectly happy with it.

So, this mail got rather longer than I expected... I'll send the prototype
off soon. Keep your expectations low, however, as I am a rather poor
Swing programmer...

Cheers,

Gulya

At 11:34 AM 11/12/2002 -0500, Nick Collier wrote:
>Hi,
>
>I've given this a bit more thought, and I have some concerns.
>
>Public Methods in the model class:
>
>Introspect the model and get a list of all the methods that return
>either a primitive number or an instance of Number. These methods can be
>wrapped by dynamically compiled Sequences and thus displayed and updated
>appropriately in the graph. Assuming the methods are public, there is no
>reflection here other than when the list of appropriate methods is first
>created. So far, no problem.
>
>Private/Protected Fields and methods in the model class are more
>problematic:
>
>As above we use reflection to create a list of numeric fields / methods.
>However, the Sequences that provide the value of these fields / methods
>to the OpenSequenceGraph for display and recording will use reflection
>every time the graph is updated. This can be quite slow. The problem
>here is that there is no way for a dynamically compiled Sequence to have
>access to private / protected methods / fields unless that Sequence is
>either an inner class of the model class or uses reflection on the
>model. In this latter case, the Sequence would not need to be
>dynamically compiled anyway. Note that the point of the dynamic creation
>and compilation of a Sequence is intended to remove the necessity for
>reflection. It may be possible to make the Sequences inner classes of
>the model on the fly, but I'm not optimistic.
>
>Using Non-model classes:
>
>This is hard because repast doesn't know anything about these classes.
>All it knows about is the model. Furthermore, it doesn't look like its
>possible to retrieve all the Class objects in a particular package
>before those classes have been loaded. And even then I think a custom
>ClassLoader is necessary. So, that leaves it up to the user to input the
>name of the non-model class. For example, the user would choose the
>"agent list" from a list of fields in the model and provide the class
>name of the agents contained in the list. A list of methods in the agent
>class could then be produced. Alternatively, the user could just specify
>the method itself, but it would be hard to check if this method was
>valid without knowing the class it belongs to. Also working with agent
>list field requires using reflection as mentioned above. At some point,
>it seems as if might be simpler for the user to create the graph in code
>as is required now.
>
>If we add something like agentIterator() to SimModel, or some other
>interface that is required for this kind of graph building that would at
>least remove the agentList reflection problem. My other concerns could
>probably be eliminated as well through new Interfaces, superclasses etc.
>
>Comments?
>
>Nick
>
>On Thu, 2002-11-07 at 16:16, Laszlo Gulyas wrote:
> > Hi,
> >
> > Thanks Nick, this sounds awesome! Please find my comments below.
> >
> > Gulya
> >
> > At 09:11 AM 11/7/2002 -0500, Nick Collier wrote:
> > >Hi,
> > >
> > >I've added support of the dynamic compilation of sequences and histogram
> > >items for the various kinds of charts in repast. I've also fiddled with
> > >the internals a bit so they should be a bit faster and look a bit
> > >better.
> > >
> > >All this should make it fairly easy to create a chart building GUI so
> > >the user can add charts on the fly. Data is received by a chart via some
> > >class that implements Sequence. This is essentially a single method
> > >class whose method returns a double. Thus, for chart building I'm
> > >thinking of introspecting the model and returning all the methods that
> > >return a number. These can be wrapped in a dynamically compiled
> > >sequence. Something similar could be done for histograms.
> > >
> > >However, this approach sort of bothers me in that it assumes the methods
> > >of interest are already defined. Maybe we also need to iterate over all
> > >the agents calling some method on each one and then plot the average,
> > >for example. I don't want to do too much here as Tom and I are keen to
> > >get 2.0 out the door as its been a bit delayed as he and I have been
> > >writing models. So, any comments?
> >
> > Disclaimer: I have very limited experience with introspection, so I
> > apologize if what I say is nonsense. [Although, in the last 30 mins
> > I've made some experiments, so it seems this may be doable.]
> >
> > That said, what I originally had in mind was something like this:
> >
> > a)
> > A menu with all the classes in the model's (?) package, you
> > could pick a class from it. (By default, it would be the model.)
> > Then, a menu of all the methods returning a value, PLUS all
> > the data members having a double/float/int/long/etc. type
> > would show up. You'd pick the data source from it.
> >
> > b)
> > Alternatively, in the second step, the menu could show all
> > the collections (or perhaps, all arrays, too) available to
> > extract data from them [and calculate min/max/avg/sum].
> > It's much trickier, though, as with collections, you don't know
> > what kind of objects you are facing. So, perhaps, we should,
> > indeed, scale back to the agents... On the other hand,
> > we could force the user to pick a class/interface and throw
> > away all objects in the generated code that don't adhere...
> > (Although, I'm afraid this would get way too complicated for
> > the users...)
> >
> > >Also, Gulya had a good suggestion about remembering the position and
> > >sizes of windows and so forth. If this is to be done between runs, but
> > >not between application instances then no problem. If we want to do it
> > >between application instances, and I think we do, then we'll need to use
> > >a file format to store this info. Java 1.4's new property mechanism
> > >would be good for this, but 1.4 is not really available for the Mac yet.
> > >So, I'm thinking a simple XML format. I'd go with java's properties
> > >format, but I think we'd might grow out of that at some time. We could
> >
> > I haven't got much experience with java properties, so I don't know.
> > In principle, XML sounds good to me.
> >
> > Take care! Gulya
> >
>--
>Nick Collier
>Social Science Research Computing
>University of Chicago
>http://repast.sourceforge.net