Thread: Java woes

I know this isnt a Java oriented-board, but this is the only message board I ever really come to, and since the other boards are for C/C++ only, I thought I would post my little Java Woe on this board.

Its a very small one.

A. Does Java allow templated classes? I have a very big Java book, and nowhere in the entire book does it talk about templated classes. Neither does my Java help file, so I am assuming Java doesnt allow them. Is that a correct assumption? Personally, that is incredibly stupid if it doesnt, because you cant create very versatile array/stack/queue classes without templated classes.

B. I hate that Java doesnt allow this syntax:

class MyClass {
public:
int a, b, c, d, etc;
private:
blah blah blah
}

instead in java you must do this:

class MyClass {
public a, b, c, d, etc;
private blah blah blah
}

which means if you have a very big class, you must list the words public/private/or protected in front of every single variable or function you want to specify, instead of just creating a section pof publics, and a section of privates, etc.

GRRRRR

i agree java sucks.....a bold statement, but true according to many including me. i'm being forced 2 learn java this summer because i got in a 3 week uni program that, as far as i've noticed, teaches ONLY java....the booklets they said they will be handing out, the books they recomended(4 of em) all realed to java.... i;d write down the book names, but i'm too lazy. the thing i hate about java is that it complicates things when there is no need of any. damned bastards....and these books...costs a fortune but when i go to read them i feel like i'm wasting my life!!

sry for all the hatred ....

and there;s one more thing, in java u HAVE to specify a return type...what the hell is that? and VOID MAIN is standars

Originally posted by w00tsoft
Both are false. While i'm not the biggest fan of OOP, that doesn't mean i've never programmed with it before. Care to clue me in on what is actually useful for?

I will a bit. Actually, I won't very much. Take a look at the prototype for this linked list class (each instance of the class is a node) (Heh, second or third time I've posted this in a few days)

Code:

class node		
{
  public:
    void adddata(unsigned char add);
    node(void);	
    ~node(void);
    void printlist();
  private:
    unsigned char data;
    node *next;
}

Using that prototype, I'm able to do things in the adddata function that you couldn't ensure if data was public - like only adding the data if it isn't present anywhere else in the list. And just think how messed up a typo in your main() function could get your list if it changed next. With data and next as private, once you have your class working, making linked lists is completely maitanence free and you aren't going to mess anything up with a typo in main(). You can even stick the class in other programs you make later. Comes in handy.

Edit: you silly little troll. I'm sorry I wasted time typing this. Eibro could most definitely think of reasons for them - and probably better ones than what I just listed.

Having a class that looks like this

Code:

class pointless
{
  public:
    seta(int data) { a = data;}
    setb(int data) { b= data;}
  private:
     int a;
     int b;
}

is completely pointless. And yeah, I simplified that a little more than what that class should have, because I don't have any way to get your data there... but all that is is a struct with some functions in it to slow it down. You might as well use a struct. But in more complicated classes, ones that you would actually use, private and public are useful. Take a look at my last post, for example. If you accidentally try to modify next in main without thinking about it, you're going to get an error and know that you're messing something up. If it was public, you would be free to set next to NULL, and then you're screwed and you have to find it with a debugger or something. BTW, I am being useful - learn not to insult the people that are most capable of answering your questions. It will get you a lot farther, and you won't be called a TROLL nearly as often.

"LOL I THINK YOU ARE STUPID TROLL, BUT THEN AGAIN I CANT REALLY THINK OF ANY USE FOR THEM EITHER, SO I WONT GIVE ANY EXAMPLES OF WHY TO USE THEM!!!111"

Sound's to me like you're mocking him - trying to get him to post an angry reply. See troll

troll

v.,n. 1. [From the Usenet group alt.folklore.urban] To
utter a posting on Usenet designed to attract predictable
responses or flames; or, the post itself. Derives from the phrase
"trolling for newbies" which in turn comes from mainstream
"trolling", a style of fishing in which one trails bait through a
likely spot hoping for a bite. The well-constructed troll is a post
that induces lots of newbies and flamers to make themselves look
even more clueless than they already do, while subtly conveying to
the more savvy and experienced that it is in fact a deliberate
troll. If you don't fall for the joke, you get to be in on it. See
also YHBT. 2. An individual who chronically trolls in sense 1;
regularly posts specious arguments, flames or personal attacks to a
newsgroup, discussion list, or in email for no other purpose than to
annoy someone or disrupt a discussion. Trolls are recognizable by
the fact that the have no real interest in learning about the topic
at hand - they simply want to utter flame bait. Like the ugly
creatures they are named after, they exhibit no redeeming
characteristics, and as such, they are recognized as a lower form of
life on the net, as in, "Oh, ignore him, he's just a troll." 3.
[Berkeley] Computer lab monitor. A popular campus job for CS
students. Duties include helping newbies and ensuring that lab
policies are followed. Probably so-called because it involves
lurking in dark cavelike corners.

Some people claim that the troll (sense 1) is properly a narrower
category than flame bait, that a troll is categorized by containing
some assertion that is wrong but not overtly controversial. See
also Troll-O-Meter.

Source: Jargon File 4.2.0

Okay, enough responding to troll bait for me.