IssueTracker

Surely this is something that the developer can handle themselves. If they just have a reference to the Marker then add a custom property to the marker and use that as the id, I don't think we need to start adding more info to Marker objects for everyone.

I would need more use cases where this is out of the developers hands before I would consider putting this in the API.

If there was a property name that was guaranteed to be safe - then sure. Theoretically any property name longer than three characters won't conflict with a closure-compiler renamed property, but this could break things:

myMarker.a = "test".

This would also be fixable by having a sub-property for objects that was designated for developers to add to.

Here's more justification as to why this would be useful: https://groups.google.com/d/topic/closure-compiler-discuss/gpM9o1sYOYc/discussion

I'll re-open the bug. I agree and I can see the utility.

In the past, I've used MVC properties (marker.set('id', 1)) to make sure my custom properties aren't compiled down to names that may conflict with internal properties. You could use 'data' as a generic property that holds a generic data object.

New developers tend to have a hard time using MVC property syntax. And while it's a great solution, it's not exactly obvious. Just to illustrate the point, your suggestion is the first time I'd even thought about solving the problem in that manner.

I think "data" is a great name for this.

It's not perfect, though. As you said, we could start using any name in the API in the future (there are no reserved names)

For example, we use 'data' as a property name on HeatmapLayer.

I think I would prefer it if, as part of the maps API specification -- though feel free to make this a general principle across *all* google APIs -- there were

(1) some kind of declaration to the effect that MVC property names of a particular form are reserved for API users,... "reserved" meaning they are guaranteed not to be set or referenced by this or any future version of Google's maps API

(2) some convention for developers of independent libraries for use with google.maps to follow for their own custom/internal properties (i.e., to ensure they likewise won't get stomped, that they'll play well with other libraries and so that it's easy to tell just from looking who owns what).  For total overkill, you set up a registry for this, but that part can probably wait.

E.g., names beginning with underscore followed by an alphanumeric are reserved for API users and any given independent library author is advised to use a common prefix beginning *and* ending with underscore (e.g., "_widgetlib_") for its own custom properties and that prefix should be advertised so that users of the library know what to stay away from.  

I'll grant that if we ever get weak object hashing in javascript, or, equivalently, the ability to use object references directly as property names + weakness so that the properties thus named aren't actually counted as referencing the respective objects meaning they never prevent the objects from getting GCed and just automatically disappear themselves -- which then allows people to keep custom properties values on the side where nothing in the original object implementation can ever stumble onto them, then this whole problem goes away.

But we're not there yet, and, I suspect, won't be for quite a while.