Even older fart, even newer newbie

S

Stan Goodman

I have what I think is a very simple question, the answer to which is
probably "No".

When instantiating a class, is it possible to use the CONTENT of a
string variable as the NAME of the new object?
 
M

Marco Schmidt

Stan Goodman:
When instantiating a class, is it possible to use the CONTENT of a
string variable as the NAME of the new object?

No, variable names are fixed at runtime in Java.

However, you might want to use a HashMap to associate your new object
with a name.

String name = "aName";
Object obj = ... ; // new object

HashMap map = new HashMap();
map.put(name, obj);
....

Object retrievedObject = map.get(name);

If no object associated with the name is in the map, retrievedObject
is null.

Regards,
Marco
 
M

Moshe Sayag

You can specify the name of the instance class by a string variable, but
not the name of the new object.

String name = "my.package.MyClass";
....
Class clazz = Class.forName(name);
MyClass mc = (MyClass) clazz.newInstance();
....

I am not aware of any way to name a variable dynamically and I can't
find any reason to do it.
In general, the object's name is a local identifier and has no use but
making the code more readable. For any technical use, t1, t2 and t3 are
just as good as any other names.

Hope this helps

Moshe
 
J

Joona I Palaste

Nothing could surprise me less. =;->8
I'll describe the problem in more detail:
Given a file containing groups of text lines, each group falling
naturally into a structure like a linked list. In the first line of
each such group is embedded an identifying string, which is unique. I
would like to be able to make an object of each such group (a linked
list), and idetify it by this unique string. I would like to set all
this up in the first phase of the program. In a later phase, the
program will generate a string identical to one of the unique strings,
and I will need to access the corresponding group to process it..
Since I posted the question, I have read a bit about hashtables; in my
present stage of ignorance, that seems a good approach, especially as
it has been suggested by Marco. Is that right? Is there another
suggestion?

I'm still not sure I understand your question, but it seems like you
want to map String values onto objects, which in this case are lists of
other String values.
If this is true then hashtables are indeed the way to go. Here is an
example of how they could be used:

Map map = new HashMap();
List list;
list = new ArrayList();
list.add("Finland"); list.add("Sweden"); list.add("Norway");
list.add("Denmark"); list.add("Iceland");
map.put("Scandinavia", list);
list = new ArrayList();
list.add("Estonia"); list.add("Latvia"); list.add("Lithuania");
map.put("Baltia", list);

--
/-- Joona Palaste ([email protected]) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"I said 'play as you've never played before', not 'play as IF you've never
played before'!"
- Andy Capp
 
B

Brad BARCLAY

Stan Goodman wrote:

Hey Stan:
I'll describe the problem in more detail:

Given a file containing groups of text lines, each group falling
naturally into a structure like a linked list. In the first line of
each such group is embedded an identifying string, which is unique. I
would like to be able to make an object of each such group (a linked
list), and idetify it by this unique string. I would like to set all
this up in the first phase of the program. In a later phase, the
program will generate a string identical to one of the unique strings,
and I will need to access the corresponding group to process it..

In this case, what you want to do is to create an object that
encapsulates one linked-list element of data, which has an assignable
String field in which you can keep your unique identifier. At its most
basic, you'll probably put together a class something like this:

public class MyListElement {
public String id = null; // Your identifier will go here
public MyListElement next = null;
// ^ Pointer to the next element in the list

public MyListElement(String id) {
this.id=id;
}

public MyListElement next() {
return next;
}

public boolean hasID(String s) {
return id.equals(s);
}
}

With this sort of object, you'll be able to "walk" the list using a
loop such as:


// "head" is first element in the list
MyListElement mle = head;
while (!mle.hasID(id_we_are_looking_for)) mle=mle.next();
Since I posted the question, I have read a bit about hashtables; in my
present stage of ignorance, that seems a good approach, especially as
it has been suggested by Marco. Is that right? Is there another
suggestion?

Using a HashTable certainly has its own benifits, but it isn't a linked
list. That is okay however -- you probably don't strictly _need_ a
linked list to store and retreive your data anyhow. HashTable has the
benifit of being able to take care of the key matching for you.

The only potential disadvantage of HashTable is that it stores elements
of the type java.lang.Object, so you don't necessarily have forced
type-safety as you do in the example above. This isn't necessarily a
problem if you're careful to ensure that only your object type is
written to the table, and you cast Objects read from the table back to
your object type before using them.

HTH!

Brad BARCLAY
 
S

Stan Goodman

Stan Goodman wrote:

Hey Stan:

Hi, Brad!!
In this case, what you want to do is to create an object that
encapsulates one linked-list element of data, which has an assignable
String field in which you can keep your unique identifier. At its most
basic, you'll probably put together a class something like this:

public class MyListElement {
public String id = null; // Your identifier will go here
public MyListElement next = null;
// ^ Pointer to the next element in the list

public MyListElement(String id) {
this.id=id;
}

public MyListElement next() {
return next;
}

public boolean hasID(String s) {
return id.equals(s);
}
}

With this sort of object, you'll be able to "walk" the list using a
loop such as:


// "head" is first element in the list
MyListElement mle = head;
while (!mle.hasID(id_we_are_looking_for)) mle=mle.next();


Using a HashTable certainly has its own benifits, but it isn't a linked
list. That is okay however -- you probably don't strictly _need_ a
linked list to store and retreive your data anyhow. HashTable has the
benifit of being able to take care of the key matching for you.

I don't, at this stage. Later I would need to operate only on a subset
of the elements, and for each of these make a linked list consisting
of only a few of its lines.

If anyone wonders what this is about, the original file is a GEDCOM
genealogical file, in which the elements are groups of lines (in
general a variable number), each element representing an entity, i.e.
a person or a family.
The only potential disadvantage of HashTable is that it stores elements
of the type java.lang.Object, so you don't necessarily have forced
type-safety as you do in the example above. This isn't necessarily a
problem if you're careful to ensure that only your object type is
written to the table, and you cast Objects read from the table back to
your object type before using them.

HTH!

It probably will, after I have digested it.

An alternative might be to prepare the file by scanning it at the
beginning, and noting on what line of the file each entity begins.
Then constructing a 2 x N array, where N is the number of elements.
One column of the array is the ID number, and the other is the line
number on which the entity begins. If I could begin reading at that
line number, I could read the entity very conveniently.

--
Stan Goodman, Qiryat Tiv'on, Israel

Please replace "SPAM-FOILER" with "sgoodman".

200 years of European fecklessness in the face of Arab terror: Tripoli
Pirates (1814); OPEC Oil (1973); Saddam Hussein and Yasser Arafat
(1990 et seq.) -- but actually financing it, and marching in support
of tyranny, are 21st-century craven European wrinkles.
 
B

Brad BARCLAY

Stan said:
I don't, at this stage. Later I would need to operate only on a subset
of the elements, and for each of these make a linked list consisting
of only a few of its lines.

Well, the nice thing about Java is that all non-primitive variables are
actually references to an object. Because of this, there isn't any
reason why you can't construct one of your linked list element objects,
and have it referenced (pointed to) by both an element in your linked
list _and_ within the HashTable. In this way you have the linked list,
but can gain quick access to any single element through the HashTable.
If anyone wonders what this is about, the original file is a GEDCOM
genealogical file, in which the elements are groups of lines (in
general a variable number), each element representing an entity, i.e.
a person or a family.

How much data will the file contain? This might influence your reading
mechanism, as if it's quite large reading it in all at once may not be
ideal.
It probably will, after I have digested it.

An alternative might be to prepare the file by scanning it at the
beginning, and noting on what line of the file each entity begins.
Then constructing a 2 x N array, where N is the number of elements.
One column of the array is the ID number, and the other is the line
number on which the entity begins. If I could begin reading at that
line number, I could read the entity very conveniently.

I probably wouldn't use a 2D array for something like this -- instead,
create an object which encapsulates your two pieces of information (ID
number, line number), and then store those objects in a 1D array.

This gives you some added type safety, and will allow you to code
accessors (getters, setters) for your information. You could probably
even code the object such that it can go to the stored line number and
read its data itself, so you can just call a method on array element 'n'
to handle the input.

Brad BARCLAY
 
B

Brad BARCLAY

Stan said:
The input file can have several thousand entities, meaning nearly 1MB
filesize and maybe 50,000 lines. I think it's better to read it all in
at one time, rather than opening it every time I want to search for an
entity.

With todays systems, that probably isn't so much data that you can't
just read it in all at once. However, your previously proposed system
of just indexing the lines and reading the data as needed may not be a
bad idea either -- that way you're only creating objects for data points
that are actually being accessed, as they're being accessed. Otherwise,
I agree that reading all of this in at once isn't going to be a big deal
(it's probably a lot of geneological data, but for a modern PC it's
pretty insignificant :) ).
Better and better. Many thanks.

No problem.

Brad BARCLAY
 
B

Brad BARCLAY

Stan said:
That's what I think, while accessing the file once per useful
datapoint (many hundreds) seems very clumsy and time-consuming. On the
other hand, if I first store the input file in a RAM disk, things
would go much faster.

I wouldn't bother if the file is being stored on a FAT16, JFS, or
HPFS386 volume with a decent cache size, as the cache will take care of
this for you.

Are you planning on modifying the data file at all, or will this be a
read-only operation?

Brad BARCLAY
 
S

Stan Goodman

I wouldn't bother if the file is being stored on a FAT16, JFS, or
HPFS386 volume with a decent cache size, as the cache will take care of
this for you.

Are you planning on modifying the data file at all, or will this be a
read-only operation?

I won't modify the input file; there will be a separate output file.

--
Stan Goodman, Qiryat Tiv'on, Israel

Please replace "SPAM-FOILER" with "sgoodman".

200 years of European fecklessness in the face of Arab terror: Tripoli
Pirates (1814); OPEC Oil (1973); Saddam Hussein and Yasser Arafat
(1990 et seq.) -- but actually financing it, and marching in support
of tyranny, are 21st-century craven European wrinkles.
 
B

Brad BARCLAY

Stan said:
I won't modify the input file; there will be a separate output file.

Well, in that case I'd say read away -- all at once.

If you need any help or suggestions, please feel free to let me know
(you know how to find me :) ).

Brad BARCLAY
 
S

Stan Goodman

Well, in that case I'd say read away -- all at once.

If you need any help or suggestions, please feel free to let me know
(you know how to find me :) ).

At the same old stand.

Thanks.

--
Stan Goodman, Qiryat Tiv'on, Israel

Please replace "SPAM-FOILER" with "sgoodman".

200 years of European fecklessness in the face of Arab terror: Tripoli
Pirates (1814); OPEC Oil (1973); Saddam Hussein and Yasser Arafat
(1990 et seq.) -- but actually financing it, and marching in support
of tyranny, are 21st-century craven European wrinkles.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top