All things are lawful, but not all things are profitable.
Tim Moores wrote:No need to add anything. To the contrary, you need to remove something. Take a very close look at the entire line 11.
tangara goh wrote:I have this method in my Subject class which make use of a Enum class and I am not sure where to put the ;
tangara goh wrote:Hope someone can let me know how cos when I close the clsss with } it still appear this message.
Ron McLeod wrote:
tangara goh wrote:I have this method in my Subject class which make use of a Enum class and I am not sure where to put the ;
Maybe I'm missing something? Which method are you referring to, and where is the Enum?
Ron McLeod wrote:
tangara goh wrote:Hope someone can let me know how cos when I close the clsss with } it still appear this message.
What is the message, and where does it appear from?
Ron McLeod wrote:Is the for loop inside a method?
tangara goh wrote:
Cos by right it should be { but my Eclipse IDE Oxygen keeps making me putting {{ and only when I put {{ then there's no error...
The standard Oracle compiler is even more likely to get it wrong. IDEs often suggest several corrections, which sometimes makes it even more difficult to understand the problem.Dave Tolls wrote:. . . IDEs tend to attempt a guess at how to fix the problem, and they are often wrong. . . .
Carey Brown wrote:There are a few things wrong with your code but it is hard to know what to suggest because the intent of this method is unclear.
Forget this getValue() method for a second and please explain in English what it is that you are trying to achieve.
Note: Enums have an implicit "name" field and getName() method. This is unfortunate because so often "name" has significance to the project but is in conflict with enum's usage. My advice is to change "name" to something else so that you are not accidentally overriding the enum "name". Also, enums are typically in all upper case characters, e.g. L_PRI_CHINESE("L1").
Why not insert the values directly into the database? Once inserted they should be persistent and not need to be inserted again, though they may need updating from time to time. As Junilu said, enum seems like the wrong vehicle for this. I even doubt you need a Map, it seems like just a list of Subject's would suffice for inserting into a database or read the list from a flat file. On the other hand, when reading the Subjects back in from the database, a Map might be a useful construct.tangara goh wrote:So now, I have a List<Subject>subjectlist which I am able to insert the ParameterValues into the database.
tangara goh wrote:...and then I can insert it to the column SubjectIDs, SubjectNames insides column SubjectNames and tutorId into column tutor.
so that the table will look like this
SubjectName SubjectID tutor_id
--------------- ------------ ---------
UPEnglish 2 1
UPMaths 3 1
UPEnglish 2 2
There are three kinds of actuaries: those who can count, and those who can't.
Piet Souris wrote:Just as a matter of exercise, you can have your Subject class implemented as an enum, including a look-up table. For instance:
Given the objections against an enum, I leave it up to you to see if this is useful.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
There are three kinds of actuaries: those who can count, and those who can't.
Junilu Lacar wrote:I don't think enums are an appropriate mechanism for representing the concept you're trying to represent here. Subjects and their IDs are temporal, that is, they will probably change over a relatively short period of time. Changing an enum by adding or removing values can break a lot of code and that's a bad thing. Thus, enums are used for value sets like Boolean (false, true) or Suits of a standard deck of cards (Clubs, Spades, Hearts, Diamonds). These things have a limited number of distinct values that don't get added to or taken away from. Subjects and their IDs are not like this. I suggest you use a class that can represent name/value pairs or a custom class that encapsulates the attributes of name and Id instead. With a class, you can create as many instances to represent however many different subjects as you need.
Carey Brown wrote:
tangara goh wrote:The subjects and Ids will never change.
tangara goh wrote:(...)
So the List<Subject> must have a list of SubjectNames and a list of matching SubjectIDs.
But, I am not sure how to do it.
There are three kinds of actuaries: those who can count, and those who can't.
Piet Souris wrote:
tangara goh wrote:(...)
So the List<Subject> must have a list of SubjectNames and a list of matching SubjectIDs.
But, I am not sure how to do it.
Well, you could have this Subject enum:
with this use:
but I agree with Junilu: a Subject class like in your opening post, and oerhaps with a field: MOESubjectIDs moes, wasn't bad at all, and much more flexible.
Carey Brown wrote:perhaps this TUTORIAL will help
There are three kinds of actuaries: those who can count, and those who can't.
Consider Paul's rocket mass heater. |