Thread: [Discussion] Interest in a Java Pokemon API?
View Single Post
  #29    
Old March 2nd, 2013 (12:07 PM). Edited March 2nd, 2013 by iTeruri.
iTeruri's Avatar
iTeruri
iAm
 
Join Date: May 2006
Location: The Nederlands
Nature: Relaxed
Quote originally posted by audinowho:
@iTeruri Would you be fine with just extending the Ability class with a function working the same way that your proposed Effect class would do? The meaning of "effect" in your example would be to serve some active purpose "in engine" rather than just containing data to be read. It seems to me that having it as part of the library would go against modularity it's aiming for. From what I gather the OP wants to do is create something that leaves both the ends (what it's used for) and the means (how it's used for that) up to the dev.
I'm not sure I understand you, sorry.

My proposal is to have a Effect class that the developer can use in any way (s)he wishes to use it. It's just a reference to an object of the Effect type, that doesn't do anything. It's just a generic type to hold a reference. It doesn't serve an active purpose.

Note: I haven't programmed in Java for quite some time, so the specific may be off. I'm sorry.

Effect could just be something like this:
Code:
interface Effect {
}
Two examples of Effect classes, both would work with the project.
Code:
class FirstExampleEffect implements Effect {
    int EffectNo; //Some other part of the code knows what to do with this (example: heal). This is the FunctionCode as it's used in Essentials.
    //other fields that serve as optional parameters
}
Code:
class secondExampleEffect impelents Effect {
    public void doEffect()
    {
         //Code to make the item that uses this effect work.
     }
}
An Item could look like this:
Code:
class Item {
     //fields
     Effect effect;
}
Note that ability, attack, item, etc. could all use this generic Effect type.

The classes themself (the Item class that has the effect field and the Effect Interface) do not care what the developer does with them. Basicly it's like having a field to contain objects of the Object type, but slightly more specific (in naming, at least).

// Edit:

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.
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.
Reply With Quote