Thanks for the reply! I have now digged a little bit into the code and I
now get what you mean by a "really big job".
The question is if it would really pay at all. I didn't even think about
all those Bags for primitives also affected.
As I can think of there would be three advantages:
- less code (which is aways good)
- less framework-specific binding in the simulation code and thus possibly
- more control over referencing or copying data
Whereas there are some disadvantages:
- possbily less performance
- primtive Bags might still be necessary
- no access on the array
Somehow I now get the overall complexity of the problem.
Others have done similar things as e.g. the Colt project
(s.http://acs.lbl.gov/software/colt/) who seem to have implemented one of
the fastest alternative Java collections frameworks.
One could consider using such a framework as the background of the Bag
infrastructure as one would like to get rid of some code. As less code is
always bettter. But one would bind to a framework - which is bad as it
might mess with peoples library dependencies if they need for a specific
colt version by themselves.
Colt e.g. does not implement a bag in the sense of a Set - they have an
ArrayList that does not allow for the specifity of the ArraySet/Bag remove
To me the main aspect of this whole question is more on how people bind to
the framework more than on the internals.
There are three cases of binding:
The Framework calls for a Bag or an Array on its methods such as a fields
add method. You can explicitly contruct a Bag from any collection or Array
(Colt could do this only from an Array). As I can see most of the cases the
content gets copied. This is the point where implicit conversions like in
scala might be wonderful to have. Else one could only use an AOP like
AspectJ to achieve that without producing boilerplate code
As for outgoing Bas one could maybe easily implement the Java List
interface. Bag allready implements Collection, which is probably fine for
many cases. In comparison Colt provides wrapper classes to convert to List
but doesn't even implement Java Collection with their ObjectList (s.
This is the most wicked problem. When changing a collection either on the
mason side of the framwork or on the progam side and have this change
linked one must not copy but wrap the collections. Implementing ArrayList
on the Bag or wrapping it would allow for lining from Mason to the outside
but there could as far as I see be no link from a java collection to the
mason collections still retaining the Bag possibilites of e.g. direct array
This kind of a thinking loud exercise so I might be wrong in some aspects
and I hope nobody gets bored.
On Tue, 21 Jan 2014 18:25:49 -0500, Sean Luke <[log in to unmask]> wrote:
> Roman, I’ve been mentioning two possibilities:
> - Moving from Bags to ArrayLists now that (it appears) HotSpot has
> special-cased the errors in ArrayList.
> - Adding some limited support for generics where appropriate in MASON.
> These are both really big jobs. We were hoping to move MASON in that
> direction with the support of an NSF grant, but applying for that grant
> will have to wait for a year. :-( So I think these two moves aren’t
> to happen for a while.
> If you’re specifically thinking about Bags, here’s what would need to be
> 1. All internal references to scanning over bags using the numObjs
> variable would have to move to using get() and set(). This would
> all applications.
> 2. Any calls to Bag.remove() would have to instead go to a utility
> we’d make up which would do the same but be outside the class. Also,
> 3. We might need to deal with a few special constructors, though it
> wouldn’t be often.
> 4. Then we’d just need to refactor Bag to ArrayList namewise.
> 5. And finish up with changes to the documentation (manual, tutorials).
> Not a small task.