[Address] Allow to extend address collection

[egeloen]

Hey!

I would like to discuss an issue before you release the 4.x. Basically, in egeloen/google-map, I have added my own provider which allows to get full informations from the Google geocoder (and not just a subset as it is done here for consistency between providers).

Anyway, since the AddressCollection is final, I don't know how I can respect the contract of geocode and reverse (returning an AddressCollection) and at the same time being able to add more behaviors to it. In the doc, I explicitely explains that I broke the contract of geocode and reverse on purpose but it would be nicer if I can respect it...

Maybe introduce an interface for an extension point?

Feedbacks really welcome :)

[egeloen]

I see that @Nyholm gives me a 👍 :) So, if there are no objections, I will make a PR tonight in order to introduce an interface.

[Nyholm]

I gave a 👍 because I like the timing of this issue and because I like extensibility. I do believe in creating an interface because it will make us more SOLID.

[willdurand]

Yep, having an extension point to expose more data or, at least, access raw data from providers, would close a lot of issues... Yet, I don't see how an interface will fix the issue.

[egeloen]

@willdurand AN interface would allow me to respect the contract of the main interface (returning an AddressCollection) whereas for now I can only use the AddressCollection since it's final.

With an interface, I will still have to re-implement the AddressCollection & Adress logic by my own, but it's a start...

Can you clarify why do you make the result objects final?

[egeloen]

I'm also 👍 for your idea about adding a new methods returning extra data. Then, I can use it instead of trying to extend the Address* models.

[willdurand]

Can you clarify why do you make the result objects final?

The initial idea was to provide some sort of value objects, only because I believe(d?) in a common layer for all the providers. That has always been the purpose of this lib, so that you could switch to any provider and you would end up with pretty much the same data. I know that it does not allow extension but it was intended. That's the "contract" of the lib.

Yet, more and more users want to extend the lib to get extra data. While I believe they should not use the lib for that, I also have to admit that Geocoder became the de facto Geocoding lib in PHP. Hence, Geocoder v4 should be more open by providing extension points or a way to expose per provider extra data.

I did not think much about it, but maybe we could extend Address-* models/factories with a extra (or raw) bag, which would be super flexible (that is, we could put it pretty much anything, depending on the provider?) This should be backward compatible, this should not involve too much work/refactoring, and it should cover 99% of use cases.

But as I don't really use the lib, I trust @egeloen on that (and other users). If it seems good to you, then let's do that!

[egeloen]

Ok, knowing that, I close the issue. It goes against the main goal of the library...

[willdurand]

That is not what I meant @egeloen

[Nyholm]

I've added #529

I'm considering the extra field. It is not very good for interoperability but it is awesome for extensibility. Having an extra field/method would solve #522, #441, #409 and many more.

[aight8]

And #421 too

[unkind]

I did not think much about it, but maybe we could extend Address-* models/factories with a extra (or raw) bag, which would be super flexible

Just my 2 cents, I think you can provide vendor-specific interfaces like GoogleGeocoder, OpenStreetMapGeocoder with vendor-specific methods, concepts, etc. There is no reason to break the original abstraction. This is what they actually want: they want to get a data from specific vendor.

We shouldn't forget what abstraction is:

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise

So if you end up with an array as a "super flexible" solution, you make your abstraction vague and, hence, you're doing it wrong.