Re: [dsdp-tm-dev] API breaking change in IHostFileToRemoteFileAdapter: n

[Kevin J Doyle <kjdoyle@xxxxxxxxxx>]

+1

_____________________________________________
Kevin J Doyle
Software Developer, Rational Developer for System i
IBM Toronto Lab 
Email: kjdoyle@xxxxxxxxxx

From:	Xuan Chen/Toronto/IBM@IBMCA
To:	Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>
Cc:	"Target Management developer discussions" <dsdp-tm-dev@xxxxxxxxxxx>, dsdp-tm-dev-bounces@xxxxxxxxxxx
Date:	06/03/2008 02:07 PM
Subject:	Re: [dsdp-tm-dev] API breaking change in        IHostFileToRemoteFileAdapter:        need your opinion

---

+1 

Regards,

Xuan Chen,  Problem Determination Tools for iSeries
(905) 413-3769 T/L 313-3769
xuanchen@xxxxxxxxxx

"Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>
Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxx

06/03/2008 12:13 PM

Please respond to
Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>

To	"Target Management developer discussions" <dsdp-tm-dev@xxxxxxxxxxx>
cc
Subject	[dsdp-tm-dev] API breaking change in IHostFileToRemoteFileAdapter:        need your opinion

Committers, 
  
While working on bug
233461 (Refresh expanded folder
under filter refreshes Filter), 
DaveM and I found that the way our IHostFileToRemoteFileAdapter is currently
defined is not entirely consistent, and does less compile-time type checking
than would make sense. 
  
The two methods in the adapter currently return IRemoteFile types, but
in reality 
it doesn't make sense to return any IRemoteFile that isn't actually an
AbstractRemoteFile. 
  
I would therefore like to change this API as per bug
235363 . This is a breaking
API change because any implementer of an IFileService will need to adapt
his 
source code; but it does not break semantics in any way, since the
return 
value would have had to be an AbstractRemoteFile anyways. 
  
Read more details on the bug, and comment with +1/0/-1 on the bug please.
  
I know that this is a VERY LATE breaking change, but I'm very confident
that doing this now is for the best of our clients since it allows for
better 
static type checking and thus more safety. 
  
Thanks, 
-- 
Martin Oberhuber, Senior Member of Technical Staff, Wind
River 
Target Management Project Lead, DSDP PMC Member 
http://www.eclipse.org/dsdp/tm
  
 _______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev
_______________________________________________
dsdp-tm-dev mailing list
dsdp-tm-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev