+1 for using the existing ResourceManager for SWT resources; it's mature code that has worked well for us.
As far as Strings go Wikipedia indicates that java already does some form of this through a technique called 'interning', why should we try to compete? A quick google lead to some suprising (to me) optimizations such as using substrings of existing interned strings to represent others... Onwards, Eric Boris Bokowski/Ottawa/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/14/2008 05:13 PM Please respond to E4 developer list <[email protected]> To E4 developer list <[email protected]> cc Subject Re: [eclipse-incubator-e4-dev] Avoiding Bloat > I'm thinking about a SINGLE ImageRegistry / StringRegistry > (could also be a database), from which plugins can acquire > an image/String by means of a Key (that could be an int > number, for instance). At the time a bundle is installed, all > its images / Strings are placed into the common Database. > Clients get a Key in return, which they can use at runtime > to retrieve their data. Identical data is collapsed. > > Sounds interesting? Or am I missing something? Uninstalling > a bundle would certainly not be easy, and I guess that the > String and Image database would likely be an add-only thing > to avoid lifecycle issues. We have had great success in the past with JFace's LocalResourceManager. As long as the keys are not taking up more space than what you save through collapsing the real data, it sounds like a good idea. LocalResourceManager is an object whose lifecycle is managed by its owner (usually some plugin), so lifecycle issues are not that problematic. Each resource manager has a parent resource manager, but all resources (in the JFace case: Images, Colors, Fonts) are managed at the root resource manager, and reference-counted there. By disposing your LocalResourceManager, the reference counts for all resources you contributed get decremented automatically. This also avoids the Singleton pattern... your all-caps SINGLE made me extremely nervous. ;-) Not sure how you would use something like this for strings though. Given a list of potentially not unique string objects, you can use a hash to uniquefy them, but it's computationally expensive if done synchronously and eagerly. (The resources plugin will uniquefy all strings used for markers, but it's done in a background job: https://bugs.eclipse.org/bugs/show_bug.cgi?id=244631#c9) Boris_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
_______________________________________________ eclipse-incubator-e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev
