PROPOSAL: Improved Support for Optional Object Behaviors at Runtime

[Artur Biesiadowski]

Gabriel Belingueres wrote:
> I don't get it. You still need an "if" after you call the getExtension
> method (thus the client code is not more object-oriented than using
> instanceof).
>
>   
Idea here is that object doesn't have to implement all the interfaces it 
provides as 'getExtension'.

For example, you could imagine some kind of persistence-aware objects, 
which delegate actual work to specialized classes. Instead of having 
Person implementing SQLSerializable interface, you would have 
getExtension class returning some kind of specialized wrapper (probably 
retrieved from some kind of externally configurable factory), and you 
would have to implement only one method delegating things further 
instead of all the methods of SQLSerializable. Of course, it can be also 
implemented by having a method like 
getPersistenceWrapper(TypeOfPersistence) on object - but OP propose to 
have one method to solve all the needs.

I don't really see a major benefit here. For it to be really useful, it 
would have to be somehow dependent on internals of the object (in other 
case you can just make a application dependent static method accepting 
object and target interface). At the same time, there would have to be 
some incentive for the object to not implement the actual interface (not 
exposing public methods, maybe some performance benefits because of some 
kind of caching in wrapper object, without polluting the main object 
with fields required to implement the interface).

In highly dynamic systems/environment, with a bit of trickery it could 
be used to 'inject' interfaces into existing classes/objects. Still, I 
think that some kind of outside mediator is better for that rather than 
putting it in object itself.

Regards,
Artur Biesiadowski