Hi Lars,
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.
That is fine as long as it doesn’t
break any existing functionality. That is, it is OK, for example, if
there is UI for a feature that is not yet supported. There will likely be
some submits before next week that you will have to synchronize with –
hopefully, they won’t be too disruptive.
- 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
I would like to keep the getParent methods
as we defined below to be consistent with other elements that have getParent
methods. Is the namespace problem when Tool implements IOptionCategory?
Is there a way for Java to handle that? I thought I saw something like
that in some Java code that I was looking at recently but I don’t
remember how it was done. Also I suggest the name getOptionsHolder rather
than getHolder, as it is more descriptive.
Thanks,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Thursday, May 19, 2005 11:21
AM
To: CDT
General developers list.
Subject: 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