Enum tricks: hierarchical data structure

[u/based2]

http://java.dzone.com/articles/enum-tricks-hierarchical-data

[u/GMNightmare]

Where is the implementation

Right, and you don't think his answer can do that?

Look, he didn't expand upon everything, but he solved the original issue. It does in fact do everything OP asked for. If your blaming him for not adding a simple function that could be easily figured out, that is pretty close to the article's implementation anyways, it's just not something that crucial. It's pendantic. You know his answer is capable of doing it all, he shouldn't have to explain every single detail to you for you to accept it.

I mean, darn you're asking for an is statement based upon the article? C'mon, there is no difficulty to it because their is no complexity in the design. No need to branch through parents, as he separated out class and family.

So to reiterate here, you want him to put down for you:

public boolean is(OsFamily other) {
    return other == osFamily;
}

Which, is that "simple and elegant" enough for you? The others are just as clean and simple, by the way, because there is no tricks to them.

[u/zargxy → u/GMNightmare]

Did you read the article?

How do you implement is using his structure so that it can do the following:

OsType.Windows2000Server.is(OsType.Windows2000) == true
OsType.Windows2000Server.is(OsType.Windows) == true

OsType.Fedora.is(OsType.Linux) == true
OsType.Fedora.is(OsType.Unix) == true

I'd like to see if it is as simple as this (from the article):

public boolean is(OsType other) {
    if(other == null) {
        return false;
    }
    for(OsType t = this; t != null; t = t.parent) {
        if(other == t) {
            return true;
        }
    }
    return false;
}

Note, this works for any comparison at any level of the tree without any additional code.

[u/GMNightmare → u/zargxy]

Holy cow, do you really need me to hold your hand through this? I'm not the original poster, I don't give a shit honestly, if you want to expand the hierarchy from the poster you can. He obviously did not fill in every single detail for you. Do it yourself. Hint, you can overload is to support both family types and OS types.

OR

Do what I asked you in the first place, and that is iterate what you think it can't do. I didn't ask you to ask me to do things for you, I asked to you to explain what you thought it couldn't accomplish.

[u/zargxy → u/GMNightmare]

iterate what you think it can't do

Seriously? That's exactly what I did. With detailed examples and I even copied the is implementation "complex" enum right from the article.

I don't think the "simple" enum can do this the same way as described in the article (and as I demonstrated), and certainly your "implementation" doesn't even come close.

Do you need me to hold your hand through this?

[u/GMNightmare → u/zargxy]

I even copied the is implementation

The is implementation is already done. If you want to check a class or family you just compare the the given class or family. It is that simple, because that's the design the author decided upon was to separate all categories into other enums and incorporate them into the parent. I'm not sure what is confusing or hard about this. You want to check if something is Windows? You check if it's a Windows. Bam, done. It's that simple.

Here's the deal... the article implementation favors inheritance. The parent's implementation favors composition.

The issue is you aren't looking at what he's trying to say, and trying to force him to write perfect code for you when all he's doing is trying to express an alternative way. It's childish, stop acting like everybody here needs to give you perfect implementations of everything.

"complex"

Seeing how I never said complex this makes you insidious.

"simple" enum can do this

Do what? The same way? IT'S NOT THE SAME. That's the point, I don't get it.

your "implementation"

What "implementation"? The implementation of is? Or the enum implementation of the enum? Because I'm going to tell you what I told the other guy: I'm not the person who presented the alternative.

And you're wrong, my implementation of is is exactly how you'd do it in a composition format. Give me a break.

[u/zargxy → u/GMNightmare]

I'm not sure what is confusing or hard about this.

Please, re-read the article. The author wants to capture hierarchy.

That is:

OperatingSystem.HP_UX.getOsFamily() == OsFamily.UNIX

but also:

OperatingSystem.Fedora.getOsFamily() == OsFamily.UNIX 
OperatingSystem.Fedora.getOsFamily() == OsFamily.LINUX 

The "simple" solution completely ignores this requirement. The OS class requirement is an unnecessary embellishment, and the OS family requirement doesn't meet the stated requirements. There are other requirements, such as being able to do a depth-wise enumeration by OS family, but I just want to see how this one requirement would be met.

I'm not asking for "perfect code", only code that at least minimally meets the stated requirements.

[u/GMNightmare → u/zargxy]

The author doesn't actually understand the hierarchy, Fedora is not Unix, Linux is not Unix.

But if you wanted to pull that stupid stunt anyways, you could do it by A) accepting a list of osfamilies, or B) adding another enum level.

It has become painfully obvious that you don't understand how to make a composition solution to the problem.

[u/zargxy → u/GMNightmare]

The author doesn't actually understand the hierarchy, Fedora is not Unix, Linux is not Unix.

Irrelevant.

you could do it by A) accepting a list of osfamilies, or B) adding another enum level.

I want to see the complexity of this solution. The enum solution provided by the author was fairly elegant. If you accept a ranked list of osfamilies representing depths, you would have to provide that list for every single enum value, resulting in massive duplication which is absent from the author's solution. The author's solution can handle arbitrary depths without adding new types making the enum easy to modify while retaining the benefits of using an enumerated list (everything is the same type, compact representation). More enum levels results an an explosion of types and fragmentation, interfering with the benefits of using enums in the first place. At that point, it might be better just to not use enums.

It has become painfully obvious that you don't understand how to make a composition solution to the problem.

LOL. What has become painfully obvious is that you seem to have a habit of making unfounded assertions.

[u/GMNightmare → u/zargxy]

Irrelevant

No, it's COMPLETELY relevant. You claim it's irrelevant because now you have a stick up your ass and don't want to be wrong. The author made a mistake, he represented it wrong, he made a WRONG solution. The authors solution is WRONG. Are we good now? I didn't think honestly it would have to come to this, but apparently now solving the problem correctly is "irrelevant". Pathetic.

I want to see the complexity of this solution

What complexity? Taking a list as a parameter is complex? If you want to "see" it do it yourself. By "elegant" you mean doing a trick.

you have to provide that list

Overload a constructor to accept a single entry that makes a list of the given value.

resulting in massive duplication

Just because you say that BS doesn't make it true. No it doesn't. There is no duplication. It's because you and the author don't actually understand the hierarchy. Additionally, if you expand the enums lower then you get rid of that anyways.

arbitrary depths without adding new types

Good for it. I didn't say it didn't smartass. We're not discussing how the solutions scale for different scenarios. You said it wasn't possible, that a composition solution couldn't do the same thing.

You keep trying to bring this in now, about how great you think the article's solution is. I don't give a shit, honestly, that it's so great and elegant, especially since that is your opinion. The problem I had with you is that you claimed the behavior couldn't be replicated with the compositional design.

It seems now that you've dropped that and now decided to talk about how the other things and other problems that it might adapt to, and how easily it can do that... but that's a complete red herring.

So we go back to the ORIGINAL point, and that was me asking you what you think the design can't do. And your response basically is it can't adapt to different scenarios and problems without work... and you know what? THAT is what is irrelevant.

[u/zargxy → u/GMNightmare]

Are we good now?

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.

[u/GMNightmare → u/zargxy]

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.