[
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 have implement the changes to the
back-end and will hopefully have completed the UI support for this by tomorrow
or at the latest on Monday. A colleague of mine is working on the callback
mechanism, so we will definitely be able to submit the patch to you a week
before the M7 milestone.
I was wondering whether it would be
OK to submit the changes we have made so far early next week, even though
not all of the proposal is yet fully implemented. The reason for this is
that I had to move quite a lot of code around, so I am getting worried
about keeping the patch and the CVS repository in sync. Please let me know,
whether this is possible. It is only really necessary if others make changes
to the class Tool. So if nobody is changing anything in Tool, then we should
be fine and do not need to submit early. You probably have the best overview
regarding this.
Best Regards
-- Lars
P.S.: The changes I have made differ
slightly from what I first suggested (red).
In fact it worked out somewhat better this way:
1. Introduce
a new interface called IHoldsOptions derived from IBuildObject
2. Have
ITool extend IBuildObject as now AND also extend IHoldsOptions
3. 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
4. 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.
5. Tool
derives
from HoldsOptions.
6. Deleted
this step
7. Do
2- 6 for IToolChain and ToolChain respectively, i.e. IToolChain implements
IHoldsOptions, Toolchain extends HoldsOptions
Further:
- IOptionCategory: deprecated
ITool getTool(), added
IHoldsOptions getHolder() - could not use getParent() because of namespace
problems
- IOption: deprecated ITool getParent(),
added IHoldsOptions getHolder()
- for consistency with IOptionCategory
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
17/05/2005 22:27
Please respond to
"CDT General developers list." <cdt-dev@xxxxxxxxxxx> |
|
To
| "CDT General developers list."
<cdt-dev@xxxxxxxxxxx>
|
cc
| Lars.Kurth@xxxxxxxxxxx
|
Subject
| RE: [cdt-dev] MBS - Questions to Options
and OptionCategories |
|
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:
1. Introduce
a new interface called IHoldsOptions derived from IBuildObject
2. Have
ITool extend IBuildObject as now AND also extend IBuildObject
3. 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
4. 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.
5. Tool
will contain an instance of HoldsOptions.
6. The
methods implementing IHoldsOptions in Tool are acting as a veneer of the
real implementation in HoldsOptions. The performance hit should be minimal.
7. 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.
**********************************************************************
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev