#1.0.5 computed property function name limitations?

[jongeho1]

Hey Guys,

I upgraded from 1.0.4 and 1.0.5 and noticed there are new limitations for naming computed property functions.

Example:

<link rel="import" href="bower_components/polymer/polymer.html">
<link rel="import" href="bower_components/layout/layout.html">


<dom-module id="sample-element">
  <template>
    <h1>#1</h1>
    <div>{{_computeJonsFavorite(GestaltGroupingLaws)}}</div>
    <h1>#2 (doesn't work)</h1>
    <div>{{nextMostFavorite}}</div>
    <h1>#2 (for real)</h1>
    <div>{{nextMostFavoriteThatWorks}}</div>
  </template>
</dom-module>

<script>
  Polymer({
    is:'sample-element',
    behaviors:[],
    properties:{
        gestaltGroupings:{
          type:Array,
          value: function(){
            return [
             "Proximity",
             "Similarity",
             "Closure",
             "Symmetry",
             "Common_Fate",
             "Continuity",
             "Good_Gestalt",
             "Past_Experience"
           ];
          }
        },
        GestaltGroupingLaws:{
          type:Object,
          computed:'toKeys(gestaltGroupings)'
        },
        nextMostFavorite:{
          type:String,
          computed:'_setNextMostFavorite(GestaltGroupingLaws)'
        },
        nextMostFavoriteThatWorks:{
          type:String,
          computed:'_nextMostFavorite(GestaltGroupingLaws)'
        }
    },

    _computeJonsFavorite:function(gestaltKeys){
      if(gestaltKeys)
          return gestaltKeys.Symmetry;
      return "";  
    }, 
     _setNextMostFavorite:function(gestaltKeys){
      if(gestaltKeys)
          return gestaltKeys.Proximity;
      return "";  
    }, 
    _nextMostFavorite:function(gestaltKeys){
         if(gestaltKeys)
          return gestaltKeys.Proximity;
      return "";
    },
    toKeys: function(gestaltGroupings){
         if(gestaltGroupings){  
          var obj = {};
          for(var i=0; i < gestaltGroupings.length; i++)
            obj[gestaltGroupings[i]] = gestaltGroupings[i];
          return obj;   
         }
         return {};
    }
});
</script>

What is the preferred means for staying current on limitations of function and property names? I poked around in the docs and primer but was unable to locate this. I can definitely use "_", "_compute" or "_update"; however, more concerned about keeping up with limitations.

Let me know if the example or question is not clear!

Best

@jongeho1

[kevinpschaaf]

In v1.0.5 we made computed properties implicitly read-only, since users should never set computed properties directly. That had a side effect of computed properties getting the conventional private setter created (e.g. _setNextMostFavorite), by virtue of it being treated as a read-only property.

This was probably an oversight; the computed property logic does not actually use that named setter, so it need not create it. We'll fix that in the next release.

The only thing you should be aware of for naming conflicts going forward is that readOnly: true properties will get a setter named _set<PropertyName> on the prototype.

[jongeho1]

Thank you, the "0.5" label for version may not apply. Would something like this be candid for hydrolysis? I don't know how volatile this may be but can be observed via static analysis.