null is ok as long as checking for it is effortless and the fact that something might return null is either clearly documented or checked at compile-time (preferably both). if those conditions are not met, avoiding nulls wherever possible is a sane choice. with current popularity of fluent APIs (understandable: they make pipeline-like operations less painful), there's nothing worse than having to convert code like this: hax() .my() .anus()
to this: x = hax() if x: shit = x.my() if shit: FUCK = shit.anus()
Name:
Anonymous2019-01-09 13:42
compile-time null checking is 100% cancerous and just bloats the code with obvious null checks that are created by a snippet and never thought about
Name:
Anonymous2019-01-09 14:26
>>5 if something cannot return null, it should be possible to prove it to the compiler so that it won't force you to add obvious checks. either that or a concise null-checking syntax like the null-conditional operator .? in C#
>>4 Monads win again! hax >>= my >>= anus or do a <- hax b <- my a anus b
Name:
Anonymous2019-01-10 7:27
>>8 monads are a nice syntax for doing that, but I'd say having nulls be their own type as opposed to a pointer to address 0, and nullable functions either having multiple returns or returning a union of actual return and null, would be enough for compiler-enforced null checking. monadic error handling makes it less boilerplatey, which is a big plus.
What do you mean by that? A null type? Something like bottom or unit?
null is already a bottom type. the point is for it not to be one - so that the compiler will complain if you try to use it as a value
Functions that return pairs? How would that help?
it's not the best approach because it ends up being verbose, but think of it like go-style error handling applied to nulls: if a function doesn't return what it usually returns, it returns an error value indicating that the normal return didn't happen.
So, like Maybe in haskell?
yes. Maybe in haskal, std::optional<> in sepples, Optional<> in Java etc.
>>15 There is a special null type, the type of the expression null, which has no name. Because the null type has no name, it is impossible to declare a variable of the null type or to cast to the null type. The null reference is the only possible value of an expression of null type. The null reference can always be cast to any reference type. In practice, the programmer can ignore the null type and just pretend that null is merely a special literal that can be of any reference type.
>>23 class Anus { public static void main (String[] args){ System.out.println(null instanceof Object); } } output: false
Name:
Anonymous2019-01-14 8:43
>>23 also: Object type defines several general-purpose methods like clone(), notify(), equals(), hashCode() etc. that are then inherited by all the Java's classes (as they all inherit from Object). null implements no such method:
Object anus = null; anus.equals(null); this code would work if null was an actual Object but it will crash instead.
Name:
Anonymous2019-01-14 8:59
What about:
class Anus { public static void main (String[] args){ System.out.println((Object)null instanceof Object); } } ?
Name:
Anonymous2019-01-14 10:09
>>26 also false. same goes for assigning null to a variable of type Object.