Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Have arrays and maps implement Collection and Map interfaces #2359

Closed
guillaume-alvarez opened this issue Sep 21, 2014 · 8 comments

Comments

Projects
None yet
3 participants
@guillaume-alvarez
Copy link
Contributor

commented Sep 21, 2014

I noticed Array, ArrayMap, ObjectMap, and other data sets utilities only implement the Iterable interface.

Is there a specific reason not to implement Collection and Map interfaces from standard Java API?

It would ease interfacing with other libs for desktop and Android backends.

@NathanSweet

This comment has been minimized.

Copy link
Member

commented Sep 21, 2014

The Java APIs have a number of things that would make libgdx's collections not so nice. Eg, Map#entrySet() requires Set<Map.Entry> which we don't have at all, similar issues with values, keySet. Adding some of these things probably would allocate, which is what we are trying to avoid. Throwing UnsupportedOperationException defeats the purpose of implementing the interface. In other places the API is simply worse, eg List#remove(Object) is easily confused with remove(int) for List<Integer>. Also, iterator() works differently which makes it a risk to use a libgdx collection in place of a Java collection.

Maybe it would be best to use delegate classes to provide a Java API to the libgdx collections.

@guillaume-alvarez

This comment has been minimized.

Copy link
Contributor Author

commented Sep 21, 2014

I understand your point.

Maybe a first step could be to ease the conversion between libgdx and Java collections? For instance a simple method to create an Array from a Collection or an Iterable, and a way to get a List from the Array?

@NathanSweet

This comment has been minimized.

Copy link
Member

commented Sep 21, 2014

If you want to copy the data from a libgdx collection to a Java collection, this is easily done in a line of code or 2. I wouldn't want this cluttering the API, I suppose it could get stuffed in some utility class. I'm not sure it's worth it, since copying the data isn't great.

@guillaume-alvarez

This comment has been minimized.

Copy link
Contributor Author

commented Sep 21, 2014

That's boilerplate for sure, but it would only require one constructor (Java -> libgdx) and one method (libdgx -> Java) per class, so not that much clutter. I think it would have a smaller footprint on the API than a delegate class, and if you agree on this design I'm willing to provide the patch.

As for the performances, copying data is not great for sure but it is not critical when not done at every frame, or from small data sets. In critical sections you would prefer Array (or even primitive arrays) over List anyway.

@badlogic

This comment has been minimized.

Copy link
Member

commented Sep 21, 2014

I'm in favor of not adding any references yo Java collection APIs as it
might make porting easier (there are restricted JVM environments without
the full Java runtimr we may want to look into eventually).
On Sep 21, 2014 9:31 PM, "Guillaume Alvarez" notifications@github.com
wrote:

That's boilerplate for sure, but it would only require one constructor
(Java -> libgdx) and one method (libdgx -> Java) per class, so not that
much clutter. I think it would have a smaller footprint on the API than a
delegate class, and if you agree on this design I'm willing to provide the
patch.

As for the performances, copying data is not great for sure but it is not
critical when not done at every frame, or from small data sets. In critical
sections you would prefer Array (or even primitive arrays) over List anyway.


Reply to this email directly or view it on GitHub
#2359 (comment).

@NathanSweet

This comment has been minimized.

Copy link
Member

commented Sep 21, 2014

I'd say it's probably uncommon to need to mix Java and libgdx collections (no one has ever brought it up until now) and if you are indeed doing that, a delegate class is the way to go, not copying the data. Given this and that the code needed is already just 1-2 lines of code, I don't think we really need libgdx <-> Java utility methods, whether in each collection class or in a utility class. If we were to have it, I'd prefer it quarantined to a utility class, something like JavaCollections.copy(Array, List), JavaCollections.copy(ObjectMap, Map). More useful would be JavaCollections.asList(Array) which returns a List backed by the Array.

@badlogic

This comment has been minimized.

Copy link
Member

commented Sep 27, 2014

Quarantined utility is fine with me, but i don't think anyone on the team will invest time on that. OP, we'd appreciate a PR!

@badlogic badlogic closed this Sep 27, 2014

@ghost

This comment has been minimized.

Copy link

commented Nov 1, 2014

I can only say I support guillaume-alvarez 100% on this... I decided on using Java Collections instead of libGDX collections mostly because no available superinterface for them makes switching between implementations very hard. Still, while I understand the notion of separating core GDX utils from core Java utils, a couple of glue classes (either adapters, views or delegates) would be very useful for anybody porting an existing Java logic to libGDX.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.