Re: [platform-ui-dev] Architecture question on the lack of IWorkbenchAdv

[Nick Edgar <Nick_Edgar@xxxxxxxxxx>]

Ed,

The difference lies in who is expected to implement the particular 
contract, and how contracts can grow given the rules of Java binary 
compatibility.

In the case of WorkbenchAdvisor, the application is expected to implement 
the contract, although we provide some default behaviour in 
WorkbenchAdvisor.
If we want to grow this contract in the future, we can do so simply by 
adding new methods to WorkbenchAdvisor.  If there was an interface 
(IWorkbenchAdvisor), it could not be changed without breaking existing 
implementations.  The only way to evolve it safely would be to define a 
new interface, e.g. IWorkbenchAdvisor2 extends IWorkbenchAdvisor.

In the case of IWorkbenchConfigurer, the workbench implements the 
contract, not the application.  This is implemented in 
WorkbenchConfigurer, which is an internal class, not part of the API.
If we want to evolve this contract, we can do so by adding methods to the 
interface since the only implementation is WorkbenchConfigurer, which is 
owned by us.
To enforce this, we have marked WorkbenchConfigurer as final.

Now, it is true that in other places in the workbench APIs, we've defined 
the contract for certain extensions as an interface but then specified 
"don't implement this interface directly, subclass this class instead". 
For example, when implementing a view, plugins are expected to subclass 
ViewPart and not directly implemen IViewPart.  Of course, the Java 
language visibility rules can't prevent anybody from directly implementing 
the interface, although if they do, they are violating the API contract 
and can expect to get broken in the future. 

In the case of WorkbenchAdvisor, we explicitly decided to depart from this 
pattern since we felt that there was a good amount of default behaviour we 
could provide in the abstract class, and that the interface wouldn't add 
much value.

Hope this clarifies,
Nick





"Ed Burnette" <Ed.Burnette@xxxxxxx> 
Sent by: platform-ui-dev-admin@xxxxxxxxxxx
12/03/2003 10:05 PM
Please respond to
platform-ui-dev


To
<platform-ui-dev@xxxxxxxxxxx>
cc

Subject
[platform-ui-dev] Architecture question on the lack of IWorkbenchAdvisor 
and the use of final in some classes






I just noticed there is a WorkbenchAdvisor abstract class but no 
IWorkbenchAdvisor interface, at least in M5. Was this deliberate or just 
an oversight?

Compare that to WorkbenchConfigurer and IWorkbenchConfigurer. But... I 
just noticed WorkbenchConfigurer and some other new internal ui classes 
are declared "final" - isn't this also going against pattern?

--Ed
_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-ui-dev