|
1) I'm currently making a package with a bunch of generally useful classes (like a calculator class, a line sorting class, etc.) neatly stored inside it - let's call it jackPackage.
Now what I want is that every time I write a Java class, no matter what project/package/folder it's in, I can just write import jackPackage (or java.jackPackage or something like that) and it will import this package (much like the standard packages such as java.lang or java.awt). Where do I have to put it and do I have to do something special to be able to do this?
2) Let's say I have a huge array of integers that I know will all be of values between 0 and 15. Is it possible to make the elements of this array 4-bit numbers so as to conserve space?
Is there perhaps a bit primitive type that would allow me to create my own class with an arbitrary number of bits to save a number (I know a byte primitive type exists, haven't seen mention of a bit one though)?
3) Is there an advantage to defining getter and setter methods for an attribute over simply making said attribute public, provided that you want the attribute both readable and settable?
...and that's the bottom line because Mate de Vita said so.
|
|
|
|
|
≡
|
2012 Sep 16 at 16:34 UTC
— Ed. 2012 Sep 16 at 17:37 UTC
|
|
|
Down Rodeo
Cap'n Moth of the Firehouse
2007 Oct 19 • 5486
57,583 ₧
|
Mate de Vita said: 1) I'm currently making a package with a bunch of generally useful classes (like a calculator class, a line sorting class, etc.) neatly stored inside it - let's call it jackPackage.
Now what I want is that every time I write a Java class, no matter what project/package/folder it's in, I can just write import jackPackage (or java.jackPackage or something like that) and it will import this package (much like the standard packages such as java.lang or java.awt). Where do I have to put it and do I have to do something special to be able to do this?
The directory structure follows the packages, so when you have jPackage.MyClass, you folders would be jPackage/MyClass.java. (Watch for capitals - it might not like that).
Mate de Vita said: 2) Let's say I have a huge array of integers that I know will all be of values between 0 and 15. Is it possible to make the elements of this array 4-bit numbers so as to conserve space?
Is there perhaps a bit primitive type that would allow me to create my own class with an arbitrary number of bits to save a number (I know a byte primitive type exists, haven't seen mention of a bit one though)?
As well as ints there are bytes and shorts. Bytes are one byte, funnily, and shorts are two. Logically they will behave like this. Sadly, internally in most JVMs that I know of, they are stored like ints, so you do not gain anything from storing them as such. If I were going to do something involving the bit representation and so on, I'd use C or C++.
Mate de Vita said: 3) Is there an advantage to defining getter and setter methods for an attribute over simply making said attribute public, provided that you want the attribute both readable and settable?
Well, say you want all changes to a certain member variable to be logged in a file. If you made it public, anyone could change it and you'd never know. OTOH if you have a public setter which goes like x = whatever; log("x = " + x); you'd be set. Those are the practical reasons, beyond that it's nice to hide functionality behind an unchanging API. What if the type of x changes internally? Those sorts of things.
|
|
|
|
|
≡
|
2012 Sep 16 at 20:49 UTC
|
|
|
|
Down Rodeo said: The directory structure follows the packages, so when you have jPackage.MyClass, you folders would be jPackage/MyClass.java. (Watch for capitals - it might not like that).
OK but how do I import it into a class in a completely different project and a completely different folder on the drive? Can I still import it simply with code import jPackage.MyClass and it'll find it?
Or do I need to do something special with the CLASSPATH environmental variable or something?
...and that's the bottom line because Mate de Vita said so.
|
|
|
|
|
≡
|
2012 Sep 17 at 08:55 UTC
— Ed. 2012 Sep 17 at 09:58 UTC
|
|
|
|
Why do you want this bulk import in #1? Are you constantly importing a large group of the same or similar classes? Wouldn't it be more efficient to only load what you need? I can't actually answer your question, just debate itttt.
Re #2, java supports bitwise so you could use these variables in pairs, you could bithack two of them into an 8bit unsigned. Realistically this saves space as long as you need more than one 4bit int. Extra points if the pairings are logical so the value of the full 8bit int is still actually data and not just the sum of an arbitrary pairing.
|
|
|
|
|
≡
|
2012 Sep 17 at 16:33 UTC
|
|
|
|
phoenix_r said: Why do you want this bulk import in #1? Are you constantly importing a large group of the same or similar classes? Wouldn't it be more efficient to only load what you need? I can't actually answer your question, just debate itttt.
I have a project of self-made classes with generally useful functions, like string manipulations, matrix calculations, power function, etc.
They're categorized into packages according to their field - mathematical classes are in package maths, string related classes are in package strings, etc.
Now say sometime in the future I want to write a program that calculates the roots of the characteristic polynomial of a matrix. I'd like to be able to import the package maths so I can use its classes' functions in said program.
I don't really get what you mean by "bulk import". It's an importing of a single package, isn't that pretty standard? Like importing for example the package java.awt?
...and that's the bottom line because Mate de Vita said so.
|
|
|
|
|
≡
|
2012 Sep 17 at 17:09 UTC
|
|
|
Down Rodeo
Cap'n Moth of the Firehouse
2007 Oct 19 • 5486
57,583 ₧
|
Yes, dicking around with the CLASSPATH variable will do it. You could also make a "release" version of your classes, and place them in something like ~/Java/, but that's a tad extreme. Better just to add to your CLASSPATH such that you also include the root directory of your classes. You can also pass both the compiler and the runtime a switch like -cp IIRC which will change the path for that compilation.
I've been drinking, please complain if that doesn't make sense.
|
|
|
|
|
≡
|
2012 Sep 18 at 21:50 UTC
|
|
|
|
1)
The Right Way™ is to use version control. Any time you are doing anything with code, you should be using version control. Eventually you'll be sorry if you didn't.
Depending on what system you use, you should be able to add your shared code as a submodule, or just a checkout within the larger project. The version control will help you keep them all in sync when you invariably make changes. And it works across any number of systems and prevents catastrophic loss.
|
|
|
|
|
≡
|
2012 Sep 21 at 23:28 UTC
— Ed. 2012 Sep 21 at 23:33 UTC
|
|
|
|
2)
If there are only 16 values, you might use an enum, and then hope Java uses only 4 bits to store the values.
AFAIK it will almost certainly use more than 4 bits anyway, b/c Java keeps track of type information and what not.
Enums may or may not fit your problem. If the meaning of the 16 values is the same 16 integers then probably not.
|
|
|
|
|
≡
|
2012 Sep 21 at 23:37 UTC
|
|
|
|
3)
If you're making an API you should use getters and setters. Or go one further and design the interface such that users don't need to twiddle individual values in the first place.
If it's something internal I would generally avoid them, since you probably don't need them. And adding a lot of crap you don't need just causes problems.
As for logging variable changes, that sounds like something you ought to do in a debugger. Don't complicate the code when you can leave it alone and use a debugger instead.
|
|
|
|
|
≡
|
2012 Sep 21 at 23:43 UTC
|
|
|
|
superjer said: 1)
The Right Way™ is to use version control. Any time you are doing anything with code, you should be using version control. Eventually you'll be sorry if you didn't.
Depending on what system you use, you should be able to add your shared code as a submodule, or just a checkout within the larger project. The version control will help you keep them all in sync when you invariably make changes. And it works across any number of systems and prevents catastrophic loss.
What's version control?
...and that's the bottom line because Mate de Vita said so.
|
|
|
|
|
≡
|
2012 Sep 24 at 18:02 UTC
|
|
|
Down Rodeo
Cap'n Moth of the Firehouse
2007 Oct 19 • 5486
57,583 ₧
|
Much as supes is right with version control, I'm not sure that's the question you're asking. Version control is a way of creating a history for your software which reflects the total sum of changes made over its life. It is very useful. (Use mercurial)
As an addendum, I still disagree about the logging stuff. For instance, you can use a setter to make sure that all changes to a variable notify an event listener, if that's what you're into.
|
|
|
|
|
≡
|
2012 Sep 24 at 19:28 UTC
|
|
|
|
If you're using [gs]etters to solve a real problem, then good. But if you're doing it because "I like to follow design patterns" or something then STOP.
It seems like a rare situation that the right answer is to watch for a variable change and fire off an event listener. I mean, it might be. But it sounds like tunnel vision. Who would change the var and why? Are there other things that typically go along with changing this var and what are they? Can we make a method that wraps up the process cleanly?
[GS]etters are generally devoid of context. All the [gs]etter knows is that the value was accessed or changed. No idea why, or whether it's part of some larger effort. That's fine if it's enough to solve a real problem now. But don't just sprinkle them everywhere expecting it to solve all future problems.
[GS]etters really aren't much more protection than just having public member vars, anyway. You can make everything [gs]ettable, but you can't enforce what order everything can be [gs]et in, which could lead to a very complicated implementation. It's usually easier and more efficient to [gs]et a lot of things at once, with some kind of a real API-like thing.
Sorry, I'm taking the opportunity to rant about something that's been bugging me for a long time. :)
|
|
|
|
|
≡
|
2012 Sep 29 at 02:40 UTC
— Ed. 2012 Sep 29 at 02:41 UTC
|
|
|
Down Rodeo
Cap'n Moth of the Firehouse
2007 Oct 19 • 5486
57,583 ₧
|
The example I was directly referencing was some teaching code for a course I did a couple of years ago - the code was for solving gravitational interactions for a few bodies in 2d in quite a nice general manner. The reason a setter was used was to make sure that when the (x,y) pair was changed anything that listened for it would know, in particular the canvas that was displaying this motion.
This makes it easy to add additional functionality, for example a logging system, because pretty much all you need to do is add it to the list of listeners.
I appreciate that it's often applied with little thought, in the best case your encapsulation should be strong enough that you don't have getters and setters for member variable because nobody needs to see them.
|
|
|
|
|
≡
|
2012 Sep 29 at 11:29 UTC
|
|
|
|
code public static void registerBlock(net.minecraft.src.Block block, Class<? extends ItemBlock> itemclass) ??
|
|
|
|
|
≡
|
2012 Nov 28 at 12:42 UTC
— Ed. 2012 Nov 28 at 12:43 UTC
|
|
|
Down Rodeo
Cap'n Moth of the Firehouse
2007 Oct 19 • 5486
57,583 ₧
|
That looks wrong. What are you doing?
|
|
|
|
|
≡
|
2012 Nov 29 at 03:47 UTC
|
|
|
|
|
|
|
|
|
≡
|
2012 Nov 29 at 18:58 UTC
— Ed. 2012 Nov 29 at 18:58 UTC
|
|
|
Down Rodeo
Cap'n Moth of the Firehouse
2007 Oct 19 • 5486
57,583 ₧
|
Oh, wait, it doesn't, it's like lots of generic stuff, and the question mark seems to mean that whatever that class is it must extend the one specified. I didn't know you could do that.
|
|
|
|
|
≡
|
2012 Nov 30 at 02:11 UTC
|
|
|
|
|
|
|
|
|
≡
|
2012 Nov 30 at 09:19 UTC
|
|
|
|
|
|
|
|
|
≡
|
2012 Dec 2 at 00:29 UTC
|
|
|
|
your link color is very close to your post color. 
I drink to forget but I always remember.
|
|
|
|
|
≡
|
2012 Dec 3 at 01:04 UTC
|
|
|
|
That's cause AJ refused to change it to yellow.
...and that's the bottom line because Mate de Vita said so.
|
|
|
|
|
≡
|
2012 Dec 3 at 11:34 UTC
|
|
|
|
Page [1]
|
