Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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
  1. Have ITool extend IBuildObject as now AND also extend IBuildObject
  1. 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
  1. 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.
  1. Tool will contain an instance of HoldsOptions.
  1. The methods implementing IHoldsOptions in Tool are acting as a veneer of the real implementation in HoldsOptions. The performance hit should be minimal.
  1. 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. **********************************************************************

Back to the top