Hi Lars,
I agree with your proposal.
Thanks,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Sent: Tuesday, May 17, 2005
3:32 PM
To: CDT
General developers list.
Subject: 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.
**********************************************************************