NULL: the worst mistake of computer science

dkf

@Buddy said:

It just is (or is not, depending on your philosophy).

The thing that is that isn't…

PleegWat

The problem with Optional<T> is that it is pointless if T is nullable.

cvi

And, as pointed out in the other thread, a bit weird if Optional<T> itself is nullable.

Captain

You know what? I'm going to ask for a feature request on GHC, to make turning warnings into errors granular, so that Haskellers can have the full benefit of static Nothing checking.

Buddy

It doesn't do much for static correctness checking, sure, but it is useful as a helper class in certain situations, as it allows you to do your null checking as an expression, instead of requiring a full if-else block.

Ragnax

@Buddy said:

just like for doesn't do anything you couldn't do with a goto

You are debating language syntax extensions versions class-level functionality. Anyone can write an Optional<T> class for C#, for instance. You don't need a language syntax extension like {T}? for Nullable<T> in C#.

ben_lubar

@Buddy said:

4) bottom line is: null doesn't actually do anything. It just is (or is not, depending on your philosophy).

Data on a computer doesn't do anything. Therefore, we should never store data on computers.

ben_lubar

Why would I write an implementation of

@Ragnax said:

Optional<T>

if the standard library contains

@Ragnax said:

Nullable<T>

?

Are you the kind of person who implements multiplication using only bit shifts and NAND gates because you don't trust the compiler?

Buddy

It's just the zeroes that don't do anything. Those lazy fuckers. If it weren't for the ones, they'd be nothing.

HardwareGeek

@ben_lubar said:

Are you the kind of person who implements multiplication using only bit shifts and NAND gates

Asked by the guy who uses BIT.

powerlord

Here, let me quote the C# documentation to you:

T is the underlying type of the nullable type. T can be any value type including struct; it cannot be a reference type.

So, the answer to this question is because in C#, Nullable<T> only applies to structs.

ben_lubar

@powerlord said:

T can be any value type including struct

@powerlord said:

only applies to structs

???

powerlord

This post is deleted!

Magus

No, ben, not ???, ==. I don't get why you use postfix notation, though.

powerlord

See also: Value Types

(I got the right documentation this time)

The gist of the above being that only structs and enums can be value types in .NET.

Magus

It's a bit odd that they make that distinction, since enums are structs as far as I know. You just declare them differently.

powerlord

I assume they spell it out because C# is similar to Java, but in Java enums are actual objects. And no, I'm not kidding about that.

Magus

I've heard of this atrocity, but it will not be given my time.

It even has defenders, foul accursed beasts though they may be.

Choonster

@Magus said:

It's a bit odd that they make that distinction, since enums are structs as far as I know. You just declare them differently.

System.Enum (which enums inherit) inherits from System.ValueType, as do structs. Enums aren't structs themselves.

Gribnit

(yawns obscenely and scratches, begins to speak in farting, belching tones)

A Java enum lets you encapsulate all the logic associated with the enumerated type, yes, which is sufficient advantage for many designs to live with this curse and its... consequences. Indeed, the apparent "You can switch on it!" use-case, all that those who can still bear the light of the sun know of, is somewhat deprecated in Java enum usage, at least by me, preferring abstract methods of the enum implemented on each value class.

(babbles "factory factory factory" and continues heaping writhing DTOs on a hideous red and black tree)

Magus

All I know is that when you make a function generic and want it to be constrained to enums, you use struct as one of the constraints. They also all work as numeric types. Enums are really clumsy overall. Anyway, if 'inherits from ValueType' does not equal 'struct' to you, I can't imagine what you think a struct is in C#.

Magus

In C#, we can do things like:

public enum SomeKindOfEnum
{
	Thing,
	Other,
	Whatever
}

public static class SomeKindOfEnumExtensions
{
	public static string DoAThing(this SomeKindOfEnum value)
	{
		return "blah";
	}
}

Which seems to take care of that.

Gribnit

So, when you want differing implementation for THING.doAThing, OTHER.doAThing, any way to avoid the switch i.e. branch?

Magus

You want differing methods for each value? WHY!?

Lets see... if your enum was Months and you wanted a GetDays() method maybe? But even then, you'd just retrieve the value from a dictionary. Nope, sounds like you want something dumb.

Gribnit

For instance I have an enum of strategies.

Magus

Dictionary. Hashtable.

Choonster

I wasn't aware of the struct constraint for enums, I don't think I've ever used a value type as a generic constraint.

I suppose enums pretty much are structs even though that's not really explicitly stated anywhere.

Gribnit

So I need to eat - hash construction, several equivalent-of-vtable hits, etc, etc, sounds great. For what I'd be doing, in C# sounds like the switch is preferable, and, no way to get my differing implementations of a polymorphic method slapped on anything like an actual vtable(-or-equivalent).

Sweeet.

Salamander

@Magus said:

Lets see... if your enum was Months and you wanted a GetDays() method maybe? But even then, you'd just retrieve the value from a dictionary. Nope, sounds like you want something dumb.

C#'s enums are pretty dumb too.
Month m = (Month) (-1);

Magus

My point is, ValueType isn't something you can ever use. struct stands in for it in user code. Declaring something with struct makes it extend ValueType. I really don't get how that makes it separate from an enum; it's just a different keyword used for the declaration.

@Gribnit said:

a polymorphic method slapped on anything like an actual vtable(-or-equivalent).

Sounds terrible.

@Salamander said:

C#'s enums are pretty dumb too.

They're just named numbers. It would be nice if they were better, but they aren't anything complicated.

Gribnit

Lambda is a little bird, sitting in a tree, that smells awful

@Magus said:

Sounds terrible.

Maciejasjmj

@Gribnit said:

For instance I have an enum of strategies.

Make the strategies into objects with a common interface. Why would you stick it in an enum?

Hell, in C#, you can then decorate an enum with types of said objects, so if you really want to switch on strategies for some reason, then you can do

public enum Strategy
{
    [StrategyImplementation(typeof(ZergRush))]
    ZergRush,
    [StrategyImplementation(typeof(Turtling))]
    Turtling
}

and get your strategies from that.

Gribnit

@Maciejasjmj said:

strategies into objects with a common interface. Why would you stick it in an enum?

When there are a fixed and finite number of strategies, and that fact happens to be part of the design, I'd stick them in an enum, because it expresses that point of the design better than interface - abstract base - implementations would. Then I have, for RIGHT_WAY, WRONG_WAY, and MAX_POWER_WAY, something type-safe and (semantically, at least) branchless (physically I expect probably it's still a calculated jump but "predictable" to some arbitrary degree) that embodies doing something one of ThreeWays.

Ragnax

@Gribnit said:

When there are a fixed and finite number of strategies, and that fact happens to be part of the design, I'd stick them in an enum, because it expresses that point of the design better than interface - abstract base - implementations would.

Have a look at System.Text.Encoding in C#...

Salamander

@Magus said:

They're just named numbers. It would be nice if they were better, but they aren't anything complicated.

They wouldn't have to be complicated to not be dumb. They only need to restrict what values you can use to what is actually in the enum.
But because they don't, if you actually have a set of unique things like Month you need to jump through hoops to make sure they actually are the values you say they can be.