Hi Lars,
I was thinking that IOption and
IOptionCategory should have both methods:
IBuildObject
getParent();
IHoldsOptions
getOptionsHolder();
They would actually do exactly the same
thing and having both is just an “ease of use” feature for
developers.
What do you think?
Regards,
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lars.Kurth@xxxxxxxxxxx
Sent: Thursday, May 19, 2005 12:02
PM
To: CDT General developers list.
Subject: RE: [cdt-dev] MBS -
Questions to Options and OptionCategories
Leo,
>
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.
That
is exactly the case here, or lets say there is no MBS grammar out there yet
which would trigger the new functionality.
> 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?
Yes,
this is also the reason why IOptionCategory does not implement getParent(), but
getTool(). The problem is that getParent()'s from different interfaces
implement different getParent() functions with inconsistent return values. In
fact you can replicate this by introducing getParent() with a return type other
than Tool into IOptionCategory. I spent almost a day trying to find a way to do
this and did not get anywhere.
> Is there a way for Java to handle that?
I do
not know. I am not really a Java expert.
The
only way how to retain the name is to change the signature, i.e. void
getParent(IHoldsOptions options) - that is not nice.
Or to
use a common return value, i.e. IBuildObject getParent(). The latter could
cause some side-effects as I believe that there would only be one instance of
getParent().
> 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.
OK,
but I will wait for the outcome of this e-mail thread.
Regards
--
Lars
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent
by: cdt-dev-bounces@xxxxxxxxxxx
19/05/2005 16:41
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,
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.
1.
IOptionCategory: deprecated ITool getTool(), added IHoldsOptions getHolder() - could not
use getParent() because of namespace problems
2.
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:
3.
IOptionCategory: deprecated ITool getTool(), added IHoldsOptions getHolder() - could not
use getParent() because of namespace problems
4.
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_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev