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

less conversions

- 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

method.



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:

-> in

<- out

<> linking 



-> in:

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

(s.http://getclass.blogspot.co.at/2008/03/inter-type-declarations-with-implicit.html).



<- out:

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.

http://acs.lbl.gov/software/colt/api/cern/colt/list/ObjectArrayList.html).



<> linking:

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

access. 



This kind of a thinking loud exercise so I might be wrong in some aspects

and I hope nobody gets bored. 



regards

roman













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

going

> to happen for a while.

> 

> If you’re specifically thinking about Bags, here’s what would need to be

> done:

> 

> 	1. All internal references to scanning over bags using the numObjs

> 	variable would have to move to using get() and set().  This would

include

> 	all applications.

> 

> 	2. Any calls to Bag.remove() would have to instead go to a utility

method

> 	we’d make up which would do the same but be outside the class.  Also,

all

> 	applications.

> 

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

> 

> Sean

>> roman