NULL: the worst mistake of computer science
-
-
The problem with
Optional<T>
is that it is pointless ifT
is nullable.
-
And, as pointed out in the other thread, a bit weird if
Optional<T>
itself is nullable.
-
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.
-
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.
-
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 anOptional<T>
class for C#, for instance. You don't need a language syntax extension like{T}?
forNullable<T>
in C#.
-
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.
-
Why would I write an implementation of
Optional<T>
if the standard library contains
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?
-
It's just the zeroes that don't do anything. Those lazy fuckers. If it weren't for the ones, they'd be nothing.
-
Are you the kind of person who implements multiplication using only bit shifts and NAND gates
Asked by the guy who uses BIT.
-
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.
-
T can be any value type including struct
only applies to structs
???
-
This post is deleted!
-
No, ben, not
???
,==
. I don't get why you use postfix notation, though.
-
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.
-
It's a bit odd that they make that distinction, since enums are structs as far as I know. You just declare them differently.
-
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.
-
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.
-
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
(whichenum
s inherit) inherits fromSystem.ValueType
, as dostruct
s. Enums aren't structs themselves.
-
(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)
-
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#.
-
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.
-
So, when you want differing implementation for THING.doAThing, OTHER.doAThing, any way to avoid the switch i.e. branch?
-
You want differing methods for each value? WHY!?
Lets see... if your enum was
Months
and you wanted aGetDays()
method maybe? But even then, you'd just retrieve the value from a dictionary. Nope, sounds like you want something dumb.
-
For instance I have an enum of strategies.
-
Dictionary. Hashtable.
-
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.
-
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.
-
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);
-
My point is, ValueType isn't something you can ever use.
struct
stands in for it in user code. Declaring something withstruct
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.a polymorphic method slapped on anything like an actual vtable(-or-equivalent).
Sounds terrible.
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.
-
-
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.
-
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.
-
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#...
-
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.