Thread: [Discussion] Interest in a Java Pokemon API?
View Single Post
  #30    
Old March 2nd, 2013 (02:02 PM).
Maruno's Avatar
Maruno Maruno is offline
Lead Dev of Pokémon Essentials
Moderator
 
Join Date: Jan 2008
Location: England
Posts: 4,146
Quote originally posted by iTeruri:
Maruno, I do not know much of how Essentials works, but you don't seem to know much about how Java works, either. Because this project is made in Java, it is much more important to know how Java works, isn't it. My examples are just examples, ignore the part where I mention how it works like Essentials if it isn't the case.

Basicly Java works by having Object and Classes. Classes are like blueprints for Objects. They define what properties Objects have (fields; variables that are defined outside methods) and what they can do (methods, other languages call them functions. Same thing). Because some Objects are similar to it's other, you can extend one object to another, which we call inheritance. Example: the Cat class extends the Animal class. The Cat class now has all the fields and method as the Animal class, and more importantly when the program expects an Animal object (an object is just a reference to a class, basicly), you can pass a Cat object.
An interface is the same, only an interface can never be an object. If Animal is an interface, you can't make an Animal object.
Ruby works the same way. I know all this.


Quote originally posted by iTeruri:
My proposal uses this, but instead of animals and cats, is uses a generic Effect placeholder and whatever implementation the developer wants for effects. That's much less limiting than using, say, an integer variable for function code, because an integer can only ever be a whole number.

// Edit 2: (Still for Maruno)
Basicly the thing is: Effect is anything you want it to be. If you need it to be a FunctionCode then it can be a FunctionCode. If it needs to be something entirely else, it's something entirly else. You don't want people to force using it in one way or another, because as you mentioned, how the effects are programmed is up to the developer. Using FunctionCodes only forces you to use FunctionCodes, and that leaves out a lot of ways to program the effects.
You are also wrong about the last part of your last post. With the reference to the Effect object, we aren't forcing anything. To the contrary. If you want to hardcode everything, that's still a posibility, but instead of getting the FunctionCode, you get an Effect object. If you want to solve it using my original idea, you can do too. But my original idea can't be done using a FunctionCode.
I fail to see the point of interface Effect, since you could just make all the classes that would implement it stand-alone classes instead. That's just me not knowing whether interfaces do anything useful.

I do get what you're saying now. I still say it's beyond the scope of this project, though. Anything involving the implementation or use of effects is beyond the scope. We don't need to say what effects do; we just need to say that one effect is different to another one (which, incidentally, can be done by designating each effect with an integer, or by implicitly assuming that every thing has a different effect in the case of items/abilities, which isn't unreasonable).

You do what you like, though. I've become bored of telling you that you're overthinking things.
__________________
Reply With Quote