Continue filtering in ListedImages

[amihaiemil]

See puzzle.

[0crat]

Job #154 is now in scope, role is DEV

[0crat]

Bug was reported, see §29: +15 point(s) just awarded to @amihaiemil/z

[0crat]

The job #154 assigned to @llorllale/z, here is why; the budget is 30 minutes, see §4; please, read §8 and §9; if the task is not clear, read this and this; there will be no monetary reward for this job

[0crat]

@llorllale/z this job was assigned to you 5days ago. It will be taken away from you soon, unless you close it, see §8. Read this and this, please.

[llorllale]

@amihaiemil

a map that would hold the actual filters

Why a map? What would be the keys and values of this map?

I understand now. Are you sure you want it implemented as a Map<String, String>? Since there are only a limited set of filters, wouldn't we want to have types defined for those?

Your answer fill probably be No but I want to make sure. :)

[llorllale]

@0crat waiting for feedback

[0crat]

@0crat waiting for feedback (here)

@llorllale The impediment for #154 was registered successfully by @llorllale/z

[llorllale]

@amihaiemil aren't #153 and #154 asking for the same thing?

[amihaiemil]

@llorllale Yes, pretty much... I looked over this once, a few weeks ago, and I think I came to the conclusion that one of these tasks is obsolete. Could you refuse it until I figure it out? These days I am also rather busy and do not have as much time for OSS :(

[llorllale]

@amihaiemil do you think there is a more elegant way forward than just overloading the Docker.images() method?

[amihaiemil]

@llorllale

do you think there is a more elegant way forward than just overloading the Docker.images() method?

I'm not sure what you mean by this :D
In this ticket we should add a Map of filters to the class ListedImages. The class should remain immutable, only add filters via the ctor -- that is, from Image.filter(...) we will simply new ListedImages(..., modifiedMap);. So actually this ticket and #153 are not the same thing.

I wanted to find a more elegant way since, like this, we will have that filtering map duplicated accross different implementations of Images... sadly, I couldn't come up with a suitable solution, so I say we do it like this and maybe decide on refactoring in the future.

Makes sense? :D

[llorllale]

@amihaiemil I see.

So you want the solution to look like:

docker.images().filter(...) -> Images

.. instead of:

docker.images(filter) -> Images

[llorllale]

@amihaiemil I think your solution may be viewed as inconsistent.

I would expect docker.images().filter(...) to also be reflected on the docker.images() instance that I already possess. Kinda weird, don't you think?

[amihaiemil]

@llorllale The initial Images you get from docker.images() basically contains all the images, with no filters applied. Then, if you want to apply some filters, you use Images.filter(...).

And, if you call Images.filter(...) multiple times, the final Images instance will indeed respect all of them. Passing the map of filters to the docker.images(...) method has a few problems IMO:

1. you oblige the user to pass a Map (even an empty one) from the start, or you have to overload .images()

2. SRP is a bit broken since now Docker knows something about filtering, which it is not supposed to. The docker client shouldn't care if the Images, Containers etc can or cannot be filtered.

3. Filrering multiple times will cause procedural code for the client since they will have to manually fetch the existing filters of the Images they got, iterate over them and put them in a new Map, together with the new filters, which they will pass again to docker.images(...)

Makes sense? :D