phetsims/axon

Deprecate PropertySet

Closed this issue · 67 comments

As discussed in #71 and #101, PropertySet creates more problems than it solves and should be deprecated. The recommended pattern is described here #71 (comment)

with reset and disposal as described here:
#71 (comment)

If anyone wants to argue that PropertySet should be kept/fixed/etc, that should happen here. Otherwise, this issue is about how and when we will move away from PropertySet. Some possibilities:
(a) Replace all PropertySet occurrences now up front, then delete PropertySet immediately.
(b) Leave existing PropertySet occurrences for now, but no new code will use PropertySet
(c) When PhET-iO instrumenting a simulation, refactor away from PropertySet

We also have the possibility to refactor PropertySet as @pixelzoom described in https://github.com/phetsims/phet-io/issues/640 as an intermediate solution.

@jessegreenberg @pixelzoom @aadish @andrewadare @jbphet @jonathanolson please comment below and we'll decide at an upcoming developer meeting.

@jonathanolson proposed keeping ES5 get/set in #71 (comment) and I responded in #71 (comment)

We have to decide in #71 before doing anything here.

Over in #71, we decided to move away from PropertySet. So it's constructor should be annotated as @deprectated.

PropertySet constructor and its public public functions as now annotated as @deprecated.

Labeling for developer meeting to decide how to proceed with refactoring away from PropertySet.

The repositories below use PropertySet. Shall we make an issue for each repository?

common code:

  • joist
  • scenery-phet
  • sun
  • vegas

simulations:

  • area-builder (JB/DB)
  • arithmetic (JB/DB)
  • balancing-act (JB/DB)
  • balloons-and-static-electricity
  • bending-light (SR/DB)
  • blackbody-spectrum
  • build-a-molecule (JO)
  • calculus-grapher (JO)
  • capacitor-lab-basics
  • charges-and-fields (MV)
  • circuit-construction-kit-basics (SR/DB)
  • color-vision (CM)
  • curve-fitting
  • energy-skate-park-basics (SR)
  • faradays-law (JB/DB)
  • fluid-pressure-and-flow (MK)
  • forces-and-motion-basics (JG/MB)
  • fraction-comparison
  • fraction-matcher (SR)
  • friction (JB/DB)
  • gravity-and-orbits (JG/MB)
  • gravity-force-lab-basics
  • john-travoltage
  • least-squares-regression
  • masses-and-springs
  • molecule-shapes (DB)
  • molecules-and-light (JG/MB)
  • neuron (JB/DB)
  • ohms-law
  • optics-lab (MV)
  • pendulum-lab (JO)
  • projectile-motion
  • proportion-playground
  • protein-synthesis (SR)
  • resistance-in-a-wire
  • rutherford-scattering (JG/MB)
  • seasons (some intern sometime - CM)
  • sugar-and-salt-solutions (SR)
  • trig-tour (JG/MB)
  • wave-on-a-string

There are 160 occurrences of PropertySet.call and 20 occurrences of new PropertySet.

I removed PropertySet from simula-rasa, blast, chains and vegas.

@ariel-phet recommended to create 30+ issues, one per each repo. Even better: Let's add a note to the "how to instrument" doc to this effect.

@pixelzoom says we should fix the common code that uses propertyset. @pixelzoom will create issues for that.

@jbphet will tackle ButtonModel.

I'm going to reopen this issue until we actually delete PropertySet.

Can this be un-tagged for developer meeting?

PropertySet has been expunged from common code, and is currently used only in sim-specific repositories. And we decided that we'll expunge from sim-specific code as we instrument for PhET-iO. So yes, looks like we can remove the developer meeting label. And I believe that we can also close this issue.

Hello,

I added a method to Property.js to help in porting away from PropertySet. Consider the PropertySet code:

function SomeConstructor(){
  PropertySet.call(this,{
    name:'test',
    age:123
  });
  ...
}

When converting to Property, you can add this check to make sure you catch all ES5 getter setter references:

function SomeConstructor(){
  this.nameProperty = new Property( 'test' );
  this.ageProperty = new Property( 123 );
  Property.preventGetSet(this,'name');
  Property.preventGetSet(this,'age');
}

Then any code anywhere else that tries to set variable.name or variable.age will throw an assertion.

Best Regards,
Sam

Linked to commits related to preventGetSet. I marked it as @deprecated, since it should not appear in production code, and should be deleted once PropertySet is gone.

That seems good, should we also recommend putting it behind asserts so it is stripped for production code?

assert && Property.preventGetSet(...);

... should we also recommend putting it behind asserts so it is stripped for production code?

Why would it be in production code? It's presumably a debugging tool. Developers should add it, run tests, then remove it.

Developers should add it, run tests, then remove it.

Sounds great.

How about moving preventGetSet to PropertySet, instead of Property? Then it will go away when we delete PropertySet. And developers will be encouraged to remove it from their code so that they can remove the var PropertySet = require(...) statement.

I created "convert from PropertySet to Property" issues for all sims that haven't been published yet. For new sims, I don't see any reason why the conversion shouldn't be done before publishing.

Reopening this because @samreid and I seem to still be working on it.

Re #102 (comment)...

How about moving preventGetSet to PropertySet, instead of Property?

Changed my mind - I think it's fine in Property.

Before closing this, let's confirm our decisions regarding "conversion of PropertySet to Property" at the next developer meeting. My understanding is:

• Convert existing sims when they are instrumented for PhET-iO.
• Convert new sims before publishing.
• Do not create any new code that uses PropertySet.

... and feel free to convert earlier, at developer discretion.

Developers agree with the bullet points above, there was a suggestion to give this to Denzell as a chip-away task.

I updated the above checklist, by removing sims that no longer use PropertySet.

Whoops, I accidentally deleted the checklist. Someone please paste it back in!

I reviewed current usage of PropertySet, and checked off sims that appear to have been converted. Some progress, but still many sims (24) using PropertySet.

Reference phetsims/projectile-motion#18 for discussion on how most of these can be taken care of.

Note to self, delegate

Bending Light is checked off after the above commits.

CCK basics fixed after the above commit.

Protein synthesis complete.

Finished sugar-and-salt-solutions above.

Energy skate park basics completed, but it was much more complex and hence requires assistance from the QA team when the time is right. I created an issue phetsims/energy-skate-park-basics#371 for that and I'll check it off the list since it is no longer using PropertySet.

The SR sims mentioned in #102 (comment) are checked off and no longer using PropertySet, so I'll unassign myself.

Curve-Fitting was converted from PropertySet to Property back in March. I closed the issue today (phetsims/curve-fitting#104) .

@samreid put you back as an assignee since there were a couple of sims in your wheelhouse I had not labelled for you before (apologies)

Thanks, it's good to be back!

rutherford-scattering was done today, phetsims/rutherford-scattering#119 is closed.

Forgot to mark, handled Pendulum Lab today.

I added assignees based on #102 (comment) but wasn't sure of the GitHub account name for MB

optics-lab was converted to PropertySet (see phetsims/optics-lab#7)

Friction has been converted to Property from PropertySet.

Area Builder is done.

Charges and Fields is done.

@jessegreenberg and I have completed trig-tour

I did seasons while running some memory leak tests for another sim. "Some intern" will thank me.

Molecules and Light is converted. See phetsims/molecules-and-light#144.

Balancing Act is converted, see phetsims/balancing-act#81.

Remaining issues in Neuron were addressed. Reference phetsims/neuron@2045f48

@ariel-phet said @samreid should get CCK out for testing before @samreid works on this much more.

Arithmetic is now done.

Faraday's Law is converted. Reference phetsims/faradays-law#77

@ariel-phet if I end up taking over fliud-pressure-and-flow, I could help in converting it from propertySet if that would be helpful.

Fraction matcher is all set.

Fluid Pressure and Flow has 75 Properties, so it will take quite a long time to convert. Before starting on it, I'd like @ariel-phet to comment on @zepumph's note:

@ariel-phet if I end up taking over fliud-pressure-and-flow, I could help in converting it from propertySet if that would be helpful.

@ariel-phet who should work on FPAF? Or should we split it up?

@ariel-phet asked if @zepumph could work on Fluid Pressure and Flow, I'll reassign him in the checkbox comment.

@ariel-phet says current priority is "no rush, would be good to be done in a couple of months"

Does the preceding comment refer to FPAF, or all remaining sims?

8/17/17 dev meeting: Recollection is that @ariel-phet meant "no rush" on all remaining sims, not FPAF specifically.

PropertySet removed from Gravity and Orbits.

PropertySet was removed from forces-and-motion-basics. That was all the sims assigned to @jessegreenberg and @mbarlow12 so removing our assignments.

I tackled a few spots in Fluid Pressure and Flow this week.

PropertySet() was converted for Molecules-Shapes. I don't have any more sims to convert so I am removing my assignment.

Removed PropertySet from Build a Molecule. Past self apparently used new PropertySet( {} ) and trigger/on for what we now use Emitter for.

Removed my assignment.

I finished removing usages of PropertySet then I deleted PropertySet. I'm going to let Bayes use preventGetSet for a few days in Fluid Pressure and Flow before deleting that. Also leaving this issue open in case there is anything else to discuss about it. Is the next step to "eliminate" Events? #83 Eliminate is in quotes because we may keep it or a variant of it for scenery node.

UPDATE: #142 seems a better reference for emitter/events.

Agreed, #142 is the reference for converting Events to Emitter.

Looks like our work here is done?

Good work everyone, that was a biggy!