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

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

Hi,

And now, after all that coding, let me get back to these.
Probably, I should have done this first... ;-)

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

Maybe I am completely out of scope here, but why should we always have
a _method_ returning the value? I mean, public data fields should also be
accessible... (I don't know about the byte code-generator, but values can
be lured out of them via introspection for sure.) In fact, I wonder if the
methods are really necessary in probing, too?

On the other hand, recognizing subclasses of Number is a good point.
This is missing from my UI-prototype.

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

OK. I believe this to be true for the data fields, too. But again, my knowledge
is limited.

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

OK, it may be hard to generate inner classes on the fly... Therefore,
considering the rush for 2.0, I think, we shouldn't count on that.

I think, we either have to leave the private/protected fields out of the 
game for
now, or provide them using reflection, with the warning that it could be a big
performance hit.

On one hand, this would be a powerful option, but on the other, I can foresee
it popping up continuously on the mailing list. Therefore, if the option 
will be
included, the warning should be really explicit and 'visible'. I could even 
imagine
this as an advanced option ('behind' a UI switch).  Or, perhaps, it should 
always
be there, but a warning window should come up each time when used? :-)

In the long run [in some later versions] we might get back to the inner class
option, though.


>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

Well, if I understand what you mean, my prototype should be a good
argument that it is possible. There, I am iterating through the files that
are accessible via the value of the "java.class.path" system property.
True, the selected classes should be loaded, but that's not that big a
deal, I think. Once the appropriate class is selected, it shouldn't be
hard to generate code that attempts to cast the objects in the collection
to the selected type. (Again, if I am not much mistaken...)

Note, that according to what I have in mind, these 'outside' classes are
only needed if the user picked a collection. Then, it is used to cast the
members of the collection. Otherwise, the user can only select variables
that are 'accessible' (could be referenced) from the Model object.

I am not sure how much sense I am making. I hope the prototype helps
me explaining it... ;-)

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

I think we don't really need an agentIterator() for this, but this all seem
to be tied to the fact that I assume that public variables can be accessed
from the generated code. (SimpleModel's agentList is protected at this
point, which, of course, makes things harder...)

Cheers,

Gulya