Community
Participate
Working Groups
I've opened several bugs against Zest lately, and the most frustrating part has not been the bug themselves (bugs happen, even to the best programmers), but that Zest has been built in a way to block adopters from tweaking, subclassing, or extending Zest to fix or workaround these problems. Zest is cool and really powerful on it's own, but as a result any problem or minor addition can be like hitting a brick wall. I've run into several cases where the only options are to reimplement/redesign a large part of Zest, or branch the code entirely. Compared with (for example) the Eclipse platform, the code is very defensive towards adopters. Some suggestions: - Export the internal packages in the manifest using x-internal:=true. - Reduce use of private members, or provide protected accessors to them. - Move creation of private members to their own factory methods. - Reduce casting to Zest classes, especially private ones. - Reduce use of private and package-protected methods. - Use coding conventions from Eclipse platform.
We are currently building up the next generation Zest API in terms of GEF4 Zest (which is not so restrictive), and as fundamental (i.e. breaking) changes to the Zest 1.x API will not be performed any more, I am resolving this as WONTFIX.
