I see exactly what you mean and we could build a solid system with the standard get/set methods and change events in some hours. My personal problem with this approach is this: It is really error prone in real world projects. It forces you to work with strings (e.g.: get('myAwesomeVariable')) instead of identifiers. That doesn't work nicely with auto-completion in IDEs like Webstorm and gives you a harder time refactoring variable names etc (not to mention the overhead of calling a function to get/set a property).

The other problem you will run into is the need for a run loop: If you have thousands of events happening at the same time you end up with endless rerenderings (the typical backbone.js problem). Ember.js solves that by introducing a complex and uncomfortable run loop which no one really understands and makes you scream some times while testing.

You see, this would be easy to implement and seems like the perfect solution – until you run into problems in a real world project. This usually happens relatively late in production where the last thing you need is a system that throws problems at you that don't belong to your application's domain.

The reason we don't need this overhead / pitfalls in our current project is: we work with Angular.js – this amazing library simple makes an end to all of this by using a technique long known as dirty checking. This is used in game programming since years and is more performant and much more predictable (hence more comfortable) than typical event-driven systems

If you want that nicely summarized, read on: http://stackoverflow.com/questions/9682092/databinding-in-angularjs

Hope this gives you an idea why the answer to these problems is not so simple as it seems ;-)

Property System? #3

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions