Entries should provide Map interface about gradle-build-properties-plugin HOT 5 CLOSED

asMap sounds good. 👍

The backstory is: I needed to simply access values. Instead I had to iterate over keys and collect values. Although not too hard, it would be much simpler to use already available Map methods. I could just add values() method but I feel like this is just an example. I believe it would be handy to have full Map interface.

I think asMap is a good compromise to have both. I like the idea.

from gradle-build-properties-plugin.

I was gonna do this simply by using @Delegate annotation from groovy. With this, it is actually pretty simple change. Except for the defaults. This forced me to have a wrapper implementation of a simple map.

But at the same time I realized that there is an ongoing work on #35. That's why I decided to wait for that to finish.

Also opened this issue for discussion.

from gradle-build-properties-plugin.

As discussed IRL the reason why the plugin defines Entries as interface is to stay away from the mutability of the Map contract. To ensure immutability then we expose just 3 methods:

• boolean contains(String key)
• Entry getAt(String key)
• Enumeration<String> getKeys()

I've been thinking about this and I still don't like the idea of using map there just to use some extension on Entries (I'm not worried about how hard or simple is to make Entries implement Map, but rather how this breaks the original idea of immutable set of lazy-evaluated entries).

We have 2 alternatives:

• manually add the missing extensions to Entries to provide all the convenience methods missing
• expose a Map<String, Entry> asMap() method that can be used to tap into the collection extensions from groovy without breaking the original idea.

@devisnik thoughts on this?

from gradle-build-properties-plugin.

Looking forward to the PR 😛

from gradle-build-properties-plugin.

Addressed by #43

from gradle-build-properties-plugin.