Re: Radix Class
Re: Radix Class
- Subject: Re: Radix Class
- From: Jordan Evans <email@hidden>
- Date: Mon, 9 Jan 2006 23:24:09 -0800 (PST)
--- Alberto Ricart <email@hidden> wrote:
> 1) It is very weird to see struct's used in OO.
> You should create another object to represent your
> RadixSet. If you
> make the instance variables public, then from within
> your code you
> can do foo->something to access them. True OO would
> not do this (as
> you are breaking encapsulation), and would instead
> call accessor
> methods. Unless you are writing high-performance
> code that requires
> the optimization.
I made the struct so the class was more stand alone.
One benefit is the loss of overhead through messaging.
But I"m not sure if this is really happened. I
haven'd done a performance test. I'll definitely set
one of up in the near future.
> 2) It seems that you are caching values like the
> count (numOfSets)
> that are managed (or should be managed in a
> collection, so you don't
> keep track of that kind of stuff, as the collection
> would do it for
> you). I would rewrite to use the collections more
> fully.
I wrote it that way at first, but I found using a
value returned from a message as a condition in a loop
created unneccessary message overhead. Each time the
loop increments the message is called just to get a
value that could be cached.
> 3) #2 is even stronger when you realize that you are
> given an array
> (so you use a collection to pass them around, but
> then revert to
> unroll it into your own data structure. Why?
I'm not sure I see unrolling of data, except in the
case of the struct being assinged values that are
queried form NSArrays. Again, those values I think
are better cached rather than messaged each time. The
element is my struct is just a highlighted object in
an NSArray, but NSArray has no function to mark a
given object, so element provides a service in the
struct, NSArray can't provide. I'd like to think of
these structs used as a data extension of NSArray,
although some data is mere cached copies.
> 4) You would probably never reInitWithXXX, instead
> you simply alloc
> and init a new Radix. If you are doing object
> pooling, then the
> correct thing to do is to have a setter method like
> setArrayOfSets:
> (NSArray*) to assign a new collection to your
> object.
I thought about this. I was thinking in terms of
immutabiity and mutability and couldn't classify Radix
that way. I sure wish something would break through
that would make me see it. I put in -reInitWith: in
the case when the old source initialized in Radix was
no longer neccessary, but a new source needed Radix's
special abilities.
The old source isn't owned by Radix, rather it has an
aquaintance with no memory ties (just data
connections). If the aquaintance is neccessary, and a
new source comes on to the scene, it's more than an
aquaitance and it's aquaintance should not be ended
with reInitWith. In the case of a strong aquaintance,
a new Radix should then be created.
I'm not sure what pooling means in the context you
used it, so I can't comment.
> 5) zeroElements would be clear or something like
> this. If you
> delegate the set management to an NSArray, you
> simply remove all
> objects and be done, this would also remove many of
> the malloc/frees
I'm not so sure this would be optimal for this class
that may need to perform very quickly as sensitive
times, but I may have misinterpreted what you have
meant.
I'm new to this, so please point out where I may have
gone wrong.
Thanks for your input Alberto.
__________________________________________
Yahoo! DSL Something to write home about.
Just $16.99/mo. or less.
dsl.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden