Java questions which don't deserve their own thread, yet.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

«‹›303 »

Sistergodiva: Jan 3, 2006; I'm like you,
I have no shame.

What is a good way to time stuff in Java? Using a Slick2d gameloop.

I want to display a string on the screen for a while after I rightclick something.

code:

        counter += delta;
        if (counter >= 10 * Map.modifier) {
            counter = 0;
            currentPlayer.aStarMove();

        }

This is what I use for my movement, but this won't really work for my string, since this one does a thing every so often. While for my new thing I would like to do something like.

code:

    private void doExamineText(String description) {
        examineText = description;
	startTimer
if (timer > displaytime) {
	examineText = "";
}
    }

Not sure what if this is the smartest way to do it.

Maybe there is a good way to make something to futureproof me when I want timed events and stuff for "cutscenes" later?

# ? Oct 27, 2015 23:49

Adbot: ADBOT LOVES YOU

# ? Jun 13, 2024 02:34

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

Jo posted:

I have a random generator from which I'm extracting random numbers in an anonymous function. It seems like doing this is producing strange results and more duplicates than I'd expect. Is it okay to use random in async operations and lambdas?

What's 'more duplicates than I'd expect' though? You're picking rows at random right - how many are there, and how many are you collecting? Like with 1000 possibilities, drawing 25 at random has a 25% chance of at least one duplicate (I think)

Just making sure your expectations are realistic!

# ? Oct 27, 2015 23:58

Jo: Jan 24, 2005; Soiled Meat

baka kaba posted:

What's 'more duplicates than I'd expect' though? You're picking rows at random right - how many are there, and how many are you collecting? Like with 1000 possibilities, drawing 25 at random has a 25% chance of at least one duplicate (I think)

Just making sure your expectations are realistic!

I had 400 samples from 60000 items and saw around 50% as duplicates.

# ? Oct 28, 2015 00:40

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Sistergodiva posted:

What is a good way to time stuff in Java? Using a Slick2d gameloop.

I want to display a string on the screen for a while after I rightclick something.
code:
        counter += delta;
        if (counter >= 10 * Map.modifier) {
            counter = 0;
            currentPlayer.aStarMove();

        }
This is what I use for my movement, but this won't really work for my string, since this one does a thing every so often. While for my new thing I would like to do something like.
code:
    private void doExamineText(String description) {
        examineText = description;
	startTimer
if (timer > displaytime) {
	examineText = "";
}
    }
Not sure what if this is the smartest way to do it.

Maybe there is a good way to make something to futureproof me when I want timed events and stuff for "cutscenes" later?

I dunno, that's pretty much what I do. I have timers and I add delta times to them and then check if its greater than some value.

Why won't that work for your string exactly?

It sounds like the problem is how you're checking and updating the timers, not how to do the timers themselves. Your main game loop needs to be able to hit updates on all the timers you have, they shouldn't be buried in individual classes and stuff.

If you want to come up with something robust and future proof, what you're looking for is like a messaging system that can handle delayed messages. So you build some class that you can fire off events on and give them delays, and then every time your main game loop updates it just calls on the messaging system and passes it the delta time to check for which timers have gone off and keep track of how much the rest have left.

Cutscenes could be done that way or could just be blocks of "do this - wait for this long - do this", either way its just a bunch of scripting.

# ? Oct 28, 2015 15:22

Sistergodiva: Jan 3, 2006; I'm like you,
I have no shame.

Zaphod42 posted:

I dunno, that's pretty much what I do. I have timers and I add delta times to them and then check if its greater than some value.

Why won't that work for your string exactly?

It sounds like the problem is how you're checking and updating the timers, not how to do the timers themselves. Your main game loop needs to be able to hit updates on all the timers you have, they shouldn't be buried in individual classes and stuff.

If you want to come up with something robust and future proof, what you're looking for is like a messaging system that can handle delayed messages. So you build some class that you can fire off events on and give them delays, and then every time your main game loop updates it just calls on the messaging system and passes it the delta time to check for which timers have gone off and keep track of how much the rest have left.

Cutscenes could be done that way or could just be blocks of "do this - wait for this long - do this", either way its just a bunch of scripting.

Ah thanks. Do I have to make a new timer for each thing I want timed? That just felt a bit hacky and I though there would be a smarter way.

# ? Oct 28, 2015 16:50

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Sistergodiva posted:

Ah thanks. Do I have to make a new timer for each thing I want timed? That just felt a bit hacky and I though there would be a smarter way.

Sure. Why not? The way I'd see it, you'd have a Messenger class which handles the calls, it would have addEvent(event e) and updateEvents(float deltaTime) or something like that.

When you call addEvent, it adds the reference to the list of things to check. When you call updateEvents, it goes through the list, adds the deltaTime to each, and then checks to see if they should fire. Heck you could just combine those into a single method, event can have like handleUpdate(float deltaTime) which either increments its time and does its junk or does't. You could make it a boolean too, and then if it returns true that means the event fired and can be deleted from the loop, so you can clean up the references when you don't need them any more.

Then you just need a basic event class which has its own timer and has an implementation of handleUpdate that checks the timer, and then you can write specific implementations of events which derive from the base event class and override its implementation with something specific.

Then each time you need a timer, you have your game logic create the appropriate type of timer (like when a bomb gets set off you create a bombEvent or whatever) and then call addEvent(...) on it, and you don't have to worry about the rest.

Or you can just have like an array of timers in your base class or each object can have its own timers based on what it needs, its all just a matter of how you want to organize it. I like having a central processor but it might be overkill depending upon how many events you're firing off or not.

Like for a simple mega man game, I'd just have a shootTimer variable on my MegaManDude class, which when the MegaManDude was updating its logic each tick, it would check to see if it could shoot or not. But if you're making a game with all kinds of timers like that, then having a central messaging system makes a lot of sense.

# ? Oct 28, 2015 17:20

Squashy Nipples: Aug 18, 2007

Here is my "Deck" Class so far.
It uses my Card Class, which relies on my Rank and Suit Enums.

code:

import java.util.Arrays;
import java.util.Collections;

public class Deck {
   
    private static final int deckCount = Rank.values().length * Suit.values().length;
    private final Card[] deck = new Card[deckCount];
    
    private int nextCard;
   
    public Deck() {
            
        int i = 0;

        for (Suit suit : Suit.values()) {
            for (Rank rank : Rank.values()) {
                deck[i] = new Card(rank, suit);
                i++;
            }       
        }
        nextCard = 0;
    }

    public Card getCard(int cardIndex) {
        return deck[cardIndex];
    }
    
    public void shuffleDeck() {
        Collections.shuffle(Arrays.asList(deck));
        nextCard = 0;
    }
    
    public Card dealCard() {
    //Return NULL value if not enough cards remain
        if (nextCard + 1 >= deckCount){
            return null;
        } else {
            Card deal = deck[nextCard];
            nextCard++;
            return deal;
        }
    }
    
    public Card[] dealCards(int numCards) {
    //Return NULL value if not enough cards remain
        if (nextCard + numCards >= deckCount){
            return null;
        } else {
            Card[] deal = new Card[numCards];
            for (int i = 0 ; i < numCards ; i++) {
                deal[i] = deck[nextCard];
                nextCard++;
            }
            return deal;
        }
    }
}

Question 1:
Is returning NULL when there aren't enough cards in the Deck a good idea?
Or should I pass the Hand in By Reference, and return a Boolean from the Method to tell the calling code whether the deal was successful or not?

I suppose I could have the Deck Object Shuffle itself if it runs out of cards, but I'd rather have that handled by the calling logic, since it's going to vary game by game.

Question 2:
I want to use this Class as an example to my students of SubClasses and Inheritance. To improve the Black Jack game, we need a Class called "Shoe": it will consist of 4-8 Decks (based on input to the Constructor), and will have a variable to represent the "Card Cut", where once you reach that Card, you have to reshuffle the Shoe before the next hand.

Is this a good idea? Maybe it's a totally separate object?
I made the deckCount FINAL at 52, so I'm not sure how to build the Shoe so that it properly inherits everything from Deck.

# ? Oct 29, 2015 17:03

Kuule hain nussivan: Nov 27, 2008

Squashy Nipples posted:

Question 1:
Is returning NULL when there aren't enough cards in the Deck a good idea?
Or should I pass the Hand in By Reference, and return a Boolean from the Method to tell the calling code whether the deal was successful or not?

I suppose I could have the Deck Object Shuffle itself if it runs out of cards, but I'd rather have that handled by the calling logic, since it's going to vary game by game.

Still a beginner, but I think returning Null might be a bit problematic (or at least cause problems later on where you constantly have to check if stuff is Null). Instead, I'd do a hasCardsLeft method which returns true or false, which can be called before the dealCards method.

# ? Oct 29, 2015 17:14

carry on then: Jul 10, 2010; by VideoGames
(and can't post for 10 years!)

I guess the behavior depends on the game. What if the rules are to just deal as many cards as are left if you don't have enough to deal a full hand?

# ? Oct 29, 2015 17:17

baquerd: Jul 2, 2007; by FactsAreUseless

Kuule hain nussivan posted:

Still a beginner, but I think returning Null might be a bit problematic (or at least cause problems later on where you constantly have to check if stuff is Null). Instead, I'd do a hasCardsLeft method which returns true or false, which can be called before the dealCards method.

Yes, and then throw an Exception if dealCard() is called when there are no cards left (create a NoCardsLeftException for this).

Squashy Nipples posted:

Question 2:
I want to use this Class as an example to my students of SubClasses and Inheritance. To improve the Black Jack game, we need a Class called "Shoe": it will consist of 4-8 Decks (based on input to the Constructor), and will have a variable to represent the "Card Cut", where once you reach that Card, you have to reshuffle the Shoe before the next hand.

Is this a good idea? Maybe it's a totally separate object?
I made the deckCount FINAL at 52, so I'm not sure how to build the Shoe so that it properly inherits everything from Deck.

Shoe shouldn't inherit from deck, a Shoe HAS A Deck (or rather a List of Decks most likely).

# ? Oct 29, 2015 17:19

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Squashy Nipples posted:

Here is my "Deck" Class so far.

Question 1:
Is returning NULL when there aren't enough cards in the Deck a good idea?
Or should I pass the Hand in By Reference, and return a Boolean from the Method to tell the calling code whether the deal was successful or not?

I suppose I could have the Deck Object Shuffle itself if it runs out of cards, but I'd rather have that handled by the calling logic, since it's going to vary game by game.

Question 2:
I want to use this Class as an example to my students of SubClasses and Inheritance. To improve the Black Jack game, we need a Class called "Shoe": it will consist of 4-8 Decks (based on input to the Constructor), and will have a variable to represent the "Card Cut", where once you reach that Card, you have to reshuffle the Shoe before the next hand.

Is this a good idea? Maybe it's a totally separate object?
I made the deckCount FINAL at 52, so I'm not sure how to build the Shoe so that it properly inherits everything from Deck.

1 : Nothing wrong with returning null, so long as you are aware of it and do null testing when necessary when calling the method. Ideally you would add a comment or a javadoc description to the method which details that it returns null in some cases and when null is returned and what that means. But its not necessary.

You could also have the deck shuffle itself when empty and return the first new card. There's nothing inherently wrong with either approach, so that's more of a design choice.

You can also pass in a hand object and have it modify the hand object and return a boolean, that's fine too. Again I would say its more of a design choice, returning a boolean is "safer" I guess but returning nulls is very very common and not considered "wrong".

2 : Having a shoe class which holds decks and returns cards and keeps track of shuffling makes sense. What else is the question related to inheritance though? Having shoe derive from Deck? Having Shoe derive from the game class? Probably not. I would have it be a seperate class with deck variables, yeah.

The only reason to have shoe inherit from Deck would be to use the Deck as an interface on both so that code could be ignorant of if it was using a deck or shoe of decks, but I'm not sure that's really worth doing. But you could, yeah, just have the same methods for both and have them all overloaded with Shoe. But when you're literally overloading every method, it'd probably be better to have a 3rd interface class and have both Deck and Shoe implement that interface. (CardStack or something?)

Kuule hain nussivan posted:

Still a beginner, but I think returning Null might be a bit problematic (or at least cause problems later on where you constantly have to check if stuff is Null). Instead, I'd do a hasCardsLeft method which returns true or false, which can be called before the dealCards method.

Nah returning null is pretty common and checking for nulls is pretty cheap.

baquerd posted:

Yes, and then throw an Exception if dealCard() is called when there are no cards left (create a NoCardsLeftException for this).

Shoe shouldn't inherit from deck, a Shoe HAS A Deck (or rather a List of Decks most likely).

I dunno, the exception may not be needed depending upon the logic. The game could just catch the null and handle it right there gracefully with no need for a NoCardsLeftException. Depends upon the organization of the code and what exactly is calling the deck for cards and if that needs to be passed up the stack or not.

I agree Shoe shouldn't inherit from Deck but rather just have deck variables.

Zaphod42 fucked around with this message at 17:23 on Oct 29, 2015

# ? Oct 29, 2015 17:21

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

Is there any problem with checking for null here, since you're going to be doing something with the result anyway? It's not a side effect of some internal behaviour, it's specifically what the method is providing - a card, or a non-card when there's none left. Especially if you're going to do a boolean check anyway - why not just directly look at whether you got a card or not?

# ? Oct 29, 2015 17:25

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

baka kaba posted:

Is there any problem with checking for null here, since you're going to be doing something with the result anyway? It's not a side effect of some internal behaviour, it's specifically what the method is providing - a card, or a non-card when there's none left. Especially if you're going to do a boolean check anyway - why not just directly look at whether you got a card or not?

Yeah exactly, its the same thing in the end. Checking a pointer value or checking a boolean are both pretty drat cheap. Ultimately the difference is the definition of "premature optimization", its not significant enough to make a difference so just go with what makes sense to you. In some situations the null could be a problem but in this situation there's no reason not to do that if that's what makes sense to you.

# ? Oct 29, 2015 17:30

baquerd: Jul 2, 2007; by FactsAreUseless

It's mostly stylistic, but it's generally helpful to users of an API to get proper Exceptions. If the user is not expecting a null, they will most likely get an NPE. However, if they instead get an OutOfCardsException, this can be much more helpful, particularly in the context of a larger system.

# ? Oct 29, 2015 17:38

Squashy Nipples: Aug 18, 2007

As always, great stuff guys, thanks!

Zaphod42 posted:

Yeah exactly, its the same thing in the end. Checking a pointer value or checking a boolean are both pretty drat cheap. Ultimately the difference is the definition of "premature optimization", its not significant enough to make a difference so just go with what makes sense to you. In some situations the null could be a problem but in this situation there's no reason not to do that if that's what makes sense to you.

Awesome, that was pretty much what I was thinking. That said, I CAN pass a Hand in By Reference and add Cards to it if I want, right?

carry on then posted:

I guess the behavior depends on the game. What if the rules are to just deal as many cards as are left if you don't have enough to deal a full hand?

Yes, the logic of the specific game matters... and to your point, for some games (not Black Jack), you might want to deal all the remaining cards, and then reshuffle. So, I think what I'll do is make the deal methods just deal to the last Card in the Deck, and add a Method to check the number of cards remaining (getCardsLeft). This means that the game code has to check first, but then it can do whatever it needs to based on the rules of the game.

Zaphod42 posted:

2 : Having a shoe class which holds decks and returns cards and keeps track of shuffling makes sense. What else is the question related to inheritance though? Having shoe derive from Deck? Having Shoe derive from the game class? Probably not. I would have it be a seperate class with deck variables, yeah.

The only reason to have shoe inherit from Deck would be to use the Deck as an interface on both so that code could be ignorant of if it was using a deck or shoe of decks, but I'm not sure that's really worth doing. But you could, yeah, just have the same methods for both and have them all overloaded with Shoe. But when you're literally overloading every method, it'd probably be better to have a 3rd interface class and have both Deck and Shoe implement that interface. (CardStack or something?)

Yeah, the more I think about it, the more I realized I picked a lovely example for a lesson on Inheritance.

Shoe is similar to Deck, with similar Methods (plus methods to deal with the (optional) cut card), but it has a variable-sized Array, based on the number of Decks. You don't want to build Shoe out of Decks, because you need to shuffle the whole Shoe at once, instead of shuffling the Decks individually, and then together. There is no value in having individual Decks in the Shoe, I just need to reuse the Deck Constructor logic, and add a third loop to it.

# ? Oct 29, 2015 17:46

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

I would expect that the return value would be an array of cards up to size N, where size is less than N if there aren't enough cards. Return an empty array if there are no cards left. Throwing an exception seems like a poor idea, since running out of cards if you don't know the count ahead of time seems like an unexceptional thing to happen.

You DEFINITELY need methods to know ahead of time if the call will return N cards, just because you don't want exception based flow control. A int hasEnoughCards(int numCards) method in particular, with a bool hasCardsRemaining method if you need to hide the deck size, or an int getCardsRemaining method if not.

If you're showing this as an example to students, don't forget your javadoc comments.

# ? Oct 29, 2015 17:48

Jerry Bindle: May 16, 2003

baquerd posted:

It's mostly stylistic, but it's generally helpful to users of an API to get proper Exceptions. If the user is not expecting a null, they will most likely get an NPE. However, if they instead get an OutOfCardsException, this can be much more helpful, particularly in the context of a larger system.

Is an empty deck an exceptional condition? Maybe it is, but in the card games I know of there is a rule for what happens when you run out of cards in the deck. You wouldn't detect being at the end of an array by catching an ArrayIndexOutOfBoundsException.

# ? Oct 29, 2015 17:49

Squashy Nipples: Aug 18, 2007

baquerd posted:

It's mostly stylistic, but it's generally helpful to users of an API to get proper Exceptions. If the user is not expecting a null, they will most likely get an NPE. However, if they instead get an OutOfCardsException, this can be much more helpful, particularly in the context of a larger system.

Ok, I like this explanation, too. I haven't gotten as far in the stream to get to handling Exceptions, yet. In fact, I don't really know any of the debugging features yet; when something doesn't work I stick in extra println() statements so I can watch variables and track down exactly where things are going wrong.

# ? Oct 29, 2015 17:50

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Squashy Nipples posted:

Awesome, that was pretty much what I was thinking. That said, I CAN pass a Hand in By Reference and add Cards to it if I want, right?

Yep. If you pass in an object by reference then you can't replace the object reference and have it update elsewhere, but if you pass in a container object by reference then you can modify the references of that container object and anywhere else that has a reference to that container will see the updates since its the same object.

Squashy Nipples posted:

Shoe is similar to Deck, with similar Methods (plus methods to deal with the (optional) cut card), but it has a variable-sized Array, based on the number of Decks. You don't want to build Shoe out of Decks, because you need to shuffle the whole Shoe at once, instead of shuffling the Decks individually, and then together. There is no value in having individual Decks in the Shoe, I just need to reuse the Deck Constructor logic, and add a third loop to it.

Yeah sounds right to me.

# ? Oct 29, 2015 17:51

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Squashy Nipples posted:

Ok, I like this explanation, too. I haven't gotten as far in the stream to get to handling Exceptions, yet. In fact, I don't really know any of the debugging features yet; when something doesn't work I stick in extra println() statements so I can watch variables and track down exactly where things are going wrong.

Learn to use the debugger in the IDE of your choice, it will pay dividends in spades.

# ? Oct 29, 2015 17:52

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Squashy Nipples posted:

Ok, I like this explanation, too. I haven't gotten as far in the stream to get to handling Exceptions, yet. In fact, I don't really know any of the debugging features yet; when something doesn't work I stick in extra println() statements so I can watch variables and track down exactly where things are going wrong.

You should def take the time to learn proper debugging. Its really very intuitive with modern IDEs, you just push buttons and then watch the debug display track what the computer is doing. You can do fancy stuff like set watch variables but that's not even necessary.

There's nothing inherently wrong with dumping println() statements into your code and everybody does that at times, but proper debugging lets you do the exact same thing without having to bother adding and removing println() statements, and it lets you do far far more.

Volmarias posted:

Learn to use the debugger in the IDE of your choice, it will pay dividends in spades.

EFB

# ? Oct 29, 2015 17:53

Squashy Nipples: Aug 18, 2007

Volmarias posted:

Learn to use the debugger in the IDE of your choice, it will pay dividends in spades.

No argument here, but I'm really just bootstrapping my way into this language, piece by piece.

The official Java tutorial covers stuff in a very academic manner, so I've been moving through it pretty slowly. I don't have the luxury of learning it all before I start teaching the kids, so piece by piece is good enough for now.

# ? Oct 29, 2015 17:57

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Squashy Nipples posted:

No argument here, but I'm really just bootstrapping my way into this language, piece by piece.

The official Java tutorial covers stuff in a very academic manner, so I've been moving through it pretty slowly. I don't have the luxury of learning it all before I start teaching the kids, so piece by piece is good enough for now.

Are you new to OO in general?

# ? Oct 29, 2015 18:01

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Squashy Nipples posted:

No argument here, but I'm really just bootstrapping my way into this language, piece by piece.

The official Java tutorial covers stuff in a very academic manner, so I've been moving through it pretty slowly. I don't have the luxury of learning it all before I start teaching the kids, so piece by piece is good enough for now.

Yeah seriously though its worth skipping ahead to debugging and coming back. It will take you literally 5 minutes to learn and it will save you SO much time on everything else you try to learn.

# ? Oct 29, 2015 18:01

Squashy Nipples: Aug 18, 2007

^^ Sounds good to me, will do.

Volmarias posted:

Are you new to OO in general?

Yes. I'm not a programmer, I'm a Management Consultant.
In my (limited) spare time, I coach the FIRST Robotics team at the local highschool, so I'm learning Java so I can teach the kids how to program the robot.

Speaking of which, I just learned that the VEX-based robots used in the Savage Soccer competitions are programmed in C++. Is that going to be hard to learn once I'm done with Java?

# ? Oct 29, 2015 18:18

baquerd: Jul 2, 2007; by FactsAreUseless

Barnyard Protein posted:

Is an empty deck an exceptional condition? Maybe it is, but in the card games I know of there is a rule for what happens when you run out of cards in the deck. You wouldn't detect being at the end of an array by catching an ArrayIndexOutOfBoundsException.

It's an exceptional condition when you're trying to get the next card in the deck, absolutely. It's exactly analogous to asking for the next element past the end of the array.

# ? Oct 29, 2015 18:55

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

Yeah debugging is cool and good, it's like logging except you don't have to guess ahead of time, you can jump in wherever you like and see the values you're getting, and stepping through line by line makes it a lot easier to see where and why things are going wrong. There are a bunch of really useful pro features but you don't even need them, just the most basic breakpoint and stepping stuff is gold and it'll take you two minutes to pick it up

baquerd posted:

It's an exceptional condition when you're trying to get the next card in the deck, absolutely. It's exactly analogous to asking for the next element past the end of the array.

I know this is kind of academic anyway, but why is it exceptional and not completely normal? You're pulling cards off the deck and at some point you're going to run out, it's part of the normal flow. I mean if you're going with this logic, why use a for loop with a bounds check, instead of just an incrementing while loop that breaks when it goes out of bounds? Or why ever return a boolean instead of just assuming success and throwing an exception when the method's result is false?

baka kaba fucked around with this message at 19:10 on Oct 29, 2015

# ? Oct 29, 2015 19:00

Jerry Bindle: May 16, 2003

baquerd posted:

It's an exceptional condition when you're trying to get the next card in the deck, absolutely. It's exactly analogous to asking for the next element past the end of the array.

I must have misunderstood what you meant. So long as the API provides a way to determine if a card is available, then its more acceptable to throw a runtime exception if one is asked for but not available.

To elaborate what I mean, not necessarily directed as a response to you,

Java code:

// This would be terrible
try {
	while(true) {
		Card c = deck.getCard();
		/* ... */
	}
} catch(OutOfCardsException e) {
}

Java code:

// more acceptable
while(deck.hasCards()) {
	Card c = deck.getCard(); 
	/* Throws runtime exception iff deck is empty.  
		Helps API client understand they used the API wrong. */
}

# ? Oct 29, 2015 19:11

baquerd: Jul 2, 2007; by FactsAreUseless

Barnyard Protein posted:

To elaborate what I mean

Yeah, agree entirely.

# ? Oct 29, 2015 19:24

Volmarias: Dec 31, 2002; EMAIL... THE INTERNET... SEARCH ENGINES...

Squashy Nipples posted:

^^ Sounds good to me, will do.

Yes. I'm not a programmer, I'm a Management Consultant.
In my (limited) spare time, I coach the FIRST Robotics team at the local highschool, so I'm learning Java so I can teach the kids how to program the robot.

Speaking of which, I just learned that the VEX-based robots used in the Savage Soccer competitions are programmed in C++. Is that going to be hard to learn once I'm done with Java?

You'll have the concepts of OO down, at least, which is a big help and which a lot of intros spend way too much time on imo. This book was really helpful years and years and years ago since it assumed you had an idea what you were doing already, although it's pretty dated by this point I'm sure.

C++ makes it easier for you to shoot yourself in the foot and can be more difficult imo, but it's definitely more powerful for a lot of use cases. Game engines are typically made in C++, while Java is way too slow for that kind of environment typically (Minecraft being a notable exception).

# ? Oct 29, 2015 20:17

Zaphod42: Sep 13, 2012; If there's anything more important than my ego around, I want it caught and shot now.

Squashy Nipples posted:

Speaking of which, I just learned that the VEX-based robots used in the Savage Soccer competitions are programmed in C++. Is that going to be hard to learn once I'm done with Java?

C# you could jump to and its exactly like Java. C++ on the other hand will be similar, but you'll be required to do more low-level bit flipping stuff that you will have no idea about coming from java. Still, with everything else being the same you can get pretty far, and learning how to handle pointers manually will just be one more thing to learn and the rest will be easy enough. And you won't even have to do much pointer fiddling if you do it right (that's more C/C++ than proper C++)

# ? Oct 29, 2015 20:21

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

I can't figure out what is rotating my catalina.out log files...

code:

-rw-r--r--.  1 tomcat tomcat   241219 Oct 28 23:28 catalina.2015-10-28.log
-rw-r--r--.  1 tomcat tomcat   189613 Oct 29 23:08 catalina.2015-10-29.log
-rw-r--r--.  1 tomcat tomcat    21527 Oct 30 07:20 catalina.2015-10-30.log
-rw-r--r--.  1 tomcat tomcat        0 Oct 30 09:36 catalina.out

I want to standardize all log rotation using logrotate, but I'm not sure what is creating these catalina.2015-10-30.log files, I don't see anything in my logging.properties that would control this and the tomcat wiki says that it doesn't rotate by default. I went through everything in /etc/logrotate.d/ and nothing I found would be doing this.

# ? Oct 30, 2015 20:03

fletcher: Jun 27, 2003; ken park is my favorite movie; Cybernetic Crumb

^ Looks like the AsyncFileHandler might be the culprit!

# ? Oct 30, 2015 22:07

FieryBalrog: Apr 7, 2010; Grimey Drawer

Ran into this issue today. A look at the spec says Java autounboxes for == up to +/- 127? Weird.

code:

        Integer i = 127;
        Integer j = 127;
        if (i == j) {
            System.out.println("i equals j");
        } else {
            System.out.println("i does not equal j");
        }

        Integer k = 128;
        Integer l = 128;
        if (k == l) {
            System.out.println("k equals l");
        } else {
            System.out.println("k does not equal l");
        }

Some guy used == in code a long time ago and it caused a lot of headaches because it worked for quite a while without anyone noticing.

# ? Oct 30, 2015 22:38

Jerry Bindle: May 16, 2003

FieryBalrog posted:

Ran into this issue today. A look at the spec says Java autounboxes for == up to +/- 127? Weird.
code:
        Integer i = 127;
        Integer j = 127;
        if (i == j) {
            System.out.println("i equals j");
        } else {
            System.out.println("i does not equal j");
        }

        Integer k = 128;
        Integer l = 128;
        if (k == l) {
            System.out.println("k equals l");
        } else {
            System.out.println("k does not equal l");
        }
Some guy used == in code a long time ago and it caused a lot of headaches because it worked for quite a while without anyone noticing.

Ugh why does java still have primitive types

# ? Oct 30, 2015 22:51

baka kaba: Jul 19, 2003; PLEASE ASK ME, THE SELF-PROFESSED NO #1 PAUL CATTERMOLE FAN IN THE SOMETHING AWFUL S-CLUB 7 MEGATHREAD, TO NAME A SINGLE SONG BY HIS EXCELLENT NU-METAL SIDE PROJECT, SKUA, AND IF I CAN'T PLEASE TELL ME TO
EAT SHIT

It's just the boxing conversion right? Like with the String pool, if you box the same primitive value (from a certain range) multiple times you'll get the same object back for all of them.

quote:

If the value p being boxed is true, false, a byte, or a char in the range \u0000 to \u007f, or an int or short number between -128 and 127 (inclusive), then let r1 and r2 be the results of any two boxing conversions of p. It is always the case that r1 == r2.

It's an optimisation thing

# ? Oct 30, 2015 22:58

Kilson: Jan 16, 2003; I EAT LITTLE CHILDREN FOR BREAKFAST !!11!!1!!!!111!

FieryBalrog posted:

Ran into this issue today. A look at the spec says Java autounboxes for == up to +/- 127? Weird.

Some guy used == in code a long time ago and it caused a lot of headaches because it worked for quite a while without anyone noticing.

We've run into that one several times. :mad:

# ? Oct 31, 2015 02:38

Brain Candy: May 18, 2006

Kilson posted:

We've run into that one several times.

If you aren't using FindBugs or the equivalent and fixing everything it finds after that happening once, you deserve it.

# ? Oct 31, 2015 03:56

Volguus: Mar 3, 2009

Brain Candy posted:

If you aren't using FindBugs or the equivalent and fixing everything it finds after that happening once, you deserve it.

Honestly, any mid-sized (100+ developers) organization that does not have an automatic code analysis tool as part of their build process deserve what happens to them. The sad thing is that most don't live long enough to bite them in the butt.

# ? Oct 31, 2015 04:42

Adbot: ADBOT LOVES YOU

# ? Jun 13, 2024 02:34

Squashy Nipples: Aug 18, 2007

Barnyard Protein posted:

Ugh why does java still have primitive types

Heh? I don't get it; I would have thought that using primitives was the SOLUTION to this problem, like this:

code:

        int i = 127;
        int j = 127;
        if (i == j) {
            System.out.println("i equals j");
        } else {
            System.out.println("i does not equal j");
        }

Why would you use the Object form of instead of the primitive form for a basic integer variable?

# ? Oct 31, 2015 13:57

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Java questions which don't deserve their own thread, yet.

«‹›303 »