Comments on: Data Model Change Eventing http://blog.palantirtech.com/2009/05/27/data-model-change-eventing/ Articles from the Engineering Group at Palantir Technologies Mon, 07 Jun 2010 12:21:26 -0700 http://wordpress.org/?v=2.8.6 hourly 1 By: Alex http://blog.palantirtech.com/2009/05/27/data-model-change-eventing/comment-page-1/#comment-208 Alex Tue, 23 Jun 2009 16:12:03 +0000 http://blog.palantirtech.com/?p=968#comment-208 I've started to migrate away from PCS to the EventBus framework. Overall, the EventBus static mechanism is much easier to work with and the weak references help protect you from memory leaks, something very likely with PCS. I’ve started to migrate away from PCS to the EventBus framework. Overall, the EventBus static mechanism is much easier to work with and the weak references help protect you from memory leaks, something very likely with PCS.

]]> By: DerekC http://blog.palantirtech.com/2009/05/27/data-model-change-eventing/comment-page-1/#comment-207 DerekC Fri, 05 Jun 2009 22:35:44 +0000 http://blog.palantirtech.com/?p=968#comment-207 We've found that in most cases, cloning the collections isn't a significant performance hit. Of course, there are exceptions. We have a table component which scales to hundreds of thousands of rows. When items are added or removed, the table's model fires events containing those specific items. For example, if a call is made to addItems(), it fires an ITEMS_ADDED event with the added items. This approach requires the listeners to deal with more event types but is necessary in some cases. Regarding the immutability of collections: in general, we treat collections as immutable objects by wrapping them with the appropriate Collections.unmodifiable* call. This removes ambiguity over whether collections are mutable (they are not) and prevents assumptions and errors. We’ve found that in most cases, cloning the collections isn’t a significant performance hit. Of course, there are exceptions. We have a table component which scales to hundreds of thousands of rows. When items are added or removed, the table’s model fires events containing those specific items. For example, if a call is made to addItems(), it fires an ITEMS_ADDED event with the added items. This approach requires the listeners to deal with more event types but is necessary in some cases.

Regarding the immutability of collections: in general, we treat collections as immutable objects by wrapping them with the appropriate Collections.unmodifiable* call. This removes ambiguity over whether collections are mutable (they are not) and prevents assumptions and errors.

]]> By: Solerman http://blog.palantirtech.com/2009/05/27/data-model-change-eventing/comment-page-1/#comment-206 Solerman Thu, 04 Jun 2009 19:25:10 +0000 http://blog.palantirtech.com/?p=968#comment-206 Doesn't giving both collections, new and old, give a performance drawback? Do you work with collections as immutable value objects as well? Doesn’t giving both collections, new and old, give a performance drawback? Do you work with collections as immutable value objects as well?

]]>