You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
do we need this.map = this.maps[this.api] everywhere? #290
I'm assuming you mean the var map = this.maps[this.api]; pattern here.
The challenge here is that the Mapstraction objects are disconnected from the "native" objects so holding a reference to the native object is a bit dodgy as the provider may have been swapped and you're now pointing to the wrong object.
Something to consider is that, whilst the "swap" feature is nice, I'm not sure who actually uses it and maybe that's costing unnecessary complexity and not providing much benefit.
The challenge here is that the Mapstraction objects are disconnected from the "native" objects so holding a reference to the native object is a bit dodgy as the provider may have been swapped and you're now pointing to the wrong object.
That's helpful. One of the things @gilesc50 and I have discussed is tidying up the namespacing and core way that Mapstraction works. This will help that.
Something to consider is that, whilst the "swap" feature is nice, I'm not sure who actually uses it and maybe that's costing unnecessary complexity and not providing much benefit.
True. Of course, it'd also be nice if we could know who is actually using Mapstraction but interest is continuing from outside of the project so for now that's about all the validation we have.
That said, to me the provider swapping is the key feature and attraction of Mapstraction. If we loose that, we're just a bunch of glorified API wrappers. I wouldn't want to loose this feature unless there's really no other way.
Activity
dezfowler commentedon Dec 4, 2013
I'm assuming you mean the
var map = this.maps[this.api];pattern here.The challenge here is that the Mapstraction objects are disconnected from the "native" objects so holding a reference to the native object is a bit dodgy as the provider may have been swapped and you're now pointing to the wrong object.
Something to consider is that, whilst the "swap" feature is nice, I'm not sure who actually uses it and maybe that's costing unnecessary complexity and not providing much benefit.
vicchi commentedon Dec 4, 2013
The challenge here is that the Mapstraction objects are disconnected from the "native" objects so holding a reference to the native object is a bit dodgy as the provider may have been swapped and you're now pointing to the wrong object.
That's helpful. One of the things @gilesc50 and I have discussed is tidying up the namespacing and core way that Mapstraction works. This will help that.
Something to consider is that, whilst the "swap" feature is nice, I'm not sure who actually uses it and maybe that's costing unnecessary complexity and not providing much benefit.
True. Of course, it'd also be nice if we could know who is actually using Mapstraction but interest is continuing from outside of the project so for now that's about all the validation we have.
That said, to me the provider swapping is the key feature and attraction of Mapstraction. If we loose that, we're just a bunch of glorified API wrappers. I wouldn't want to loose this feature unless there's really no other way.
Also, nice to see you back and commenting here!