Hi Thomas,

I agree with how you decided to do it defining the functional interfaces 
one layer below assembler (actions, page, scheduledjobs, screen..) keeping 
the different method names and the changes minimal.

We may continue think about checked exceptions, that is, if we really want 
retain the checked exceptions - but I am fine for now.

Nonetheless removing the checked exceptions might be worth to be 
considered in a second move (release, later) ..

Best regards, Georg

P.S. What about valve? We may make this a functional interface as well and 
use e.g. spliterator in TurbinePipeline. But same here, it may be worth 
the effort only (getting cleaner code, be close to java functional 
lambdas), if removing/better handling the checked exceptions..




Von:    Thomas Vandahl <[email protected]>
An:     Turbine Developers List <[email protected]>
Datum:  04.03.2019 19:21
Betreff:        Re: Change modules to interfaces



Hi folks,

On 04.03.19 09:52, Georg Kallidis wrote:
> Making use of the functional interface just straight as in your code 
might 
> be the best choice keeping some valuable name conventions (java Consumer 

> interface definition might be similar).

Thanks for your input. I tried to implement Assembler as an extension to
Consumer<PipelineData> but got bitten by the limitation that the whole
functional stuff cannot handle checked Exceptions.

I'm open to suggestions how we could get around this. I'd really like to
simplify the whole mess of Loaders, Factories, Brokers and such.

Bye, Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to