Yay new update, deprecated stuff :(

Discussion in 'Plugin Development' started by mollekake, Sep 11, 2013.

Thread Status:
Not open for further replies.
  1. Offline


    Magic Number, Magic Name. In the end you still have a hard coded value to represent something. The advantage of Magic Names is they are more meaningful. After all, "iron ore" makes more sense than "15".

    The big disadvantage of doing this is, do I want to use "iron ore" or "iron_ore" or "IronOre" or "Iron Ore" or ....? At least with numbers there is no ambiguity, we know that 15 is iron ore, regardless of how we choose to spell iron ore. How much time are we going to spend cursing this because our code won't compile we can't remember or find how iron ore is supposed to be spelled?

    Changing it to get rid of "magic numbers" is futile, you are still using magic values. In the database world, we have a table of meaningful names, but behind the scenes each name is represented by a unique identifier, usually an integer (sometimes a guid). Assuming you know how to design your database.

    <shrug> I was fine with magic numbers. Changing something to be politically correct is not always a good change....
    Blah1 likes this.
  2. Offline


    Out of curiosity - does anyone actually have any record of someone from Mojang actually saying they are phasing out "magic numbers"? Or is this something that is only discussed in top-secret Mojang/Bukkit meetings? :D

    Because... well if I'm going to be perfectly honest, that sounds *way* more like the kind of thing Bukkit would do in an attempt to abstract us further away from the underlying NMS code, than something Mojang would do internally. (Unless this is maybe paving the way for their own mod api... ?)

    I haven't looked at all the new packets, maybe they use string ids in those- but I really don't see them changing the internal data structure so that every single block or item in the world stores a string id. There's no way, it'd be crazy inefficient. The underlying data is always going to be integer ids- whether you have to pass through some kind of enum or string map to get the actual id# you want, that's just an abstraction layer... (and some of us would prefer to be able to bypass as many abstraction layers as we can, let us take off the training wheels)

    Anyway, I don't want to rant about this too much.. but the entire MaterialData things feels like a typical Bukkit thing to do- give us a nice friendly interface for something, but take away any ability we have to do anything custom with it. Want to get/set data for a material bukkit doesn't think has data? Too bad! Meh...

    Ok, well that was ranty anyway. Sorry if I've offended anyone!
  3. Offline


    I dont have a problem with using (Material.IRON_ORE)...it's the server owners that are gonna have to do a lot of work because most of them know/have memorized all the IDs they need.

    Just keep it, mojang/bukkit...it's not causing any harm.
  4. Offline


    Well Material.OBSIDIAN is easier to remember than #49, because you already know it's obsidian.
  5. Offline


    Not to mention that all shovels are spades, and all the horse armor are bardings.

    Not saying I don't support removing item ids, but not all the materials make immediate sense.
    jorisk322 likes this.
  6. Offline


    Not for server-owners. It's easy to look up the id's, but harder to look up the Material enum.
  7. Offline


    When coding in eclipse, you can do Material. and it will bring up a menu of all the materials, this is easier to find that having to go to the internet and get the ID's

    BTW, I found a nice ID site:
  8. Offline


    I am aware of this (though I use IntelliJ so it's actually even easier to type :p). I actually just have a command in my custom global plugin to easily look up ids though.
Thread Status:
Not open for further replies.

Share This Page