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

[Nick C. <nic...@ve...>]

Hi,

On public data fields: Certainly public fields will work fine w/r to
dynamically compiled classes. I'm just don't see them very often :).

non-model classes: good solution. As you say its certainly possible to
get the fully qualified names of all available classes. I was too
fixated on getting those _only_ in the user's package and missed this.

Anyway, thanks for the prototype. I'll take a look at it this morning.
By the way, this should be the last addition for repast 2.0 on my side.
We really need to get it out the door. Especially before we get swamped
by model development again.

Nick


On Tue, 2002-11-12 at 23:05, Laszlo Gulyas wrote:
> 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
> 
-- 
Nick Collier 
Social Science Research Computing 
University of Chicago 
http://repast.sourceforge.net