If you can't use a getter/setter, which format do you prefer?

[rich]

No we can't use that method, you'd get no documentation / code insight support from your IDE if it was all bundled under a single method. Equally the amount of conditionals we'd within those two methods would be huge. Nice approach, but not suitable for our needs.

[Quetzacotl]

I just don't support IE7/8

[Chris]

Why do you need getters/setzers in the first place?

[Quetzacotl]

Um, I answered that before.

 

Because If you will need additional validation or operation on value, then you would have to replace every assignement.

 obj.x = 1

 

 

to 

setX(1) // orset('x', 1)

[Chris]

I know the general concept behind getters/setters

I mean why does @rich specifically need them.

[Quetzacotl]

Oh, ok. But I think no specifics are needed. You use setter/getters to leave yourself open doors if you will eventually need additional operation on set/get. Other way you would have to replace assingments in whole project just to check for example if passed value is a string, it would be really painfull.

[Chris]

I still think Backbones approach is better, since you can have one basic model that you extend/adapt to all objects you might need.

Yes, some IDEs might not be able to support code completion for those attributes, but I develop very complex applications upon backbone and never missed attribute completion in the get/set methods.

If you really forgot what attributes an object has you take a look into the docs or on the objects 'defaults' property which should hold all default attributes of an object.

Also you dont need to use any conditionals in the set method to validate your incoming values. Again, take a look at backbones validation approach, they don't use conditionals, either.

The best would be to not validate at all (by default), because its slow.

[rich]

If you don't validate the parameter given you run the risk of creating random properties on the base object, assigning who knows what to them. Equally using strings to set them opens up plenty of chances for code typos, and I still don't see how documentation generation would be cleanly split up?