On 12 Mar 2013, at 21:25, Graham Cox wrote:
On 13/03/2013, at 2:41 AM, Dave <d...@looktowindward.com> wrote:
So, what is it? Wind up merchant or Moron?
I don't think there's any need for this. If I caused offence, it
was unintended (I sometimes have trouble anticipating how others
might receive statements I make, that's just something I have to
live with).
The further discussion doesn't really convince me that you've
really understood it, but if you have, great. Personally I have no
stake in whether you succeed or not, so if you choose to ignore
advice or insult the adviser, it makes no difference to me.
Look, you made a number of silly and wild comments, all I did was to
ask you do back them up. Perhaps I could have been kinder, but to be
honest, from your comments it showed you didn't even bother to read
the original post and the code contained therein, so again:
@interface BaseClass
+(NSMutableDictionary*) newDict;
@end
@implementation BaseClass
+(NSMutableDictionary*) newDict
{
return [[NSMutableDictionary alloc] init];
}
@class NewClass;
@interface NewClass : BaseClass
+(NSMutableDictionary*) newDict;
@end
#import "BaseClass.h"
@implementation NewClass
+(NSMutableDictionary*) newDict
{
NSMutableDictionary* myDict;
myDict = [[super class] newDict];
//********** bug
[myDict setObject:@"Some Data" forKey:@"someKey"];
return myDict;
}
You said of this code:
Why not state you goals instead of give us a lump of incoherent code?
How is the above code incoherent? The text from that email:
I had assumed (and I thought I'd done something like this before)
that the:
myDict = [[super class] newDict];
statement would call newDict in BaseClass???? Instead it calls the
version in NewClass and goes into an infinite loop!!
How is this not stating my goals?
The attempts you made show a clear lack of understanding about
inheritance, which is what others were trying to tell you.
In what way does the above code show a "clear lack of understanding
about inheritance" ? To me and many others on this list, it just
showed a typeo/bug in one line of newly added code.
Then you post some other code, that was slower and didn't even do the
same job! Then you argued that it did do the same job and made light
of the fact that is was slower and even questioned the fact that it
might be slower. From that I could have said "the attempts you made,
showed a clear lack of understanding abut memory management and how
container objects work in Cocoa".
The fact of the matter is that allocating a read-only array and then
copying it's contents into a mutable array is slower, but worse than
this, doesn't do the same thing at all. When I pointed out how it's
different, you went quiet and then had a "go" about something else!
The latest post really takes the cake though:
In general you shouldn't return a retained object (unless it's
temporarily retained and will be autoreleased of course). If you
are routinely doing this then your design is flawed. The reason
it's hard to signal to the compiler that you're returning a
retained object is that you shouldn't be doing it. When you have to
do it, use the word 'new' in the method.
According to you, many, many Apps have "design flaws" because they
contain methods that return retained objects! What a croc! rofl!
So, lets explore this stupidity a little! This is the Non-ARC case,
obviously. I need to create an Object that has a different class type
than the class I am working in. I want to retain the object locally
in the current method. Normally I would write
-(Obj*) newObject
{
Obj* myObj;
myObj = [[Obj alloc] init];
// setup some fields in myObj
return myObj;
}
// Calling method:
Obj* myObj;
myObj = [self newObj];
////// use myObj
[myObj release];
You are saying that this is a flawed design? Worse than that, you
seem to be saying that:
-(Obj*) getObject
{
Obj* myObj;
myObj = [[Obj alloc] init];
// setup some fields in myObj
return [myOb autorelease]j;
}
// Calling method:
Obj* myObj;
myObj = [self getObject];
[myObj retain];
////// use myObj
[myObj release];
Is a better design? Is this really what you are saying? Because if it
is, I don't care about what any rule says. the second example is
Flawed over the first for obvious reasons. If you really do think
this, then justify it and I don't mean point me to some Apple Doc of
rules that was written years ago and has no real relevance to the
real world. Tell me in technical terms why example 2 is better than
example 1 or come up with a better way altogether.
So far AFAIAC you have been wrong on most of what you have said. I've
pointed out the reasons why I think you are wrong but you just ignore
them and pick on something else to be wrong about.
If you don' justify your reasoning, then regardless of your
intention, it just comes across as a wind-up, which is fun for a
while but, enough is enough, so come on, either put up or shut up!
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
