| Re: [e4-dev] Declarative UI |
Ed, Ed Merks wrote:
Given sufficient interest, it would not be all that difficult to create an eEMF. For example, all the specialized lists are great for optimal performance, but a single list can emulated all possible behaviors quite nicely... The Ecore plugin was a one point only 250K in size, but clients always want more and more!
Perhaps we should discuss what limitations are acceptable for eEcore? Like read-only EModelElements? Only binary Resource serialization?
Maybe there's a way to compile the EMF model to straight Java code (like we do for XSWT) and so retain the design-time modelling benefits and keep the small runtime size? Or some other solution?Some folks have generated plain old Java, but in the end, reflection, notification, XML persistence is something the majority of the clients end up needing...
In general, you would want these, but for each specific application the usage may be limited... Tools for deploying mobile applications include an "obfuscation" step, where jars are trimmed by renaming, removing unneeded classes and methods etc. If EMF was included in this step, together with the relevant application classes AND models, I bet the total size could be reduced a lot. (It's a bit like "partial evaluation", whereby a generic program is specialized to a specific set of data). Think of it: Even if you use reflection, you seldom change EClasses, so you could remove all setters. An interesting experiment would be to profile a "typical" EMF application and note which Ecore methods are used and calculate the necessary footprint.
Hallvard