Hi,
> - Why "flat" in the name? It sounds a little misleading to me. With
> Stream is quite clear what flatMap does: it gets new streams out of each
> element end merge them into an unique stream. But in this case I don't
> understand what "flat" means.
generally I tend to agree with your argument, but I believe you could make this
case for Optional<T> equally well. To my knowledge in Java and Scala (not using
Scala, so please correct me if I am wrong) 'flatMap' refers to the general idea
of a function, which takes some value inside a 'container' (the T in
Optional<T>, Stream<T> or IModel<T>) and returns a new container with a new
value inside it. But we actually don't care, whether it is a Stream, an
Optional or an IModel. To make this more tangible take a look at the following
method signatures:
public <R> Optional<R> flatMap(Function<T, Optional<R>> mapper) {...}public <R>
Stream<R> flatMap(Function<T, Stream<R>> mapper) {...}
public <R> IModel<R> flatMap(Function<T, IModel<R>> mapper) {...}
Except for the 'container' type (Optional, Stream or IModel) they have exactly
the same signature.¹ In Haskell this function is called 'bind'. Just an equally
opaque name (in my personal opinion). So, the reason I chose this name when
proposing the ideas, was to align it with other classes in the ecosystem
already using this name for a method with this sort of signature and behaviour.
As for the origin of the name 'flatMap', I have no idea. :)
> - Looking at the test code I see that the main difference between map
> and flatMap is that the first creates a read-only model, while the
> second uses a wrapping model that might be a read/write one. If so
> wouldn't be better to provide a second map method with a WicketConsumer
> as additional parameter? Example: Model.of(person).map(Person::getName,
> Person::setName);
That is certainly possible, but we would lose the ability to return whatever
IModel implementation we want. As it stands now, we are able to return a
MapModel, a ListModel, a LoadableDetachableModel and whatever IModel we can
think of. In the test case it just happens to be a Model, where the setObject
method has been implemented.
Regards,Matthias
¹ We might derive the following general signature for 'flatMap', (ignore this,
if it doesn't make sense, since we cannot actually express this in Java):public
<R, M<R>> M<R> flatMap(Function<T, M<R>> mapper) { ... }
Von: Andrea Del Bene <[email protected]>
An: [email protected]
Gesendet: 13:22 Freitag, 15.Juli 2016
Betreff: Question about IModel#flatMap
Hi guys,
I need some help with the new method IModel#flatMap as I don't
completely get the idea behind it. I've got two main questions:
- Why "flat" in the name? It sounds a little misleading to me. With
Stream is quite clear what flatMap does: it gets new streams out of each
element end merge them into an unique stream. But in this case I don't
understand what "flat" means.
- Looking at the test code I see that the main difference between map
and flatMap is that the first creates a read-only model, while the
second uses a wrapping model that might be a read/write one. If so
wouldn't be better to provide a second map method with a WicketConsumer
as additional parameter? Example: Model.of(person).map(Person::getName,
Person::setName);
Cheers.
Andrea.
