Repository navigation
[Address] Allow to extend address collection #523
Description
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 :)
Activity
egeloen commentedon Aug 22, 2016
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 commentedon Aug 22, 2016
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 commentedon Aug 22, 2016
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 commentedon Aug 22, 2016
@willdurand AN interface would allow me to respect the contract of the main interface (returning an
AddressCollection) whereas for now I can only use theAddressCollectionsince it's final.With an interface, I will still have to re-implement the
AddressCollection&Adresslogic by my own, but it's a start...Can you clarify why do you make the result objects final?
egeloen commentedon Aug 22, 2016
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 commentedon Aug 23, 2016
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 aextra(orraw) 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 commentedon Aug 24, 2016
Ok, knowing that, I close the issue. It goes against the main goal of the library...
willdurand commentedon Aug 25, 2016
That is not what I meant @egeloen
Nyholm commentedon Sep 9, 2016
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.
vandalouze commentedon Oct 7, 2016
And #421 too
unkind commentedon Oct 8, 2016
Just my 2 cents, I think you can provide vendor-specific interfaces like
GoogleGeocoder,OpenStreetMapGeocoderwith 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:
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.
Nyholm commentedon Oct 14, 2016
@egeloen would you have a look at #529 to see if that satisfy your needs?
Nyholm commentedon Dec 22, 2016
Closed by #529
topikito commentedon Aug 29, 2019
Hi all - Not sure if I should post here or open a new issue, but this is a matter that has been discussed on several other issues.
I come here searching for a
rawor a way to create custom response objects (ResultFactory?). The need comes because some providers return really rich results (like Open Cage Data).I've read comments suggesting for returning the result in
raw#523 #529, and others referencing toResultFactory, however, I don't see any documentation or references to this anywhere here or on the website.What would be the right way to do this as per today?