| Re: [eclipse-pmc] Add back an old method from 3.3 (detected as an API addition since 3.4M6a) |
eclipse-pmc-bounces@xxxxxxxxxxx wrote on 05/02/2008 02:57:50 AM:
> ...
> More seriously, if you find that growing the size of .class files
> is an issue, then this should be a discussion topic for the arch
> call. Should we have some rules where a component cannot add more
> than x% new methods in a release?
>
I'm not sure how serious you are being here. Obviously, such a rule would be problematic. However, I do believe that we have to remain sensitive to the problem. Adding methods _really_does_ have a cost, one that directly impacts our consumability.
As to discussing this in the arch call, that's a great idea. Let's start the conversation next week. I, for example, would be perfectly will to consider having us make a systematic effort to reduce the size (and number) of class files we create as part of the 3.5 effort. One possibility would be to create a set of refactorings that supported the kinds of transformations this would require. Of course, the problem with anything like this is that it's difficult to do without effecting readability, etc.
> Should there be some static
> analysis on each build to control the size of the meta info used
> by each component?
>
It would probably be useful. What would that look like?
> >
> > Separate from that, adding back the method, with a body that is
> > known to fail, also seems bogus -- why would we want people to fail
> > at runtime, when removing the method would allow them to detect the
> > problem at compile time?
> Actually the method is now marked @deprecated, so the misusage will be
> detected at compile time.
>
Ah yes, you're right, of course. Typically though, deprecated methods are still expected to work, are they not?
McQ.