MASON-INTEREST-L Archives

October 2004

MASON-INTEREST-L@LISTSERV.GMU.EDU

Options: Use Proportional Font
Show HTML Part by Default
Condense Mail Headers

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

Print Reply
Sender:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Tue, 19 Oct 2004 11:47:19 -0400
MIME-version:
1.0 (Apple Message framework v619)
Reply-To:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Content-type:
text/plain; format=flowed; charset=US-ASCII
Subject:
From:
Sean Luke <[log in to unmask]>
Content-transfer-encoding:
7bit
Comments:
To: MASON Multiagent Simulation Toolkit <[log in to unmask]>
Parts/Attachments:
text/plain (35 lines)
I am considering making a change which cannot be handled just with
deprecation.  It's a minor thing but I figured I'd ask the group for
comments about whether or not to make the change.

At present GUIState has a method called isInspectorVolatile(), which
you override if you want your model inspector to be volatile.
Presently all per-object inspectors are volatile.

In preparation for a new per-field inspector, I am considering
modifying this, by moving the volatility-check functionality into the
Inspector itself (adding two non-abstract methods,
Inspector.setVolatile and inspector.isVolatile).  GUIState's
getInspector method will still by default return non-volatile
inspectors.  However if you have overridden this method, your inspector
will of course start out VOLATILE unless you explicitly set it to
non-volatile with an Inspector.setVolatile(false).
isInspectorVolatile() will never be checked.

I will update Tutorial 4 appropriately.

I have two levels of possibility here:

- deprecate isInspectorVolatile and indicate that it is never used.
This will cause some people's model inspectors to start running in
volatile mode (slower) until they change their code to set volatile to
false.

- completely remove isInspectorVolatile to force the issue.  This will
break people's code until they fix it, but the upside is that we won't
have any phantom bugs due to people not reading the new documentation.

I have half a mind to do the second one.  Comments?  Recommendations?

Sean

ATOM RSS1 RSS2