MASON-INTEREST-L Archives

February 2009

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Sean Luke <[log in to unmask]>
Reply To:
Date:
Wed, 4 Feb 2009 16:35:25 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
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
> properties.

Nope.

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

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... 
that's it.

The code also has some gizmos which are nice for us but no one else 
provided:

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

None of these gizmos requires any code on your part, they're all optional.

Sean

ATOM RSS1 RSS2