Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] IManagedOptionValueHandler.isEnumValueAppropriate parameter type

On Saturday 05 December 2009 20:38:18 Andrew Gvozdev wrote:

> Hi Vladimir,
> On Sat, Dec 5, 2009 at 8:48 AM, Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>wrote:
> 
> >
> > At present, the signature of
> > IManagedOptionValueHandler.isEnumValueAppropriate
> > is as follows:
> >
> >        public boolean isEnumValueAppropriate(IBuildObject configuration,
> >                        IHoldsOptions holder, IOption option, String
> > extraArgument,
> >                        String enumValue)
> >
> > It seems to be that the type and name of the first parameter are
> > misleading.
> > First, looking at the name one can assume that it's configuration that is
> > passed
> > in (and in fact, IConfiguration does extend IBuildObject). However,
> > in practice IResourceInfo is always passed in -- after upcast to
> > IBuildObject.
> > Second, even assuming IBuildObject can be passed -- what is a poor method
> > to do?
> > There's a dozen interfaces that directly extend IBuildObject, and it's
> > unlikely
> > that any of that dozen can be passed.
> >
> > So:
> >
> > 1. Why is the parameter type so needlessly generic?
> >
> 
> I doubt that somebody can answer the first question. The creators of the
> design are not around anymore.
> 
> 
> > 2. Could this be fixed?
> >
> 
> That could be problematic by the reason of my answer to the first question.
> The best we can do is: a) accept a patch renaming the variable - not
> changing API - and describing your findings in JavaDoc for the function, and
> b) you can create a bug in bugzilla requesting API change (put API word in
> description). All the bugs like that would get looked at when project model
> is redesigned (optimistically, there is a non-zero chance of that)

Can IManagedOptionValueHandler2 be introduced, and the corresponding code modified
to check which one is implemented, at runtime.

It appears that this interface has yet another issue -- the 'enumValue' is actually
what is shown in the UI, not the id of the enumerator. And the thing shown in UI
is somewhat volatile -- e.g. just now out product got a name of enumerator changed
for clarify. Ideally, the id of the enumerator should be passed.

- Volodya


Back to the top