Compute v2: Clean up availabilityzones - #466

I'm OK with renaming these, but this is a mouthful, especially when it's used in user code. Here, it seems (to me) like availabilityzone.Ext is clear. I'd like to hear suggestions, with an eye toward keeping it succinct yet clear when used in user code.

I agree that this one is a mouthful. Maybe ServerAZExt?

The naming pattern that I have in mind for these extensions is ParentType-Extension-Ext. The reason for this is to make sure the extension is easily recognizable with its parent type, since both will be under separate packages.

If this was named just AvailabilityZoneExt (or even AvailabilityZone), it wouldn't be immediately recognizable that it is intended to extend the Server result.

I suppose it's possible that an extension could be applied to more than one parent. I don't know if it's a good idea to enable/allow, that, though. That kind of flexibility might create confusion and odd ways of applying extensions (I don't have a specific extension in mind that is reusable, just thinking of a possible case).

With regard to availabilityzone.Ext, IIRC, there is an issue when embedded/anonymous structs have the same name. So something like this wouldn't work:

var foo struct {
  servers.Server
  availabilityzone.Ext
  tenantid.Ext
}

there is an issue when embedded/anonymous structs have the same name

That's right, I remember now. I'm now in favor of this.