Many setters have implicit assumptions of state.

[mbostock]

For example:

• arrow.map cannot be changed after initially set (or set to null).
• map.container cannot be changed after initially set (or set to null).
• map.container must be set before adding anything to the map.
• layer.id cannot be changed after the layer is added to the map.
• layer.size cannot be changed after tiles are loaded.
• layer.zoom cannot be changed after tiles are loaded.
• image.url cannot be changed after tiles are loaded.
• ... etc.

Ideally, all of these should be changed to allow objects to be reconfigured independent of whatever state they are currently in. If that is not possible, the limitations should be clearly documented and an error should be thrown.

[mbostock]

Some of these were fixed in 2.0.3, but not all.

[mbostock]

The layer.id restriction was fixed in 2.1.0.

[mbostock]

More fixes in this commit:

http://github.com/mbostock/polymaps/commit/0cfd05321bffb7492b83db73314c58eef32a3b9b

I think the remaining stateful bugs are limited to:

• map.tileSize
• map.container
• geoJson.clip

There's also the issue that url.template and url.hosts can't be changed after add, unless you re-assign the url property on the given layer, or call layer.reload() manually. But I think that's fine.

[mbostock]

And geoJson.clip is now fixed:

http://github.com/mbostock/polymaps/commit/692eb1c45647c4bec8e9dfd1bf2c7d73a4b7e95f

I think the last two will be part of the 3.0 release, since the change from container to parent won't be totally backwards-compatible.