Home > Archive > Java Help > April 2007 > A list of ever member in a class.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
A list of ever member in a class.
|
|
| Hakusa@gmail.com 2007-04-21, 10:09 pm |
| I came across the problem that I want to create a class of X members,
but I can't make an array of them unless I know what X is unless I
created a class that used two or three different arrays and keep
switching between which is the active one while neutralizing the
other. That would be a bit more of a distraction from my goal than I'd
like, and it seems like this problem would already have been solved by
the language itself.
It seems that it would make a lot of sense if the language kept track
of how many members there are of each class and what they are. Is
there?
| |
| Greg R. Broderick 2007-04-21, 10:09 pm |
| "Hakusa@gmail.com" <Hakusa@gmail.com> wrote in news:1177192223.896645.222460
@o5g2000hsb.googlegroups.com:
> It seems that it would make a lot of sense if the language kept track
> of how many members there are of each class and what they are. Is
> there?
See the java.lang.Class class, particularly its getFields(), getConstructors
() and getMethods() methods.
Cheers!
--
---------------------------------------------------------------------
Greg R. Broderick gregb+usenet200612@blackholio.dyndns.org
A. Top posters.
Q. What is the most annoying thing on Usenet?
---------------------------------------------------------------------
| |
| Tom Hawtin 2007-04-21, 10:09 pm |
| Hakusa@gmail.com wrote:
> I came across the problem that I want to create a class of X members,
> but I can't make an array of them unless I know what X is unless I
> created a class that used two or three different arrays and keep
> switching between which is the active one while neutralizing the
> other. That would be a bit more of a distraction from my goal than I'd
> like, and it seems like this problem would already have been solved by
> the language itself.
What's wrong with Object[]?
> It seems that it would make a lot of sense if the language kept track
> of how many members there are of each class and what they are. Is
> there?
You mean instances? That would make garbage collection more difficult
and not be particularly useful.
Tom Hawtin
| |
| Hakusa@gmail.com 2007-04-21, 10:09 pm |
| On Apr 21, 10:23 pm, Tom Hawtin <use...@tackline.plus.com> wrote:
> What's wrong with Object[]?
Because an array requires Java to know how much space to save or it.
On Apr 21, 7:57 pm, "Greg R. Broderick" <gregb
+usenet200...@blackholio.dyndns.org> wrote:
> See the java.lang.Class class, particularly its getFields(), getConstructors
> () and getMethods() methods.
I'll check tomorrow . . . although that and the previous post might
make it seem futile.
| |
| Patricia Shanahan 2007-04-21, 10:09 pm |
| Hakusa@gmail.com wrote:
> On Apr 21, 10:23 pm, Tom Hawtin <use...@tackline.plus.com> wrote:
>
> Because an array requires Java to know how much space to save or it.
If that is the problem, why not ArrayList?
Patricia
| |
| Daniel Gee 2007-04-22, 4:16 am |
| Are you familiar with Java's Template Classing? Do you want something
like this?:
public class MemberHolder<T>
{
public T[] mymembers;
public MemberHolder(int numberToHold)
{
mymembers = new T[numberToHold];
}
}
| |
|
|
|
| Daniel Gee <zefria@gmail.com> wrote in news:1177227493.424674.45700
@o5g2000hsb.googlegroups.com:
> Are you familiar with Java's Template Classing? Do you want something
> like this?:
<nitpicking>
No such thing as java templates. What you are referring to are generics.
A template in C++ is a piece of code that acts as a template (duh) for
the compiler to create code for you. Java generics do no such thing -
they simply enforce compile-time typesafety.
</nitpicking>
> public class MemberHolder<T>
> {
> public T[] mymembers;
>
> public MemberHolder(int numberToHold)
> {
> mymembers = new T[numberToHold];
> }
>
> }
Unfortunately this won't work. Mixing generics and arrays is never a
good idea, and in this case the compiler won't even let you: you can't
create an array of generic types. There's a section in the JLS
explaining why this is, but I'm afraid I can't remember where exactly.
Zero
| |
| Daniel Gee 2007-04-23, 7:08 pm |
|
> <nitpicking>
> </nitpicking>
Ah, right. I get those names often mixed up because the teacher who
gave me the first formal introduction to the subject was actually a C+
+ programmer who wasn't used to teaching in Java.
Right then, "generics" it is.
>
>
>
> Unfortunately this won't work. Mixing generics and arrays is never a
> good idea, and in this case the compiler won't even let you: you can't
> create an array of generic types. There's a section in the JLS
> explaining why this is, but I'm afraid I can't remember where exactly.
but...... sections from the source for java.util.ArrayList itself
read:
public class ArrayList<E> extends AbstractList<E>
implements List<E>, RandomAccess, Cloneable,
java.io.Serializable
{
private transient E[] elementData;
....
public ArrayList(int initialCapacity) {
super();
if (initialCapacity < 0)
throw new IllegalArgumentException("Illegal Capacity: "+
initialCapacity);
this.elementData = (E[])new Object[initialCapacity];
}
....
}
Does the casting make all the difference?
| |
| Andrew Thompson 2007-04-23, 7:08 pm |
| On Apr 22, 7:50 am, "Hak...@gmail.com" <Hak...@gmail.com> wrote:
Sub: A list of ever member in a class.
As an aside, what is the point of having this list?
What is it that you are wanting to offer to the end user?
(There are a few good reasons to use reflection, many
bad ones.)
| |
| Tom Hawtin 2007-04-24, 8:08 am |
| Daniel Gee wrote:
>
> but...... sections from the source for java.util.ArrayList itself
> read:
Not everything in the Java library is written nicely. This is an example
of that. Don't copy it.
Tom Hawtin
| |
|
| Daniel Gee <zefria@gmail.com> wrote in news:1177371058.868913.54070
@n76g2000hsh.googlegroups.com:
>
> public class ArrayList<E> extends AbstractList<E>
> implements List<E>, RandomAccess, Cloneable,
> java.io.Serializable
> {
> private transient E[] elementData;
> ...
> public ArrayList(int initialCapacity) {
> super();
> if (initialCapacity < 0)
> throw new IllegalArgumentException("Illegal Capacity: "+
> initialCapacity);
> this.elementData = (E[])new Object[initialCapacity];
> }
> ...
> }
>
> Does the casting make all the difference?
>
Yes. Here they are creating an array of Objects, and casting it to an
array of Es, which to the compiler is quite different from creating an
array of Es directly.
As Tom Hawtin said, don't try this at home.
I've never liked generics, and seeing this code doesn't help. If the
people implementing ArrayList have to resort to this kind of tricks, maybe
it should've made them wonder at the validity of generics.
Of course copying the syntax from C++ templates (which btw *are* a well
thought out feature, albeit with scary-looking syntax) only makes things
worse.
Btw just because I don't like generics doesn't mean I don't use them. As
long as you know what to expect and what not they're useful in their own
right. I just think they could've been designed better.
Zero
| |
| Tom Hawtin 2007-04-24, 7:08 pm |
| zero wrote:
> Daniel Gee <zefria@gmail.com> wrote in news:1177371058.868913.54070
> @n76g2000hsh.googlegroups.com:
[color=darkred]
> Yes. Here they are creating an array of Objects, and casting it to an
> array of Es, which to the compiler is quite different from creating an
> array of Es directly.
> If the
> people implementing ArrayList have to resort to this kind of tricks, maybe
> it should've made them wonder at the validity of generics.
It is not necessary to do this sort of cast in order to implement
ArrayList. It's just to avoid lots of unchecked casts whenever an
element is read from the array.
Anyway, now that ArrayList has been implemented, we can all use List
instead of reference arrays. Even if ArrayList were implemented
natively, the implementation still would not make any difference to
other code.
Tom Hawtin
|
|
|
|
|