Plugin YAML - Main: error

ColonelHedgehog I think you're missing my point.

 

ColonelHedgehog, while it may take more effort, programming properly without nasty shortcuts pays in the long run. Get in the habit now, rather than learning the hard way when you get fired from your first real job.

 

Minecraft has no reason to change the ChatColor prefix. The only time that would ever be necessary would be if Mojang had the sudden desire to screw all users over or if for some wild reason the character was removed from the text format level that Java classes support, which would be equally implausible.

I guess that works if you have zero self control rofl. § is hardly a nasty shortcut, to be honest.

I think I get where you're coming from. But it seems more lazy to wait around for Bukkit to update the ChatColor enum than to replace "§" with whatever new char they replace it with.

I spend much more time than I need to accounting for every single possible circumstance in my code. Example: UUIDs. I don't use names because there's a possibility that Minecraft will eventually add name changing support (they claim it's confirmed, but still). This is because I can't just replace "TheHandfish" with "TheHandfish'sUUID."

Let me just say I'm SO GLAD we can have these calm civilized discussions here. I recently was on a Minecraft API forum which regards debates of any kind with much contempt. The atmosphere here would appear to be a great deal more mature. But I digress.

 

It's still entirely possible. Wasn't the colour symbol something else a long time ago? And what if they stop supporting it over the JSON format? Just because something doesn't seem likely to happen, doesn't mean it won't - your example of UUIDs & name changing is a good example of this - did anyone think that was likely to happen?

Yes it is? What else would you call it?

The idea of abstraction is a sound principle, not lazy.

Well that's the disadvantage of programming against a dead project, I suppose.

Let's assume the only change was that the colour character was changed from § to ¬. The only change you'd have to do to update Bukkit would be to change the character here. I can assure you that it's not faster to change every single plugin using the raw symbol than to change that one line there.

 

I used that as a contrasting scenario. A few of us did see it coming. We knew that Notch had made several hints at name changing, but we didn't know what would have to happen. There is absolutely no reason why the § should ever need to change. UUIDs made sense, albeit a "username displayname" rather than a "UUID displayname" system is what we'd all have preferred. § is the original Minecraft character. If Mojang decided to change the § character, they'd be screwing over a lot of people, not just coders.

The raw method of using colors. ChatColor is basically just §, except it takes a precaution for a situation that will most likely never occur. It could, but it won't.

Quite right. How is it a sound principle if in our far fetched hypothetical scenario, there is no update to fix the issue to speak of? We're at the point where we need to take these problems in our own hands.

Except for the fact that:

a) Bukkit and craftbukkit are likely never going to update
b) They'd likely use a system to replace the old char with the new char
c) You could update your plugin to support hacked protocols (which many people use) before Bukkit updated, if it ever DID update.

Again, we're looking at a scenario where Bukkit is making actual progress. A sounder argument could be made for Spigot development, but this isn't Spigot development.

 

ColonelHedgehog Or you could avoid all that trouble and just use the given ChatColors, I mean they wouldn't have been implemented if it wasn't for more ease?

 

It's good that I use the ChatColor enums. To be honest though, I use it because I'm too lazy to remember the unicode to type the color char. But apart from that, I do support using the API.

 

To be fair, that wouldn't be Mojang screwing people over, that would be people screwing themselves over failing to follow proper standards ;3

ChatColor is much more than just a character. It stands for an actual colour, no matter how it's implemented in Minecraft. Also, that last part is equal to saying that we shouldn't mind thread safety. After all, it's likely to work out most of the time. Why should we care about the chance that it doesn't work out... right?

 

ColonelHedgehog I think my point, and probably AdamQpzm 's point as well, is to just follow the principle as good practice, even when you probably won't need it. Because of the mere fact that you can never really know. Plus it makes the code a lot clearer in intent as one wouldn't have to look up a list of formatting codes and what they mean (if you don't bother learning them, that is). Using the enums lets the reader immediately know exactly what colour is intended.

 

World folders don't use ChatColor enums...

I'm quite OCD about my practices. Like I said, I try to look at every possible scenario. A lot of the stuff I do will probably be a waste of time (i.e. Mojang may never remove item datas, just keep it there in the background for convenience). But I do it anyway because it could happen.

I kind of want to email Mojang about this. It's a very interesting subject.

The ChatColor enum is exceedingly easy for people who can't easily use the §. I know a few people who don't have keyboards that can type the § character so the ChatColor enum is the best fit.

I am not one of those people. And since we're using a (next to) dead project, I think it's best to use something that you can fix yourself in the (very) off chance that the CC char is ever changed.

It really sounds like the only advantage to the CC enum is readability. However, I can't think of any circumstance where you'd need to be able to read it other than if you're showing someone your code or you're trying to be nice to the dev.bukkit.org staff when they're scanning your plugin for threats.

It just seems to me like in the circumstance that Minecraft's CC char is ever changed, that would also mean the ChatColor enum would need to be updated. Because Bukkit has been dead for months, that's probably not going to happen. So you'd have to go through your code and replace the CC enum with the new char, which would be a major pain, since each enum title is (obviously) different and you'd have to match them to the corresponding number.

To me it seems like there are pros and cons on both sides, so it seems much more of a personal preference thing. My personal opinion is that because the ChatColor enum (ease of use when § is not accessible aside)'s purpose is to make it so all that would need to update is Bukkit (which won't at this stage), it is effectively just as good as §.

 

ColonelHedgehog Well, it seems like we'll never really come to an agreement about this, but you've shared some interesting and valuable points and it has sure been an interesting debate. Let's just call it preference thing, like you said.

 

Agreed to disagree.