Skip to main content

Collection Overloading: Collection access through [ i ] or [i, j]

13 replies [Last post]
laurapiersol
Offline
Joined: 2003-06-13
Points: 0

Collection Overloading: Just a little syntatic sugar that would REALLY solve many of the problems associated with using Java for Scientific Computing. No change to JVM just javac. Not new but needs mentioning.

Allow classes with methods:
get(int i);
set(int i, V value);
to be accesses through

notation. May need new Interface to help make clear.

Also allow access to multidimensional classes with methods:
get(int i, int j);
set(int i, int j, V value);

Matrix and List class usage would be GREATLY Simplified. If really daring could allow index to be of any type (String for example) like in Groovy.
a["One"] = 1

Again, don't see any changes to JVM or compatibility and shouldn't be too hard on parser. If parser has problem then change syntac to whatever works.

This isn't usuable for Scientific Community:
a.set(i, b.get(j));
a.set(i, j, b.get(k, l));

This is USABLE:
a[i] = b[j];
a[i, j] = b[k, l];

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
forax
Offline
Joined: 2004-10-07
Points: 0

I think that a modern language must have language access
to basic collections like List, Map.

I propose to introduce to the Java langage construts
that permit :
- initialise a Listlike an array :
List l={"toto","titi","tutu"};

- initialise a Map with a similar construction :
Map m={"toto"=3,"titi"=4};

- access using operator '[]' by mapping it
get/{set or put} method :
l[3] -> l.get(3) [List.get(int)]
l[3]="titi" -> l.set(3,"titi") [List.set(int,E)]
m["toto"] -> m.get("toto") [Map.get(Object)]
m["toto"]=3 -> m.put("toto",3) [Map.put(K,V)]

Perhaps, these construts could be extended
to object[a,b,c] -> object.get(a,b,c).

Rémi Forax

forax
Offline
Joined: 2004-10-07
Points: 0

i'm replying to myselft :)

i forget that a list have different implementation
so List l={"toto","titi","tutu"};
is not a good syntax.

A syntax like enum declaration seems better :
List l=new ArrayList() {
"toto","titi","tutu"
};

This syntax is close to anonymous classes but
the compiler can make the difference.
If you want to declare and initialise an anonymous
List. The syntax is :

List l=new ArrayList() {
"hello","my"; // <-- there is a ; here
public @Override void add(String s) {
super.add(s+"world");
}
};

the same syntax could be used for Map.

Rémi

gipak
Offline
Joined: 2004-10-11
Points: 0

I really can't agree with that, don't like the idea of having many ways to do exactly same thing. It would make programmers life easier but learners harder, it would be somewhat confusing and made code harder to read. Just being ...conservative. ;)

monika_krug
Offline
Joined: 2004-10-14
Points: 0

I agree that collections that support .get(index) and .set(index, value) should be accessible via [index] (so not all Collections, e.g. not Sets). I believe this would not be harder to implement than auto(un)boxing and would be a completely compile-time solution.

However, maybe there is a problem with the .set part. If javac compiles coll[index] to coll.get(index), then the set part would not work: coll[index] = something might be compiled to coll.get(index) = something instead of coll.set(index, value). So it might be hard to implement the .set part.

So, assuming the difficulty that I described really exists for the compiler programmers, I would maybe change the proposition to just support the .get part, i.e. var = coll[index] compiles to var = coll.get(index), but setting still has to be done via set(index, value).

This also removes the necessity of overloading the = operator for the .set part of your suggestion.

Most posters seem to be against your proposition. My opinion is:
- It's not only useful for scientific computing, but for general programming, too. I would love to be able to access ArrayLists more easily.
- I don't think there would be much confusion. If someone iterates over a LinkedList with list[index] - too bad for him. He would probably have iterated over the LinkedList with list.get(index), too.
- However, if .get can be done with [], but .set cannot, like I suggested, there might indeed be confusion, because list[index] = something would not work.

So, what do you all think? Is .set really a problem, i.e. the compiler could not compile list[index] = value to list.set(index, value), because it would compile this into list.get(index) = value?

Monika.

forax
Offline
Joined: 2004-10-07
Points: 0

> I agree that collections that support .get(index) and
> .set(index, value) should be accessible via [index]
> (so not all Collections, e.g. not Sets).

yes

> I believe
> this would not be harder to implement than
> auto(un)boxing and would be a completely compile-time
> solution.

i think too

>
> However, maybe there is a problem with the .set part.
> If javac compiles coll[index] to coll.get(index),
> then the set part would not work: coll[index] =
> something might be compiled to coll.get(index) =
> something instead of coll.set(index, value). So it
> might be hard to implement the .set part.

it can't be compiled to coll.get(index)= because
in Java there is no way to return a lvalue like
in C++. So coll[index]=3 must be compiled to
coll.set(index,3).

>
> So, assuming the difficulty that I described really
> exists for the compiler programmers, I would maybe
> change the proposition to just support the .get part,
> i.e. var = coll[index] compiles to var =
> coll.get(index), but setting still has to be done via
> set(index, value).
>
> This also removes the necessity of overloading the =
> operator for the .set part of your suggestion.

I don't think overloading = is a good thing.
There is a lot of bugs in C++ code due to such overloading.

>
> Most posters seem to be against your proposition. My
> opinion is:
> - It's not only useful for scientific computing, but
> for general programming, too. I would love to be able
> to access ArrayLists more easily.

i agree

> - I don't think there would be much confusion. If
> someone iterates over a LinkedList with list[index] -
> too bad for him. He would probably have iterated over
> the LinkedList with list.get(index), too.

i agree

> - However, if .get can be done with [], but .set
> cannot, like I suggested, there might indeed be
> confusion, because list[index] = something would not
> work.
>
> So, what do you all think? Is .set really a problem,
> i.e. the compiler could not compile list[index] =
> value to list.set(index, value), because it would
> compile this into list.get(index) = value?

i think the restriction about list[index]=value
is not necessary if its compile to list.set(index,value).

>
> Monika.

i think List is not the sole type that could need [],
Map or Matrix could benefit of such system

Here, you can find my proposal :
http://www-igm.univ-mlv.fr/~forax/works/indexer/proposal.pdf

Rémi

laurapiersol
Offline
Joined: 2003-06-13
Points: 0

Thanks for the responces. I appreciate them greatly. If I read this correctly there are three issues with Collection Access Overloading (CAO).

1.) Hides distinction between List (or Map) and array. Point well taken. This is true but why is this is such a bad thing? JVM and compiler wouldn't be confused. Don't we want to hide distinction between List and Array? Isn't this what the new "for loop" does? Everyone loves the new for loop (syntac aside). Auto conversion of int to Integer seems like a much, much worse thing and yet it was implemented (not sure I agreed with that decision). Could someone give a use case where this would cause a problem or confusion (like autoconversion of primitives does)? CAO would allow for a much richer use of arrays. Example: could now have a multidimensional array class just like C#, C/C++, and Fortran (not a ragged array implementation). a[row, col] could be mapped to backingArray[row * rowSize + col] like in other languages. Benifits seem to far outway some unknown hypothetical confusing use case. I count the hiding distinction between List and Array as a plus, not a negative. Java now becomes easier to learn, not harder.

2.) This is Operator Overloading (OO) of "=" and OO is bad. This isn't numeric OO (+, -, ...) which has problems. This is more like the OO of "goto" statement with "for" or "while" loops. Get and set ruin readability of Lists much like "goto" ruins readability of loop structures. This is not a general OO contract for abuse but a very targeted attack on using Lists and Arrays uniformly. Enhances readability, consistency, and ease of use.

3.) Scientific Community wouldn't use Java anyway so shouldn't try and make language fit their needs. I agree we shouldn't try and make Java all things to all people but are we saying Java isn't fit for doing math? Does that mean people shouldn't write accounting programs or games with Java? Why? Speed is not the issue anymore, syntac is. The ONLY two things stopping Java being embraced by the Scientific Community is List structure syntac and a Complex Number primitive. 95% can life without the complex primitive but very few can live without the cleaner syntac for List structures. Has anyone used FORTRAN? It's not that great. If Java gained the support of the Scientific Community I assert there would be ALOT MORE MONEY and support thrown at the language since the government loves to throw money at science. This seems to be a very important community to court.

gipak
Offline
Joined: 2004-10-11
Points: 0

Unless there is something i don't get right... this is a bad idea. That would be usefull (kinda) to make [b]ArrayList[/b] access with [], but not [b]List[/b], think about [b]LinkedList[/b], it is a usefull thing but accesing large LinkedList with a [i]get(i)[/i] is a horrible waste of CPU time, when using the "for:" loop you access it with an underlying iterator and everything works fast.If you don't need iteration you usually deal with a List with fixed number of elements, so it's a good idea to use a standard array. If it isn't a fixed size List and you need to access it throug an index number it is/(should be) an ArrayList. This realy limits any usability of [] to ArrayList (at Least in 99% cases). Adding a special interface that allows an overloading of "[]" operator (and =)? I don't think it's a good idea, although it's as good as say.. static imports - saves you keystrokes :). But makes a code harder to understand ("So is it an array or a List?").

forax
Offline
Joined: 2004-10-07
Points: 0

I not agree with you, you can have
a List with a direct access that is not an ArrayList.
See java.util.Arrays.asList() by example.

get(index) exists on LinkedList, so [] could
exist on it.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

Scientific community will find much more deficits in Java, so we should not try to satisfy them.

Unless - provide special explicit operator overloading for explicitly mentioned classes in java.lang and java.math packages (class Number, future java.math.Matrix / whatever)

But this should be explicit, part of JLS, and not a generic [] and = overloading for collections.

patrikbeno
Offline
Joined: 2004-10-11
Points: 0

-1
I don't like it

1) Confusion with arrays
2) Need for = operator overloading
3) Very little added value - with generics, typesafe get(0 and set() are just enough, don't you think?

scolebourne
Offline
Joined: 2003-06-20
Points: 0

Although I like it in theory, I fear that it confuses the distinction between arrays and lists. The two do have different strengths and uses, so confusing them doesn't actually help (if java was a fresh new language, I might go with the syntax)

I also strongly oppose the multidimensional array part as it implies something beyond that normally implied by lists.

A better RFE is to add List-like methods to arrays.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

This is related/covered by a RFE I have filed recently:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5099780

A lot of this sort of stuff is common-sense operator-overloading issues. The key is to push Sun for safe/approached operator usage instead of asking for catch-all operator overloading. Please vote for this issue if it interests you.

laurapiersol
Offline
Joined: 2003-06-13
Points: 0

I'm not shooting for a flame fest here but the bug report you filed is not quite the same. You seem to be looking for Operator Overloading (OO) (+, -, /, *, ect) and I'm looking for Collection Access Overloading (CAO) ([]). Semantics are extremely important here. Think of CAO as a tiny, small subset of OO if you want but lets refer to it as CAO so the discussion/enhancement is focused.

The last 100 or so responses I've received over the last few years all deal with OO and the problems and issues introduced by that enhancement (there are many). Not one response, as far as I can see, deals with the much much simpler issues associated with CAO. I've never been able to elicit any real discussion on the merits of this proposal. I personally feel CAO would be EXTREMLY useful for anyone doing Scientific Computing.

The question I really care about is would introducing CAO into java cause any problems? Would it be hard to implement (I don't see why)? Would it cause any changes to the JVM (can't think of any)? Any issues with version compatibility (no)?

An enhancement request seems a little premature since I'm the ONLY one who sees any benefit in CAO. Maybe I'm the only one using JAVA for Scientific Computing. I was hoping to develop some steam behind this proposal by first developing a community of like minded individuals. That's why I brought it up in this forum.