Community
Participate
Working Groups
From bug 240523 comment #8: > 17 DelegatingTerminalService -- I think that we should probably have an > AbstractDelegatingTerminalService as API in the services plugin, just like > we do for the AbstractDelegatingConnectorService, since many clients can > re-use this in order to augment behavior of an ITerminalService. Also, > this would work around the @noimplement restriction on ITerminalService -- > clients cannot legally implement ITerminalService. But we may need a bit > more thought on this.
Created attachment 124476 [details] patch that makes required refactoring I think it makes sense to have AbstractDelegatingTerminalService as an API. I'll check the patch in after M5 candidate is out.
Checked in the patch.
To me it seems wrong to have AbstractDelegatingTerminalService#getDescription() AbstractDelegatingTerminalService#getName() return a hardcoded name ("Generic Terminal Service"). Shouldn't it return the name of the service that it is delegating to? Assume that the "real" one is a Telnet Terminal Service, which a client decides to decorate with some specific functionality. IMO the name/description should still be "Telnet Terminal Service", or some other name that the client decides by overriding getDescription() and getName(). Or am I missing something?
(In reply to comment #3) > To me it seems wrong to have > > AbstractDelegatingTerminalService#getDescription() > AbstractDelegatingTerminalService#getName() > > return a hardcoded name ("Generic Terminal Service"). Shouldn't it return the > name of the service that it is delegating to? > > Assume that the "real" one is a Telnet Terminal Service, which a client decides > to decorate with some specific functionality. IMO the name/description should > still be "Telnet Terminal Service", or some other name that the client decides > by overriding getDescription() and getName(). > > Or am I missing something? Martin, you're right. I'll check in the fix today.
Done.
