On 12 Mar 2013, at 16:44, John McCall wrote:
There is exactly one difference between [[self superclass] newDict]
and [super newDict] here: the value of 'self'. (This assumes the
obvious behavior for +superclass, of course.)
[[self superclass] newDict] is exactly equivalent to [Subclass1
newDict].
[super newDict] calls the same method as [Subclass1 newDict], but
using a 'self' value that is still the Subclass1 class.
Now, if everything is implemented the way you've quoted it, the
value of 'self' doesn't matter, because +[Subclass1 newDict] just
passes it on to +[BaseClass newDict], and +[BaseClass newDict]
ignores 'self'.
However, that wouldn't be an idiomatic implementation. The usual
expectation is that allocating methods, like +new methods,
construct an object *of type self* (at least). For example,
NSObject has a +new method that looks like this:
+ (id) new {
return [[self alloc] init];
}
This way, subclasses don't have to reimplement +new in order to
make it work: [NSWindow new] eventually does an [[NSWindow alloc]
init], just like you'd expect.
This is why I was talking about instance methods and fields:
because, generally, people introduce new classes because they
expect to create instances of them, and [[self superclass] newDict]
bypasses that in a way that might not be obvious.
What you're doing is introducing a ton of classes in order to
create a delegation hierarchy of factory methods. It's probably
the most wasteful way of achieving this goal that I can see
Firstly, I didn't create it, it was already there and I had/have to
make it work faster since it is/was too slow. There was no time to
rewrite it, and, even if there was, I really can't see a better way,
there may be different ways, but I can't see that they would be
substantially better.
This class I am working can receive data from the following sources:
An Object of the same Class.
PList Raw Data String.
Dictionary.
Network
PList file.
Core Data.
SQLite Database.
Other Data File.
This source is turned into Objective-C Objects using data created in
the Class Chain, then Cached and later if necessary used to create
the Object. The basic mechanism was already there, all I've done is
to make it quicker by caching info so that it doesn't need to be
regenerated each time an object is created. The .m file for each of
the classes in the chain have specialist *instance* methods that are
used during the object life cycle. The things that threw me I think
was that I did two things at once, I changed the caching code and
also added two more classes to the chain. The problem was in the
newly added Classes, not in the caching code and was just the
difference between [super xxx] and [[super class] xxx], a simple bug
to fix once I realized what the problem was.
Another way to do it would be to define each Class to contain all the
fields contained in the chain, but this would mean that there would
loads more classes and lots of duplication of code. At present there
are around 50 such classes, if I were to Flatten them, there would
probably be 200+.
I thought the initial design was quite good, it was just a slow,
fairly dumb implementation, this makes it a lot faster which is a
good and fixes the immediate problem. If I thought this was really
"probably the most wasteful way of achieving this goal that I can
see", I could and would ask for time to fix it. But I can't see a
substantially better way of doing it or why you think this way of
doing it is wasteful? Wasteful in terms of what? Code Size? Execution
Time (bearing in mind it is done one, the class chaining I mean and
instances allocated many times). I can't think of anything that is
excessively wasteful and it's very flexible.
If you can of better, less wasteful way then please do let me know
and I will look at your suggestions.
— why not just use functions or something? — but you're certainly
welcome to it.
I'm not sure how "functions" would help me achieve anything given the
above?
Just understand that most people, reading code like +[FooDictionary
newDict], would reasonably assume that this actually creates an
instance of FooDictionary.
But that is NOT how the code looks, which can be seen from my
original post, it looks like this:
Class myClass = [someClass class];
NSDictionary myDict;
myDict = [myClass newDict];
Why would you think newDict returned a myClass object?
If you saw:
Class myClass = [NSDictionary class];
SomeObject* myObj;
myObj = [myClass newObj];
Would you think that newObj was returning an NSDictionary?
If so, why?
All the Best
Dave
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
