MASON-INTEREST-L Archives

January 2012

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:
MASON Multiagent Simulation Toolkit <[log in to unmask]>
Date:
Sun, 8 Jan 2012 13:41:27 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (15 lines)
On Jan 7, 2012, at 5:29 PM, Mark Coletti wrote:

> So, these are the changes I plan to make:
> 
> 	 Eliminate the MasonGeometry user data field redundancy; prefer to use the underlying JTS Geometry user data field.
> 	 The user data field should be just that: for the users.  Move the attribute information to a separate field that does not rely on the optional user data field.  As a pleasant by-product this also eliminates the originally mentioned exception problem.  (It's always a Bad Sign when one must suppress compiler warnings regarding unhandled exceptions, which is what we have now.)

I'm wondering about this though.  The attributes, commonly stored in geometry files, are automatically loaded by JTS into the JTS geometry user data, aren't they?  Wouldn't moving them elsewhere be going against JTS convention, and if this is the case, would it eventually bite us down the road?

> 	 Use a hash map instead of a manually sorted list for attributes thus eliminating the aforementioned brittleness.

Hashmaps will be a problem because they're not in a predictable sort order.  Maybe a ThreadedHashMap?

Sean

ATOM RSS1 RSS2