RE: [mylar-dev] Architectural question...

["Mik Kersten" <beatmik@xxxxxxx>]

The framework makes more use of abstract classes for two different reasons:

1) For APIs it helps insulates clients from our changes.  For example,
abstract classes allow us to add a method that's optional to implement and
provide a default implementation, but making a similar change to an
interface would break the client. 

2) We are continuing to grow the framework around integrators' needs and in
some areas don't have a clear interface in place yet.  This is the case with
AbstractRepositoryTaskEditor, which is currently under rapid evolution to
make it more flexible in the way that you describe for 2.0.  

The best way to ensure that it's flexible enough to support your use cases
is via patches and comments on the corresponding bugs, such as the one you
filed.  When starting on a patch to AbstractRepositoryTask editor please let
us know on bug first because it is likely to see additional refactoring for
2.0M3.  

179254: [api] AbstractRepositoryTaskEditor needs to be decomposed
https://bugs.eclipse.org/bugs/show_bug.cgi?id=179254

Mik

> -----Original Message-----
> From: mylar-dev-bounces@xxxxxxxxxxx [mailto:mylar-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Boris Pruessmann
> Sent: Friday, April 13, 2007 5:05 AM
> To: mylar-dev@xxxxxxxxxxx
> Subject: [mylar-dev] Architectural question...
> 
> 
> Everyone,
> 
> I've got a probably simple question regarding the Mylar architecture.
> If this already has been discussed in the past, feel free to point
> me to some documentation as I don't want to restart a discussions
> that has already been completed.
> 
> I think you've all done a great job in providing a framework that's
> pretty easy to hook into and I greatly appreciate that. On the other
> hand, I've already run into several situations where I wanted to do
> things differently and that couldn't easily be achieved, at least
> not without patching the Mylar source code. And all of those things
> just boil down to one issue: the use of abstract classes instead
> of interfaces (in contrast to abstract classes in conjunction with
> interfaces)
> 
> So my question is this: is there any specific reason why you chose
> this approach? I just want to give you one specific example that's
> troubling me though I could probably come up with others:
> 
> I want to write a page for the task editor that has a completely
> different look and feel than pages based on
> AbstractRepositoryTaskEditor.
> I can return something different (based on IEditorPart) out of my
> task editor factory. Unfortunately that would not behave as first-class
> citizen because TaskEditor includes code fragments that only execute
> against AbstractRepositoryTaskEditor based classes. An interface
> in addition to the abstract class would solve this.
> 
> Anyone? ;-)
> 
> Cheers,
> Boris
> 
> 
> _______________________________________________
> mylar-dev mailing list
> mylar-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/mylar-dev