Generic tree interface for *SLF/EMF/WMF

[Andreas Beeker <ki...@apache.org>]

Hi,

I'd like to introduce a generic interface [1] for *SLF/EMF/WMF, which can be used to navigate through the records more easily - i.e. for debugging and extraction purposes. So each record needs to implement/inherit this interface.

* I'd put it into the org.apache.poi.sl.extractor package - would it make sense to move it up in org.apache.poi.common.usermodel and eventually implement it in other modules too?

* What do you think about using Optional constructs?
  i.e. do we stick with return NULL as "doesn't exists", and an empty list if there are no children
  My gut feeling is, this might be over-engineering and doesn't match the rest of our API, but I'm open to changes now that we are using Java 8+.

* I thought about providing a java.util.NavigableMap-like interface (or something from commons collection), but I think a simple interface is more pragmatic.

* Having the ...Generic... in its method names should be enough to prevent signature clashes.

* One could use a delegate method to provide the interface, but this seems to be too much hassle.

Andi

[1]

public interface GenericRecord {
    Enum getGenericRecordType();

    Map<String,Object> getGenericProperties();

    List<? extends GenericRecord> getGenericChildren();
}

Re: Generic tree interface for *SLF/EMF/WMF

[Dominik Stadler <do...@gmx.at>]

Quick opinion from my side:

I would put it into common.usermodel to be able to introduce it for other
parts later on.

I personally would not use Optional, I tried it at some point and did not
get much value out of it. IntelliJ IDEA is much better at showing problems
with null-values...

Dominik.

On Sun, Aug 4, 2019 at 1:49 AM Andreas Beeker <ki...@apache.org> wrote:

> Hi,
>
> I'd like to introduce a generic interface [1] for *SLF/EMF/WMF, which can
> be used to navigate through the records more easily - i.e. for debugging
> and extraction purposes. So each record needs to implement/inherit this
> interface.
>
> * I'd put it into the org.apache.poi.sl.extractor package - would it make
> sense to move it up in org.apache.poi.common.usermodel and eventually
> implement it in other modules too?
>
> * What do you think about using Optional constructs?
>   i.e. do we stick with return NULL as "doesn't exists", and an empty list
> if there are no children
>   My gut feeling is, this might be over-engineering and doesn't match the
> rest of our API, but I'm open to changes now that we are using Java 8+.
>
> * I thought about providing a java.util.NavigableMap-like interface (or
> something from commons collection), but I think a simple interface is more
> pragmatic.
>
> * Having the ...Generic... in its method names should be enough to prevent
> signature clashes.
>
> * One could use a delegate method to provide the interface, but this seems
> to be too much hassle.
>
> Andi
>
> [1]
>
> public interface GenericRecord {
>     Enum getGenericRecordType();
>
>     Map<String,Object> getGenericProperties();
>
>     List<? extends GenericRecord> getGenericChildren();
> }
>
>