[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] MBS - Questions to Options and OptionCategories
|
Leo,
I started doing this and had to duplicate
a lot of code that is now in Tool and essentially had to copy it into ToolChain.
This looks like a bad idea with regards to long-term maintainability.
Thus I have the following suggestion
to make:
- Introduce a new interface called
IHoldsOptions derived from IBuildObject
- Have ITool extend IBuildObject
as now AND also extend IBuildObject
- Move functions that implement
functionality to do with options and categories into IHoldsOptions - this
ensures that ITool will look as it always has done. This would mainly be
the getOption*, getOptions, addOption*, removeOption*, etc. methods
- Implement an object HoldsOptions
which implements IHoldsOptions - essentially this objects holds all the
implementation of functions to do with holding options and categories that
are now implemented in Tool. By moving them into HoldsOptions we only have
one instance of the code and thus better maintainability.
- Tool will contain an instance
of HoldsOptions.
- The methods implementing IHoldsOptions
in Tool are acting as a veneer of the real implementation in HoldsOptions.
The performance hit should be minimal.
- Do 2- 6 for IToolChain and ToolChain
respectively.
For the getParent() methods on OptionCategory()
and Option() the return type would be IHoldsOptions, not IBuildObject as
you suggested.
This would avoid a lot of special casing
and duplicating of code. It is a bit more risky and would make it harder
for you to integrate the patch, than just bolting functionality on.
What do you think? Note that I do not
mind restructuring what I have done so far.
Best Regards
-- Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
12/05/2005 20:00
Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
|
To
| "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
| RE: [cdt-dev] MBS - Questions to Options
and OptionCategories |
|
Hi Lars,
> Do you have any preferences? Note
that I prefer the first approach. Also if I went for the first approach,
would you be happy if I renamed IOptions::getParent() to getTool().
I suggest the following:
getParent is the common method
used by the tool definition elements to return their “build model” parent.
There are a few exceptions when things are a bit more complicated,
e.g. OptionCategories.
OptionCategory: Add a
getParent method that returns IBuildObject (either an ITool or an IToolChain).
OptionCategories are unique in that they have both a IOptionCategory
“owner” (categories can be nested) and, in 2.1, an ITool “parent”.
Now, they can have an ITool or IToolChain “parent”. The getTool
method should be deprecated. Search for “deprecated” in ITool.java
for examples of how to deprecate a method. getTool should continue
to return the ITool when appropriate, else null. Note also that Tool.java
implements the IOptionCategory interface so that you can get there using
getOwner. IToolChain will need to implement that interface also.
Option: This is more
complicated. Ideally, I believe that we should change getParent to
return an IBuildObject. This breaks a “public” interface, but we
have not documented these interfaces yet. If anyone disagrees with
changing this method’s return type, let me know.
Thanks,
Leo
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxxx
Sent: Thursday, May 12, 2005 1:16 PM
To: CDT General developers list.
Subject: [cdt-dev] MBS - Questions to Options and OptionCategories
Hi Leo,
I have a question regarding Options and OptionCategories which is caused
by the implementation work for the Shared Tool Options proposal. The proposal
would allow Options and OptionCategories to be children of ITool and of
IToolChain, depending on what is defined in .buildDefinitions.
Now this means that we have to cater for the fact that the "parent"
of these may either be ITool or IToolchain. Currently
- IOptions defines "ITool getParent()"
and
- IOptionCategory defines "ITool
getTool()"
I have essentially
two choices to handle the interface: either I use getTool() and getToolChain()
for both interfaces, where the invalid one returns null. Or I use "Object
getParent()" and return the appropriate object.
Do you have any preferences? Note that I prefer the first approach. Also
if I went for the first approach, would you be happy if I renamed IOptions::getParent()
to getTool().
Best Regards
-- Lars
**********************************************************************
Symbian Software Ltd is a company registered in England and Wales with
registered number 4190020 and registered office at 2-6 Boundary Row, Southwark,
London, SE1 8HP, UK. This message is intended only for use by the named
addressee and may contain privileged and/or confidential information. If
you are not the named addressee you should not disseminate, copy or take
any action in reliance on it. If you have received this message in error
please notify postmaster@xxxxxxxxxxx and delete the message and any attachments
accompanying it immediately. Neither Symbian nor any of its subsidiaries
accepts liability for any corruption, interception, amendment, tampering
or viruses occurring to this message in transit or for any message sent
by its employees which is not in compliance with Symbian corporate policy.
**********************************************************************
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
**********************************************************************
Symbian Software Ltd is a company registered in England and Wales with
registered number 4190020 and registered office at 2-6 Boundary Row,
Southwark, London, SE1 8HP, UK. This message is intended only for use by
the named addressee and may contain privileged and/or confidential
information. If you are not the named addressee you should not disseminate,
copy or take any action in reliance on it. If you have received this
message in error please notify postmaster@xxxxxxxxxxx and delete the
message and any attachments accompanying it immediately. Neither Symbian
nor any of its subsidiaries accepts liability for any corruption,
interception, amendment, tampering or viruses occurring to this message in
transit or for any message sent by its employees which is not in compliance
with Symbian corporate policy.
**********************************************************************