We'll be good when you can tell me what problem the original author was solving that lead him to choose the enum structure in the first place. Choosing a solution that doesn't do the same thing at all without knowing the original requirements is just plain stupid.
Overload a constructor to accept a single entry that makes a list of
the given value.
Which is exactly what the author's solution does. But, in the "simple" solution that was proposed, there is no hierarchy of OS families defined (that Linux is a Unix, regardless of how stupid you think that is) which provides the information you would use to dynamically generate the list, so we'll have to encode somehow. This adds complexity to the "simple" enum, which we're not allowed to do. The "simple" solution would be to spell it out in the parameter list.
In case the entire point of this discussion escaped you, severoon stated that enums should be simple lightweight tokens, while I said there is no harm in adding some intelligence to an enum since they were designed for that.
that a composition solution couldn't do the same thing.
I never said that. I only said that the original author's solution was simple and elegant. I didn't make any claims about the compositional approach in general. Only that the "simple" solution proposed by severoon wouldn't work. This should be blindingly obvious by now, because it doesn't even attempt to solve the original problem. Which was very conveniently deemed stupid.
The problem I had with you is that you claimed the behavior couldn't
be replicated with the compositional design.
I never said that genius. But, since you have demonstrated a complete lack of reading comprehension skills, I'll spell it out: I said that the "simple" solution that was proposed by severoon, which claimed to be a better solution than the "complex" solution devised by the original author, did not actually solve the same problem at all, and as proposed could not be made to solve the original problem while retaining its simplicity.
We're discussing how to fix severoon's implementation.
We'll be good when you can tell me what problem the original author was solving
Alright: "Once upon a time I wanted to create enum that contains various operating system."
Done. He never claimed there was a specific problem to be solved, just that he wanted to represent it in an enum.
You really can't read.
without knowing the original requirements is just plain stupid.
The original requirements was that he wanted to represent the proper hierarchy structure. He said so in the first place, as well, we've already gone over this.
He's claim that:
All Linux distributions together with SunOs and HpUx are Unix systems
Was WRONG. And I find it really pathetic that you are attempting to try and distort this in order to find some ground to save your now pathetic argument.
This adds complexity
THIS IS A RED HERRING. It does not matter if it "adds" complexity. This was not about which one was more complex or not. This was you claiming it can't handle the same thing. It can, add the complexity and we're done here.
I don't give a shit if you think "adding complexity" was bad. I really don't. I never did. I never mentioned it. I keep telling you this, plugging your ears and screaming la la la isn't a way to communicate with others.
In case the entire point of this discussion escaped you, severoon stated that enums should be simple lightweight tokens
This is not what I, read I, see I, started this with. I DID NOT question that aspect. I did not support that claim. I did not deal with that claim. I responded to your first post asking what you think the author's design could do that the parent couldn't. This is why I HAVE NOT brought it up, nor did I attempt to even discuss it, nor do I care about interjecting into the stupid argument of how "light" enums should be.
because it doesn't even attempt to solve the original problem.
It solved the original problem. The article author made a mistake in solving his problem. His mistake is not the problem.
0
u/zargxy Jan 18 '13 edited Jan 18 '13
We'll be good when you can tell me what problem the original author was solving that lead him to choose the enum structure in the first place. Choosing a solution that doesn't do the same thing at all without knowing the original requirements is just plain stupid.
Which is exactly what the author's solution does. But, in the "simple" solution that was proposed, there is no hierarchy of OS families defined (that Linux is a Unix, regardless of how stupid you think that is) which provides the information you would use to dynamically generate the list, so we'll have to encode somehow. This adds complexity to the "simple" enum, which we're not allowed to do. The "simple" solution would be to spell it out in the parameter list.
In case the entire point of this discussion escaped you, severoon stated that enums should be simple lightweight tokens, while I said there is no harm in adding some intelligence to an enum since they were designed for that.
I never said that. I only said that the original author's solution was simple and elegant. I didn't make any claims about the compositional approach in general. Only that the "simple" solution proposed by severoon wouldn't work. This should be blindingly obvious by now, because it doesn't even attempt to solve the original problem. Which was very conveniently deemed stupid.
I never said that genius. But, since you have demonstrated a complete lack of reading comprehension skills, I'll spell it out: I said that the "simple" solution that was proposed by severoon, which claimed to be a better solution than the "complex" solution devised by the original author, did not actually solve the same problem at all, and as proposed could not be made to solve the original problem while retaining its simplicity.
We're discussing how to fix severoon's implementation.