AEModernMCPort / Applied-Energistics-3-Fork

A Minecraft Mod about Matter, Energy and using them to conquer the world..
http://ae-mod.info/
Other
37 stars 12 forks source link

Replace use of Guava's Optional with Java 8 Optional #81

Closed shartte closed 7 years ago

shartte commented 8 years ago

This also has some benefits with regards to code:

for( final Block block : energyCell.maybeBlock().asSet() )
{
   ...
}

These pseudo loops can be replaced with:

energyCell.maybeBlock().ifPresent( block -> ... )
yueh commented 8 years ago

It is not that straightforward actually. But there are some interesting snippets like

choices.stream().map( choice -> choice.maybeStack( 1 ) ).filter( Optional::isPresent ).findFirst().orElseGet( () -> Optional.of( new ItemStack( Blocks.CHEST ) ) ).get()

but still sucks compared to scala with something like

choices map _.maybeStack(1) filter _.isPresent head getOrElse ItemStack( Blocks.CHEST )
choices map ((_, 1)) filter _.1.maybeStack(_.2).isPresent head getOrElse ItemStack( Blocks.CHEST )

and it also sucks that java has no tuples.

Also there are few cases, where it is really subpar compared to guavas one. But these are pretty much code smell (abusing a pseudo for to early return from a method).

It is something to have everything as final is really useful, as you cannot pass non final variables to them.

shartte commented 8 years ago

It is something to have everything as final is really useful, as you cannot pass non final variables to them.

Pass non-final variables to what? I don't follow what you mean

yueh commented 8 years ago

This is not possible as long as foo is not final.

Object foo = new Object():
optional.ifPresent( o -> syso(foo) );
shartte commented 8 years ago

It actually should be.

Lambdas use the concept of implicitly final.

edit unless you assign foo to sth else later in the function

yueh commented 8 years ago

A good amount of the current usage of optionals us it to either reassign the variable within the lambda or later (like a for loop)

But yes, if the compiler can defer that the variable is effectively final it can ignore it. But it still has the usual problem with implict stuff, you change it later and it breaks something completely else.

shartte commented 8 years ago

It's always with regards to local variables though, so whatever you break is directly within your field of view and causes an immediate IDE red squiggle :)

Elix-x commented 8 years ago

is directly within your field of view

Unless your method is 1000 lines long :D ...