| 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@xxxxxxxxxxx
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. **********************************************************************
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.
********************************************************************** |