WICKET-6774: rework of component state - #424
Conversation
State of a component is no longer stored as an array but using instances of ComponentState. These have a smaller memory footprint in most cases, are more efficient and the code is easier to read (I hope). Note that a small change in behavior is introduced: behavior ids are only maintained for statefull behaviors. Ids can change for other behaviors, also when combined on the same component.
| * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| * See the License for the specific language governing permissions and | ||
| * limitations under the License. | ||
| * Licensed to the Apache Software Foundation (ASF) under one or more contributor license |
There was a problem hiding this comment.
i would restore formatting here :)
There was a problem hiding this comment.
I've found the setting in Eclipse to prevent it from reformatting these headers, hope that helps :)
| * | ||
| * @author papegaaij | ||
| */ | ||
| abstract class ComponentState implements Serializable |
There was a problem hiding this comment.
Why do not create an interface that creates ComponentStates? Then one implementation interface does as it was before and a new one using this approach? Then this could be backported to 10.X and companies can experiment with this too? No idea if using interface is the way to go
There was a problem hiding this comment.
I think I tried interfaces earlier on in this branch, but they were slow. This code lives on very performance critical paths. Every ns makes a difference. I'll resurrect the branch. It was a fun experiment. I'd rather not put this in 10 as it might have some unforeseen side effects.
There was a problem hiding this comment.
What about if:
- Iterfaces are used once application is started to configure something static at component
- Then use this static fixed thing for all components?
Again I haven't tried this thus it might still have the problems you mentioned
State of a component is no longer stored as an array but using instances
of ComponentState. These have a smaller memory footprint in most cases,
are more efficient and the code is easier to read (I hope).
Note that a small change in behavior is introduced: behavior ids are
only maintained for statefull behaviors. Ids can change for other
behaviors, also when combined on the same component.
ComponentStatestill needs documentation, but first let's agree on this approach.