Update internal Objects interface names to have Object*/Objects* prefix

[VeskeR]

No description provided.

[lawrence-forooghian]

I think that in the existing types that have a prefix of singular "Object" (ObjectOperation, ObjectState), this prefix makes sense because these types describe something to do with an individual non-specifically-typed object. But I'd suggest that for the types you've changed here, which all relate to a specific type of object, it might make more sense to prefix them with Objects (i.e. plural); this would still indicate that they belong to the feature named "Objects".

[lawrence-forooghian]

e.g. ObjectCounter reads a bit weird (it counts objects?) — ObjectsCounter is still not super clear but if you know that there's a feature called "Objects" then I think it's a bit better

[lawrence-forooghian]

We also don't have any hard rules around naming for types in the spec, so we could also just introduce a namespace — Objects.Counter etc. That might be the clearest.

(then languages can adapt the naming to whatever the language permits)

[sacOO7]

In the case of Java/kotlin, the outcome depends on how you import packages. Ultimately, it will recommend using Counter directly with a full-fledged import statement.

[VeskeR]

Hm, the only thing that makes me slightly uncomfortable with using the plural Objects for a specific type of object is the inconsistency it would introduce between the types used in the spec. Naming everything using the plural Objects is also not ideal, as some types - like ObjectsMessage - can be misinterpreted as a message belonging to an object (i.e., read as "object's message" with an apostrophe).

So basically:

• All Object - sounds a bit odd when referring to a specific type of object.
• All Objects - can be misinterpreted as a possessive form, especially for non-specific types.
• A mix of both - inconsistency in naming.

I think I would lean slightly more towards using plural Objects everywhere, and just rely on the fact that the reader should first understand that they're reading something related to the feature called Objects, then it shouldn't be really a problem.
I'm not adamant on this, so if you think a mix of singualr and plural will work just fine we can go with that approach.

[sacOO7]

I guess we can keep it prefixed with Object, we will have consistency for the naming.

[lawrence-forooghian]

Yeah, I still think that Objects makes more sense — can always just add a line to the spec explaining the naming

[lawrence-forooghian]

To be honest, if the only reason that we were doing this was because the types are named ObjectMap and ObjectCounter in ably-js, we could just rename those two types here (be it plural or not) and not prefix everything LiveObjects-related

also why ObjectCounter in JS? does Counter clash with something in JS? Can we get away with just renaming Map to ObjectsMap and be done with it?

[lawrence-forooghian]

Let's perhaps just discuss this in the next standup and come to an agreement the three of us?

[VeskeR]

updated in https://github.com/ably/specification/compare/7ac745d97245dcd8a7f8630f3a09029a09ac9653..fd3ae6feff97474c6c0e9dead07d118bd0562bd5

[sacOO7]

lgtm

[sacOO7]

small change requested

[VeskeR]

As discussed on the standup, I've updated the names for the interfaces that are related to a specific type of an object to use plural prefix Objects* in https://github.com/ably/specification/compare/7ac745d97245dcd8a7f8630f3a09029a09ac9653..fd3ae6feff97474c6c0e9dead07d118bd0562bd5

ably-js name change in ably/ably-js#2042

[sacOO7]

lgtm