realized i couldn't get all the way into it so lea...

# announcements

[cosmicexplorer (inactive)]

realized i couldn't get all the way into it so leaving it as a WIP for now and will get to it in the next few days, but i'm pretty sure the idea here will work (allowing duplicate PathStats in a Snapshot if they originate from the same base directory): https://github.com/pantsbuild/pants/pull/6500

[gildor]

if(obj != null) is not bad itself
Maybe you could show to your team members good examples how to eliminate nullability in particular cases

[jovmit]

For the code that we don't control there is no other way. We must check the nulls. But I wouldn't agree that we have to make everything nullable in the code we own and control.

[jovmit]

Seems better to get back to Java which btw introduced Optional. But will try showing some nice examples. Thanks for the advice

[gildor]

Back to Java? Why?

[gildor]

Work with Optional is much-much more verbose than with nullable in Kotlin

[gildor]

And also adds overhead

[jovmit]

Right, but I meant even Java tries to wrap the null into am object. The null is not an object and into my eyes simply doesn't fit in the OOP

[jovmit]

Especially not in FP

[gildor]

I disagree

[gildor]

null is completely fine in OOP

[gildor]

and in FP if you not a radical about this

[jovmit]

Well ok. I was asking for arguments against it, not for it :)

[gildor]

Kotlin gives a power or type system and tools to handle nullability gracefully

[gildor]

Because code without nulls looks better, you have less condition, easier to write and support

[jovmit]

And maintain

[gildor]

Just take some class and elliminate nulls where it’s possible to show an example for team mates

[jovmit]

That's something we are going to try for sure. That's great point.

[gildor]

Also some idioms help to improve code with nulls in some cases, like early return, default arguments and so on