Mark Coletti wrote:
> I do have design question. The sim.util.Properties and
> sim.util.Propertied may have the same functionality as the java beans
Java bean properties are merely a notion: if a function's name,
arguments, and return type match a certain pattern, that object is
considered to have a "read property" corresponding to that function.
Likewise for "write properties". That's literally all there is to that.
No code, no system, nothing. It's just a definition written down in a
If you want to actually *examine* or *manipulate* the properties of a
given class, you need to write a fair bit of code. There's various
chunks of code out there which do it: but everything I found was either
WAY overblown, poorly written, unextensible, and/or not under an
acceptable license. Usually all at one time. So I just wrote it. That
was several years back and I think it turned out to be a good decision.
MASON's property examination code is actually pretty simple. There's a
class for manipulating class java bean properties (SimpleProperties).
There's another class for manipulating arrays, Lists, Sets, and Maps as
if each of their slots was a property (CollectionProperties). And
there's an abstract superclass which has the factory functions. And...
The code also has some gizmos which are nice for us but no one else
(1) You can define domains for your properties ("this property isn't
just an integer: it's an integer from 4 to 15").
(2) Objects can tell the properties system "don't examine at me, use
*this* object for my properties instead" (sim.util.Proxiable).
(3) Objects can tell the properties system "don't use my java bean
properties, use *this* list of properties instead" (sim.util.Propertied).
(4) Objects can tell the properties system that the number and names of
the properties are volatile and must be looked up each time. Lists,
Sets, and Maps are volatile, as can be objects in #3 above if they so
None of these gizmos requires any code on your part, they're all optional.