From discussions with Karin :-) concerning IO:
- It is probably worthwhile to have a name for each particle which uniquely identifies the particle. The ID doesn't really serve this purpose as adding a particle changes the ids of particles which are added later. My proposed mechanism would look something like like adding get and set name methods to particles (and perhaps an argument to the constructor). When a particle is added to a model, if there is a name conflict then an exception would be thrown (or we could append something to the name to make it unique). If no name was specified before the particle is added to the Model, a unique name would be generated ("particle 3").
These names mean that logging and XML-based IO could use something nicer and more stable to identify particles. And logging could print names instead of particle ids since the names are always non-empty and meaningful.
Daniel Russel wrote: > - It is probably worthwhile to have a name for each particle which > uniquely identifies the particle.
Can't we just use a regular string attribute for this? I don't much like the idea of adding another set of get/set methods purely for this purpose. And in many cases, we don't really care what the particles are called. Thus, I don't like the idea of wasting the memory needed to store all those strings, and having to make sure all the particles have unique dummy names (and presumably having to do a hash lookup for every new particle). Output methods can use the 'name' string attribute if there is one in any case. For reading in particles where you do care about not duplicating names, surely it's straightforward to provide a method to look up a particle by a given string attribute, so that you can decide on a case by case basis what to do about duplicated names (e.g. rename, combine the two particles in some way, throw an exception, or use only the new or existing particle). Why not just have a Model method to add an index for a given StringKey? This would create and then maintain a hash to allow rapid lookup of particles by values of that StringKey. I imagine this would be useful for things other than a simple 'name'.
Ben
BTW, can we have the list set the default response address to be the list rather than the sender?
> Can't we just use a regular string attribute for this? The main utility would be from ensuring that the names are unique identifiers (at least within the concept of a model) so we could use them for a human-editable file format if we ever come up with one. I don't like having a particular string attribute be handled differently than the others.
This is not something to act on now, more something to keep in mind as we think about IO formats. For reference, my current favorite choice for a user-editable file format is python, where this is all sort of moot. We could relatively easily write code to dump everything to a .py file (and for doing that ensure that each particle has a unique name attribute).
Daniel Russel wrote: > BTW, can we have the list set the default response address to be the > list rather than the sender?
Ah, so it's not just me! The default behavior is sender, and mailman gave dire warnings about changing it to list, so I left it alone. But it annoys me too, so I just changed it.
Ben
participants (3)
-
Ben Webb -
Daniel Russel -
Daniel Russel