Clean up javadoc about developercapes HOT 57 CLOSED

https://github.com/jadar/DeveloperCapes/blob/master/src/main/java/com/jadarstudios/developercapes/DevCapes.java#L92 .... uhm so what method is it supposed to use?

from developercapes.

Uhh.. Remove that deprecated comment on anything that doesn't have "String identifier" in the arguments. DevCapes manages IDs on its own now..

from developercapes.

why does this exist?

from developercapes.

also someone forgot to import ByteStreams.... in CapeConfManager.......... I wonder who...

from developercapes.

Heh. Probaby intended to put parsing in there and then changed my mind. And I KNOW CAUSE I DIDN'T WRITE IT THEN ACCEPTED A PR.

from developercapes.

^ not yelling ^_^

from developercapes.

I was blaming plank not you just fyi

from developercapes.

I was too ;)

from developercapes.

here the continue, continues the for loop ... so ... what exectly are you skipping with it? Since there is nothing below the if

from developercapes.

It's redundant. Remove it. ;)

On Oct 17, 2014, at 5:37 PM, Captain Shadows [email protected] wrote:

here the continue restarts continues the for loop ... so ... what exectly are you skipping with it?

—
Reply to this email directly or view it on GitHub.

from developercapes.

this is the last part of the sanity check, you are not using realId at all...

from developercapes.

I think this.configs.put(claim(id), config); works just fine but if you want readable then this.configs.put(realId, config);

from developercapes.

Oops! Use it instead of id in the next line.

On Oct 17, 2014, at 5:42 PM, Captain Shadows [email protected] wrote:

this is the last part of the sanity check, you are not using realId at all...

—
Reply to this email directly or view it on GitHub.

from developercapes.

heh ok

from developercapes.

"Readable and understandable code is good code" - my boss

On Oct 17, 2014, at 5:43 PM, Captain Shadows [email protected] wrote:

I think this.configs.put(claim(id), config); works just fine but if you want readable then this.configs.put(realId, config);

—
Reply to this email directly or view it on GitHub.

from developercapes.

ok this is the beginning #34

from developercapes.

Ok what do you think of changing this to userFromName?

from developercapes.

Also what do you think of this javadocs?

from developercapes.

do newUser()

looks good

from developercapes.

sorry xD

from developercapes.

ok... why is this ......... I'll take it as only a string can be passed

from developercapes.

we we can keep track of all the cape instances?

from developercapes.

Sorry that is the fixed one ... should of linked the original :P
This is what I was referring to.

from developercapes.

I already told you. It's for subclasses so they can parse using a different type of object.

On Oct 19, 2014, at 6:46 PM, Captain Shadows [email protected] wrote:

Sorry that is the fixed one ... should of linked the original :P
This is what I was referring to.

—
Reply to this email directly or view it on GitHub.

from developercapes.

ah.... ok

from developercapes.

but.. as I thought ... that is simply ... well .... http://stackoverflow.com/questions/4604978/subclassing-an-enum

from developercapes.

did you perhaps try to make it a singleton by making it an enum but forgot about that?

from developercapes.

Yes I did. xD Oops. Can we switch it? ..again..

from developercapes.

..... so.......... singleton?

from developercapes.

how would the subclass handle the instance change though?

from developercapes.

should we have an instance of each in DevCapes and reference that?

from developercapes.

Know what? Just leave it for now.

from developercapes.

too complex for this hour? :P

from developercapes.

Unfortunately

from developercapes.

that is ok

from developercapes.

oh btw I added the license to the files that were missing it (that was a thing that was needed right?)

from developercapes.

ok thanks

from developercapes.

so, have you thought about how you want it to work?

from developercapes.

No. I will when I have time. Can you just move one without addressing it?

from developercapes.

ok, should I leave the current methods as is or optimize for enums?

from developercapes.

Just leave it please. I don’t want to have to change the API twice.

On Oct 20, 2014, at 3:01 PM, Captain Shadows [email protected] wrote:

ok, should I leave the current methods as is or optimize for enums?

—
Reply to this email directly or view it on GitHub.

from developercapes.

heh... sorry for pointing that out...

from developercapes.

No it’s ok. That’s good. I just don’t have time to deal with it now. I’m very grateful you’re doing what you’re doing now.

On Oct 20, 2014, at 3:03 PM, Captain Shadows [email protected] wrote:

heh... sorry for pointing that out...

—
Reply to this email directly or view it on GitHub.

from developercapes.

Talking about reasons for you to hate me(for adding more work), what is this for?

from developercapes.

As if. :)

That’s so we don’t have a negative number.. I think.. Read the JavaDoc!! :D

On Oct 20, 2014, at 3:14 PM, Captain Shadows [email protected] wrote:

Talking about reasons for you to hate me(for adding more work), what is this for?

—
Reply to this email directly or view it on GitHub.

from developercapes.

"Returns the byte value that, when treated as unsigned, is equal to value, if possible." uhm ... we are not using the return AT ALL so.... I will ask again, Why?

from developercapes.

I don’t remember. I didn’t want someone registering a cape with a negative number as the ID.

On Oct 20, 2014, at 3:25 PM, Captain Shadows <[email protected] mailto:[email protected]> wrote:

"Returns the byte value that, when treated as unsigned, is equal to value, if possible." uhm ... we are not using the return AT ALL so.... I will ask again, Why?

—
Reply to this email directly or view it on GitHub #33 (comment).

from developercapes.

so it is a bug? since that call won't change its input I should set ID to the return val?

from developercapes.

I thought it threw an exception if a number wasn’t unsigned.

On Oct 20, 2014, at 3:30 PM, Captain Shadows [email protected] wrote:

so it is a bug? since that call won't change it's input I should set ID to the return val?

—
Reply to this email directly or view it on GitHub #33 (comment).

from developercapes.

it returns a byte that when treated as unsigned is equal to the input, the error only happens if the input is negative or greater than 255

from developercapes.

at least that is what the doc says the code shifts the input to the right with Byte.SIZE, and if that isn't 0 it errors (I don't know much about byte shifts so I don't really get it...)

from developercapes.

Right… Just make it print an error to the screen and return if it’s <= 0.

On Oct 20, 2014, at 3:41 PM, Captain Shadows [email protected] wrote:

at least that is what the doc says the code shifts the input to the right with Byte.SIZE, and if that isn't 0 it errors (I don't know much about byte shifts so I don't really get it...)

—
Reply to this email directly or view it on GitHub #33 (comment).

from developercapes.

is this it? I'm sorry I just really don't get byte stuff.... sorry

from developercapes.

Uh, yah I think so.. Donno why I wanted it capped at 256.

from developercapes.

because you are putting it in a "new BitSet(256)"?

from developercapes.

I just copied EntityRegistry

On Oct 21, 2014, at 1:52 PM, Captain Shadows [email protected] wrote:

because you are putting it in a "new BitSet(256)"

—
Reply to this email directly or view it on GitHub.

from developercapes.

..... lol k

from developercapes.