QmlWeb/Qml.js/Design Questions and Decisions: Difference between revisions
Akreuzkamp (talk | contribs) No edit summary |
Akreuzkamp (talk | contribs) No edit summary |
||
(6 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
This page intends to collect questions about software architecute and software design, pros and cons as well as the decisions made on the topic. | This page intends to collect questions about software architecute and software design, pros and cons as well as the decisions made on the topic. | ||
==Runtime Architecture== | == Runtime Architecture == | ||
===Getter/Setter Technique=== | === Getter/Setter Technique === | ||
Possibilities: | Possibilities: | ||
; Two methods getProperty(index) and setProperty(index, value): | |||
* ''pro:'' super fast and memory efficient in all browsers (doesn't require closures or the like) | |||
* ''con:'' not nice to read | |||
* ''note:'' requires use of property indexes and a properties array (see below) | |||
; C++ style getters and setters: | ; C++ style getters and setters: | ||
: ''this.width(); and this.setWidth(width);'' | : ''this.width(); and this.setWidth(width);'' | ||
* C++ style | * ''note:'' C++ style | ||
* fast in all browsers | * ''pro:'' fast in all browsers | ||
; Transparent getter/setter using Object.defineProperty | ; Transparent getter/setter using Object.defineProperty | ||
: ''Object.defineProperty(this, "width", { get function(){}, set: function(){} });'' | : ''Object.defineProperty(this, "width", { get function(){}, set: function(){} });'' | ||
* nice while debugging | * ''pro:'' nice while debugging | ||
* worse performance in IE | * ''con:'' worse performance in IE | ||
* horrible performance in Firefox | * ''con:'' horrible performance in Firefox | ||
; Transparent getter/setter using literal notation | ; Transparent getter/setter using literal notation | ||
* nice while debugging | * ''pro:'' nice while debugging | ||
* worse performance in IE | * ''con:'' worse performance in IE | ||
* you can't use object literals and inheritance at the same time in a standard compliant manner | * ''con:'' you can't use object literals and inheritance at the same time in a standard compliant manner | ||
Benchmark: http://jsperf.com/getter-setter/7 | Benchmark: http://jsperf.com/getter-setter/7 | ||
'''Decision:''' Use | '''Decision:''' Use getProperty and setProperty. | ||
=== Storing properties === | === Storing properties === | ||
Line 29: | Line 33: | ||
; Using property objects and direct object references | ; Using property objects and direct object references | ||
; Using property indexes and a properties array | ; Using property indexes and a properties array | ||
* If done right, it might provide weak references | * ''pro:'' If done right, it might provide weak references | ||
; Using a properties object and access it per name | ; Using a properties object and access it per name | ||
* Bad bad bad performance | * ''con:'' Bad bad bad performance | ||
Decision: Use property indexes and a properties array. | |||
=== Handling bindings === | |||
; Let the bindings depend on each other and make them set the value on update | |||
* ''pro:'' Seems logically like the right thing. After all it's the bindings that define the dependencies | |||
* ''con:'' How to know when a property gets overwritten and thus the binding is invalidated? | |||
; Let the properties depend on each other and make them reevaluate the binding when needed | |||
=== Module Handling === | |||
The relevant point here is how to handle the case that in two different contexts, two different modules are loaded, which contain two different types with the same name. | |||
The possibilities to handle that are: | |||
; Always create a namespace, not only when imported with ''as'' | |||
* Makes generated code bigger and less readable | |||
; Alternatives? | |||
=== Possibly use a global pointer array to create weak references === | |||
* ''pro:'' As fast as a direct reference (within the limits of accuracy of the measurements) | |||
=== Object properties === | |||
Some QML basic types, like color or QQuickAnchors, are object types and thus have properties themselves, like color.r or anchors.left. How to access/set their properties? |
Latest revision as of 15:37, 14 March 2015
This page intends to collect questions about software architecute and software design, pros and cons as well as the decisions made on the topic.
Runtime Architecture
Getter/Setter Technique
Possibilities:
- Two methods getProperty(index) and setProperty(index, value)
- pro: super fast and memory efficient in all browsers (doesn't require closures or the like)
- con: not nice to read
- note: requires use of property indexes and a properties array (see below)
- C++ style getters and setters
- this.width(); and this.setWidth(width);
- note: C++ style
- pro: fast in all browsers
- Transparent getter/setter using Object.defineProperty
- Object.defineProperty(this, "width", { get function(){}, set: function(){} });
- pro: nice while debugging
- con: worse performance in IE
- con: horrible performance in Firefox
- Transparent getter/setter using literal notation
- pro: nice while debugging
- con: worse performance in IE
- con: you can't use object literals and inheritance at the same time in a standard compliant manner
Benchmark: http://jsperf.com/getter-setter/7
Decision: Use getProperty and setProperty.
Storing properties
As we're using setters and getters in either way, we need to store the actual property value separated. There're multiple possibilities for that:
- Private member using closures
- Private member using like _width
- Using property objects and direct object references
- Using property indexes and a properties array
- pro: If done right, it might provide weak references
- Using a properties object and access it per name
- con: Bad bad bad performance
Decision: Use property indexes and a properties array.
Handling bindings
- Let the bindings depend on each other and make them set the value on update
- pro: Seems logically like the right thing. After all it's the bindings that define the dependencies
- con: How to know when a property gets overwritten and thus the binding is invalidated?
- Let the properties depend on each other and make them reevaluate the binding when needed
Module Handling
The relevant point here is how to handle the case that in two different contexts, two different modules are loaded, which contain two different types with the same name. The possibilities to handle that are:
- Always create a namespace, not only when imported with as
- Makes generated code bigger and less readable
- Alternatives?
Possibly use a global pointer array to create weak references
- pro: As fast as a direct reference (within the limits of accuracy of the measurements)
Object properties
Some QML basic types, like color or QQuickAnchors, are object types and thus have properties themselves, like color.r or anchors.left. How to access/set their properties?