Reworked a bit the Extension interface

[slinkydeveloper]

Look at #122

This change:

• Change the signature of readFromEvent to accept CloudEventExtensions
• Remove asMap() and let Extension extend CloudEventExtensions. Because the number of attributes for a materialized extension is always the same, allocating a map to provide an unstructrured view (needed to write the materialized extension to the cloud event builder) is useless. This solution makes more efficient the implementation of such materialized extensions

Signed-off-by: Francesco Guardiani [email protected]

[slinkydeveloper]

@bsideup mind giving a look?

[bsideup]

This sounds wrong. Extension extends CloudEventExtensions smells.

Especially given that it will look like:

Extension ext = ...;

ext.getExtension("OMG WTF!");
ext.getExtensionNames(); // whaaaat?

[slinkydeveloper]

how about:

public interface Extension {

    void readFrom(CloudEventExtensions extensions);

   Object getValue(String key);

   Set<String> getKeys();

}

[bsideup]

Much better :)

WDYT about Iterable<String> getKeys();? Since extension may define a dynamic set of keys, Set here can be a bit restrictive, and it does not look like we need to have Set's characteristics in this case

[slinkydeveloper]

To me it doesn't sound explicative Iterable<String>, because Iterable can contain duplicates. Because we're returning a key set, to me it makes sense using the Set<String> type, exactly like i expect a Map to return the keys as a set

[slinkydeveloper]

On the other hand, I don't think it would be a bad idea to let this interface extend Iterable<Map.Entry<String, Object>> or have a method like iter() that returns such Iterable

[slinkydeveloper]

And btw such Iterable can be default implemented

[bsideup]

Iterable<Map.Entry<String, Object>> would require allocations.

Okay, let's keep Set then.

[slinkydeveloper]

Iterable<Map.Entry<String, Object>> would require allocations.

Sure, it's like "use it at your own risk" 😄