How should we name the tandems for primary group A and secondary group B?

[samreid]

From https://github.com/phetsims/buoyancy/issues/160#issuecomment-2145925951 @zepumph said:

Actually. I don't like the notion of "a" and "b". It should be "primary" and "secondary".

groupA -> primaryMasses aMap -> primaryMassesMap

or whatever you think it best.

Let's consult with @arouinfar

[zepumph]

• [ ] As part of this work, it would be nice to have the shapes screen's modeProperty have a better name.

[AgustinVallejo]

If we follow the naming convention from explore screen we could use shapeA and shapeB. However, in the code they are still referred as primary and secondary, even in the Explore Screen code. If we rename, those should be consistent as well.

[zepumph]

• [x] Studio tree for each model object:

• objectA

  • shapeNameProperty enum : "DUCK" "CONE" "INVERTED_BLARG"
  • shapeProperty
    • { phetioID: "objectA.shapes.cone"} // It would be nice if studio showed the cutout link to the referenced thing here (liked linked element);
  • shapes
    • block
    • cone
    • duck
    • ....
    • ellipsoid

• [x] primaryShapeSizeControlNode -> objectAShapeSizeControlNode

• [x] Internal variable renames too like primary/secondary/aMap

• [x] Don't forget about renaming primary/secondary on other screens that use two block modes called blockA/blockB.

[zepumph]

I also recommend using a class for this structure, so that we don't have to repeat this twice. It could be something like "ShapedMassModel.ts"

[zepumph]

working on this now.

[zepumph]

Still more to do to get the right phet-io tree structure and renames, but good progress.

[AgustinVallejo]

Started replacing but based on the initial comment, decided to stash it, as I'm not totally sure that the decision is. To go from primary to A or viceversa. Personally, I also prefer primary, as MK said originally. PrimarySecondary* is a clearer name than AB* and so on.

So holding for discussion...

[AgustinVallejo]

Addressed I think most of the renamings, there's still some strings, tags and string keys to look into. As well as the three structure

[AgustinVallejo]

Studio tree for each model object:

@zepumph can you please double check that the structure is as it was desired? That item was a bit confusing as there is already a shapeProperty and massProperty in Mass.ts, which were in no way related to the shapeProperty in ShapeModel.ts... could lead to confusions.

[zepumph]

Excellent. I changed the serialization to make it a reference. We don't need a copy of the actual Mass, just a pointer to the one that exists in the shapes collection:

I wish that the shapeProperty could be a DerivedProperty, but I sorta gave up because of the complexity of changeShape(). Oh well! Thanks for doing this, I know it was confusing. Ready to close?

[AgustinVallejo]

Ready to close, bye!