[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
