My point is, If java allows us to use type name as variable name, how to use the enum type in rhs of the following code (B b = B.a;).
If you're wondering why Java allows it, it's probably because it would have made the language spec and compiler implementations more complicated to disallow it, and it's easy enough to make it not be an issue simply by following good practices. In fact, since all types other than primitives conventionally start with an uppercase letter, and since variables conventionally start with a lowercase letter, and since we're not allowed to name a variable the same as a primitive type, all we have to do is follow variable and class naming conventions and the issue will never arise.
I thought about the scenario and this is what came up to my mind.
Each class can be compiled independently as long as it does not refer to any other class. The other types (class) can be introduced at runtime by placing them in the class path. So it is impossible for the compiler to know what all valid type names will be present at runtime. Maybe for this reason the compiler does not impose any restriction on the programmer depending on the type names. In my scenario java correctly recognizes the static int and overlooks the type. But I personally feel that the compiler should detect it as in my case all the required information are available at compile time. Maybe its some logical limitation or just the designers choice.
I found your second post hard to understand. There is (as Jeff V has already said) a good reason for those conventions. Remember the opposite of “good practice” is “bad practice”, so breaching conventions can be “bad practice”.
It would be very difficult to design a compiler to check that types and variable names do not conflict with each other. Especially when the compiler can tell from the context whether a particular occurrence of the letter B is used as a type or the field name. If you write B b = B.b; both Bs mean the type. If you write B = 123; it is the field, if you cast it B b = (B) B; the red B is the field and the two blue Bs the type. The compiler will correctly recognise that as a cast and complain you can’t do that cast. In fact you cannot confuse the compiler like that, only human readers.
Sarfarajey Akram wrote:Thanks Jeff. Though your reply does not answer my query. Conventions are just conventions. They are not laws and are recommended as they are good practice.
I gave you a probable reason why the language works the way it does. The only way to know the answer for sure to those "why" questions is to ask the language designers who made the decisions, and they don't frequent this forum as far as I know.
I also gave you a possible approach that would let you do what you're trying to do. You can test that directly yourself and see if it works.
I also suggested a better approach to writing your code, so that this won't be an issue in the first place.
I'm not sure what else you want, although at this point it seems like you're asking how to be able to continue to follow a bad practice in a more general case. That's not something I want to answer. I'm not interested in helping people shoot themselves (and the next developer who has to look at their code) in the foot.
Campbell Ritchie wrote:Remember the opposite of “good practice” is “bad practice”, so breaching conventions can be “bad practice”.
Not just 'can be'; IS - and certainly in this case.
@Sarfarajey: This has the smell of a piece of code from an SCJP question, and they are specifically intended to be confusing. Furthermore, the SCJP exam is NOT about good programming, it is about understanding the Java compiler.
This is not, by any means, the only case of Java allowing you to do something you shouldn't; and if you want the answer to the question 'why' every time you run into one, your learning process is likely to be long and hard.
My advice: accept it, and move on. You'll have plenty of time to e-mail the designers of the language when you're a bit further down the road.
@all Thank you for your valuable advice.
Firstly I am not advocating for bad coding practices. I know they are for good reason and I always try to follow them.
Below are some of my findings,
1. Create two type of same name in same file/in two different file within same package. They wont compile. Below is the example.
2. Create a type A (file name is A.java).
Now create a jar using the generated class, say myjar.jar and put this jar to class path of A.java. Now the compiler wont report any problem.(javac -classpath myjar.jar A.java).
3. Third one is what I mentioned in my first post, that is mixing type name and variable name.
These are the simple reasons why so many 'why' came to my mind and I was confused.
Sarfarajey Akram wrote:Firstly I am not advocating for bad coding practices. I know they are for good reason and I always try to follow them.
Create two type of same name in same file/in two different file within same package...
Do you see how that statement is contradictory? The second half of it IS a bad coding practise - as is not using meaningful names when you write your classes.
And furthermore, as Jeff and Campbell have both tried to explain, the confusion is yours, not the compiler's.