Re: object instance names generated on the fly?
Re: object instance names generated on the fly?
- Subject: Re: object instance names generated on the fly?
- From: Ben Dougall <email@hidden>
- Date: Fri, 21 Mar 2003 22:03:16 +0000
I think the answer is no, but I'm having a bit of trouble
understanding what
you are after. You'll get a better answer if the question is, can I
access
an instance of my object based on something that the program will
provide at
runtime? The answer to that one is yes.
well yes access, but more importantly initiate.
As John said, you can instantiate as many objects as you want and put
them
in an array. When you want a particular one, you can get to it by
index
number, e.g.
well, maybe this is the answer. i should probably just go and learn
obj-c/cocoa properly first.
this answer, arrays, certainly doesn't fit in with how i have
visualised what i want to do, but maybe it is the way to do it.
i had just typed, and now deleted, what i thought was wrong with
arrays, but thinking about it maybe it will do it. what i'm not so keen
about the array thing is that for it to work in conjunction with what i
want, it would have to be one single big continually growing array.
where as the way i visualised what i want to do was very split up into
lots of little bits.
obviously with an array, a muteable one, you can add to it infinitely
(well, within reason) - you can keep adding to it, that's the important
bit. grows as required. the one big array does fly in the face of the
idea i want to implement though - it goes against it. (in a logical
way, for me).
it's just that in all the obj-c/cocoa stuff i've read so far (which
isn't that much), when talking about initiating an object instance,
it's set in stone what that instance will be called and that you're
going to get that one instance. if you want another instance you do the
same again with a different name. so this is hard wired - written into
the code. in my thing, i don't know how many instances i'll require -
it completely depends on what happens while the app is running.
but an array can be manipulated on the fly, and the array indexing
could be looked at as part of each object instance's name (the object
instances in the array) so an array would seem to do it. i guess you
can have multidimensional arrays, so arrays can be stored in the array
(i'm looking for the objects in question to create new myObject
instances themselves.. but forget that, that's further confusion). hmm,
this is going to become one large, unwieldy array though - and that's
the problem i've got with the array solution - it would have to remain
*1* main array. the whole deal of oop is that things get split up into
manageable little units. the array solution forces me to go back to
thinking in one big thing again - counter oo. and having to think of it
as one large thing makes my head spin - it makes it unmanageable for me
basically. it doesn't fit the idea, but maybe i've just got to try and
paper over that fact and view it differently. technically an array
would seem to do it from what little i know. so maybe this is the
solution.
shall i just actually say what i want to do? :) - i'll try and be short
and simple (this isn't the full picture but it'll hopefully explain
what i'm trying to do with regards to why i want variable object
instance names) :
user inputs some info (into my app). my app deals with this info as it
comes in, to start with by splitting it up and wrapping each split part
in an instance of myObject. each myObject instance exists for it's
piece of info. so before the user inputs any info, no myObject
instances at all. the object instances start processing their info -
the info they contain and the other myObject instance's info. later,
user inputs more info, this time a larger chunk, say. again the info
gets split up (just more splits this time because it's a larger block
of info) and wrapped in myObject instances. the fresh myObject
instances start processing their info, also mingling with the already
existing myObject instances that were there from the first block of
info input by the user. and this is an ongoing, potentially never
ending process - accumulative. the user, over time, adds info. and if
an array was used, it would have to be *an* array, otherwise you'd need
variable object instance names for the array*s*. and if i had worked
out how to do variable object instance names, i wouldn't be using an
array or arrays in the first place. i'd be using just objects on their
own, not contained in an array. maybe one single large array isn't such
a problem technically. it is a problem for this idea though - conflicts
with it.
another person suggested, well 2 suggestions - create source code and
compile on the fly and the other suggestion was something to do with an
NSDictionary but i don't know anything about that (my fault completely)
- maybe something to look into. the compile on the fly idea would allow
variable object instance names, but it was suggested that this was a
smart-ass option :) - but it isn't counter oop whereas the array
version, i think, is.
sorry if that was a bit too long. i'd tried to keep it short but it's
complicated. well, it is to me.
thanks :) ben
int x;
NSMutableArray *things = [NSMutableArray array];
for(x=0; x<1000;x++)
{
YourObject *you = [[[YourObject alloc] init] autorelease];
[things addObject:you];
}
YourObject *theFiftiethThing = [things objectAtIndex:50];
Or, you can put your objects in a dictionary with keys that you create
programmatically, like so:
int x;
NSMutableDictionary *things = [NSMutableDictionary dictionary];
for(x=0; x<1000;x++)
{
YourObject *you = [[[YourObject alloc] init] autorelease];
NSString *key = [NSString stringWithFormat:@"Object Number %d", x];
[things setObject:you forKey:key];
}
YourObject *theFiftiethThing = [things objectForKey:@"Object Number
50"];
The idea here is that the key string could be anything: text from a
text
field, the result of a calculation, etc.
If neither of these suits your needs, maybe you can explain why.
Jonathan
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.