Re: Adding tabs programaticaly (solved)?
21-Mar-11 16:08, Vyacheslav Karamov пишет:
Hi All!
I'm writing IB 3.2 plug-in for NSTabView descendant.
After adding new tab
CLTabViewItem * item = [[CLTabViewItem alloc] init];
[item setLabel: @"new Item"];
[tabView addTabViewItem: item];
I'm trying to select it and edit is properties. But IB crashes with
error messages.
2011-03-21 15:44:35.899 Interface Builder[2398:a0f] Message:
ibObjectAtLocation: asked to object not in the document
2011-03-21 15:45:23.413 Interface Builder[2398:a0f] Assertion Failure:
[[controller document] containsObject:self]
2011-03-21 15:45:23.414 Interface Builder[2398:a0f] File:
/SourceCache/InterfaceBuilder/InterfaceBuilder-851/Framework/PublicCategories/IBObjectIntegration.m
2011-03-21 15:45:23.414 Interface Builder[2398:a0f] Line: 213
2011-03-21 15:45:23.430 Interface Builder[2398:a0f] Backtrace:
0 InterfaceBuilderKit 0x0011f909
-[NSView(IBViewIntegration) ibObjectAtLocation:inWindowController:] +
1017
1 CocoaPlugin 0x1283b758
IBShouldSubstituteSwapperForObjectInContextOfArchiver + 48132
2 InterfaceBuilderKit 0x0011f848
-[NSView(IBViewIntegration) ibObjectAtLocation:inWindowController:] + 824
3 InterfaceBuilderKit 0x0011e00d
-[NSObject(IBFrameworkObjectIntegration)
ibObjectAtLocation:inWindowController:] + 708
4 InterfaceBuilderKit 0x001b2867
-[IBViewEditorWindowController objectAtPoint:] + 79
5 InterfaceBuilderKit 0x00122c07
-[IBViewEditorWindowController trackMeasurementsWithEvent:atPoint:] + 58
6 InterfaceBuilderKit 0x0011629c
-[IBViewEditorWindowController interceptEvent:] + 289
7 InterfaceBuilderKit 0x00116140 -[IBEditableWindow
sendEvent:] + 70
8 AppKit 0x91a2352b -[NSApplication
sendEvent:] + 5683
9 Interface Builder0x4615
10 AppKit 0x919b72a7 -[NSApplication run] +
917
11 AppKit 0x919af2d9 NSApplicationMain + 574
12 Interface Builder0x22c5
13 Interface Builder0x0003
What I did wrong?
___
Solution wasn't obvious:
@implementation CLTabView (InspectorIntegration)
- (void)addObject:(id)object toParent:(id)parent
{
IBDocument * document = [IBDocument documentForObject:parent];
[document addObject:object toParent:parent];
}
...
@end
@implementation CLTabView
- (void)addTabViewItem:(CLTabViewItem *)tabViewItem
{
[super addTabViewItem: tabViewItem];
[self addObject:tabViewItem toParent:self];
[self addObject:[tabViewItem view] toParent:tabViewItem];
}
...
@end
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Edit NSScrollView text
on XCode version 3 I was able to launch IB and edit the text of a NSScrollView. On XCode 4 I can't. And even if I modify this text, which is saved within the file MainMenu.nib/keyedobjects.nib when I relaunch XCode 4 and open my project file, the change doesn't show up. I always see the old text. Also, I have seen that even creating a new NSScrollView, I can't edit the text. So, my question is, how can I edit the text of a NSScrollView when editing a nib file? I found it very useful, especially to create a license panel. What text of an NSScrollView do you mean? Are you talking about the NSTableHeaderView? There doesn't seem to be any Inspector edit field for its content in the integrated IB 4 (yet). Just double-click the header view's cell and edit the string. Maybe this is a IB4 bug and you may want to file a bug. ---Ulf Dunkel ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: MPMoviePlayerController setContentURL twice
Your code worked! Thanks! The main difference between our snippets
was that you added the MPMoviePlayerController's view directly to the
UIViewController's view rather than putting it in a holder view (which
I doubt would matter) and that you aren't using the embedded controls.
I'll post back when I figure out what went wrong.
-Heath Borders
heath.bord...@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com
On Mon, Mar 21, 2011 at 11:50 PM, Matt Neuburg wrote:
> On Mon, 21 Mar 2011 22:59:04 -0500, Heath Borders
> said:
>>That's exactly what I did. I have a brand new project with just a
>>ViewController with 3 views
>>
>>[SNIP ridiculous quantities of code]
>
> I can't read that. And it isn't what I suggested you do. I said make a
> *minimal* project. Enough to prove to yourself that setting the contentURL
> works. And no more than that! Here's my code; this is what I mean when I say
> "minimal" and "simple" and stuff like that:
>
> - (void)viewDidLoad {
> [super viewDidLoad];
> MPMoviePlayerController *player = [[MPMoviePlayerController alloc] init];
> player.shouldAutoplay = NO;
> player.controlStyle = MPMovieControlStyleNone;
> [player.view setFrame: CGRectMake(0,0,200,150)];
> [self.view addSubview: player.view];
> self.thePlayer = player;
> [player release];
>
> }
> - (IBAction)play1:(id)sender { // button 1
> [self.thePlayer setContentURL: [[NSBundle mainBundle]
> URLForResource:@"blend1" withExtension:@"mp4"]];
> [self.thePlayer play];
> }
>
> - (IBAction)play2:(id)sender { // button 2
> [self.thePlayer setContentURL: [[NSBundle mainBundle]
> URLForResource:@"xbox" withExtension:@"mp4"]];
> [self.thePlayer play];
> }
>
> That's all. It works. So then you build up from there towards what you
> *really* want to do. When it stops working, that's when you broke it. m.
>
>
> --
> matt neuburg, phd = m...@tidbits.com,
Re: MPMoviePlayerController setContentURL twice
I was able to replicate my issue. In my original code, I was only
allowing the movie to be played with the embedded controls. When I
set the contentURL a second time, my embedded controls were not
showing, so I couldn't play the movie again. As I mentioned
previously, Matt's code worked great. However, I can replicate my
issue by removing line 4 below.
1 - (IBAction)play1:(id)sender { // button 1
2 [self.thePlayer setContentURL: [[NSBundle mainBundle]
3URLForResource:@"blend1" withExtension:@"mp4"]];
4[self.thePlayer play];
5 }
I only want to control the movie from the embedded controls, so I
don't want to programmatically play it. In the MPMediaPlayback
protocol, there is a prepareToPlay method, which must always be called
before the movie starts playing, and which is called if needed by
play.
So, replacing line 4 with
[self.thePlayer prepareToPlay];
makes my code work.
Thanks again for your help, Matt!
-Heath Borders
heath.bord...@gmail.com
Twitter: heathborders
http://heath-tech.blogspot.com
On Tue, Mar 22, 2011 at 8:30 AM, Heath Borders wrote:
> Your code worked! Thanks! The main difference between our snippets
> was that you added the MPMoviePlayerController's view directly to the
> UIViewController's view rather than putting it in a holder view (which
> I doubt would matter) and that you aren't using the embedded controls.
> I'll post back when I figure out what went wrong.
>
> -Heath Borders
> heath.bord...@gmail.com
> Twitter: heathborders
> http://heath-tech.blogspot.com
>
>
>
> On Mon, Mar 21, 2011 at 11:50 PM, Matt Neuburg wrote:
>> On Mon, 21 Mar 2011 22:59:04 -0500, Heath Borders
>> said:
>>>That's exactly what I did. I have a brand new project with just a
>>>ViewController with 3 views
>>>
>>>[SNIP ridiculous quantities of code]
>>
>> I can't read that. And it isn't what I suggested you do. I said make a
>> *minimal* project. Enough to prove to yourself that setting the contentURL
>> works. And no more than that! Here's my code; this is what I mean when I say
>> "minimal" and "simple" and stuff like that:
>>
>> - (void)viewDidLoad {
>> [super viewDidLoad];
>> MPMoviePlayerController *player = [[MPMoviePlayerController alloc] init];
>> player.shouldAutoplay = NO;
>> player.controlStyle = MPMovieControlStyleNone;
>> [player.view setFrame: CGRectMake(0,0,200,150)];
>> [self.view addSubview: player.view];
>> self.thePlayer = player;
>> [player release];
>>
>> }
>> - (IBAction)play1:(id)sender { // button 1
>> [self.thePlayer setContentURL: [[NSBundle mainBundle]
>> URLForResource:@"blend1" withExtension:@"mp4"]];
>> [self.thePlayer play];
>> }
>>
>> - (IBAction)play2:(id)sender { // button 2
>> [self.thePlayer setContentURL: [[NSBundle mainBundle]
>> URLForResource:@"xbox" withExtension:@"mp4"]];
>> [self.thePlayer play];
>> }
>>
>> That's all. It works. So then you build up from there towards what you
>> *really* want to do. When it stops working, that's when you broke it. m.
>>
>>
>> --
>> matt neuburg, phd = m...@tidbits.com,
Re: Error reporting in Cocoa (was Re: Exception not being caught)
On Mar 21, 2011, at 10:24 PM, Chris Hanson wrote: > Ultimately, the solution will be to modify HessianKit -- or any other > framework that presents an RPC-style interface[1] -- to follow the Cocoa > convention of returning BOOL (or a non-nil/nil object reference) to indicate > success or failure, and to fill in an NSError passed by reference if the > caller desires additional failure details. > > -- Chris > > [1] Distributed Objects doesn’t work this way - it predates NSError and uses > exceptions, which results in exactly the problems discussed in this thread. > Often DO calls will wind up wrapped in an API that just does a @try/@catch > around the call and returns success/failure, for exactly this reason. Hi Chris, I am curious as to how you would propose to add error: handlers to DO calls considering that DO is meant to transparent and cannot modify method signatures. For example, assuming you were designing a new DO framework, how would you propose changing this: int junk = [secretlyDistantObject calculate:4]; to allow for a socket timeout? Would you then wrap any API which could be potentially called by DO with the additional error: argument? Cheers, M___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Adding tabs programaticaly?
On Tue, Mar 22, 2011 at 1:22 AM, Vyacheslav Karamov wrote: > I have no idea how to do this. http://bugreport.apple.com Also, please post on the Xcode 4 Developer Forums. http://devforums.apple.com --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Error reporting in Cocoa (was Re: Exception not being caught)
On Tue, Mar 22, 2011 at 8:07 AM, A.M. wrote: > I am curious as to how you would propose to add error: handlers to DO calls > considering that DO is meant to transparent and cannot modify method > signatures. For example, assuming you were designing a new DO framework, how > would you propose changing this: > > int junk = [secretlyDistantObject calculate:4]; > > to allow for a socket timeout? Would you then wrap any API which could be > potentially called by DO with the additional error: argument? Good practice probably won't allow "secretly distant" objects to leak into the rest of the app. But that doesn't solve your problem: how does DO report DO errors without modifying message signatures? Exceptions really are the only answer. As long as DO is internally safe with respect to DO exceptions, this is okay. It's when you start introducing foreign exceptions that implementation gets hairy. Rick was attempting to handle exceptions in his client code that were being thrown through HessianKit. Because of Cocoa's attitude towards exceptions, this isn't guaranteed to work. The lack of exception support across a forwarding boundary is a significant change in language behavior that fails to fulfill the language's contract, but fixing it won't actually solve Rick's problem, which is that he's trying to throw exceptions through stack frames he doesn't own. --Kyle Sluder ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableColumn dataCellForRow:
Thank you for the quick reply. Implementing 'tableView:willDisplayCell:forTableColumn:row:' is exactly what I needed. Just want to change cell attributes. I thought the only way to do this was to subclass 'dataCellForRow:', especially since it was 'pointed out' in the documentation. But, this led to too much work (IB and all), for a one line attribute change (and never came out right). Guess I need to review all the delegate protocols. Since I'll be spending plenty of time in tableViews, I need to know every aspect of configuration. Thank you, again. On Mar 22, 2011, at 12:22 AM, Quincey Morris wrote: On Mar 21, 2011, at 16:16, William Weygandt wrote: I need to set attributes for a TableColumn cell, based on its row, leaving the cells of other rows, unchanged. I tried using the method dataCellForRow:. I just can't seem to make this work. Not sure I can subclass this because the delegate will reference this method. Can you ask a more specific question. We've no idea what you've tried and what's failed. We don't know what you mean by "can't seem to make this work". You might want to post some failing code, if you're not sure how to describe the problem. Meantime ... You shouldn't think in terms of subclassing NSTableColumn -- it just makes it too hard to set things up in IB. Instead you should use one or both of the delegate methods 'tableView:dataCellForTableColumn:row:' and 'tableView:willDisplayCell:forTableColumn:row:' (or the parallel variants used by outline views). All you have to do is the keep them straight in your mind. 'tableView:dataCellForTableColumn:row:' is called to obtain a cell to use at a specific row/column position, in case you want to use a different kind of cell (or for some reason just a different cell) from the default provided by the column. At the time this is called, the cell is not being configured yet, just being obtained, so anything you do to it is subject to being undone by NSTableView. 'tableView:willDisplayCell:forTableColumn:row:' is called sometime after that to configure a cell for use, whether the cell was provided by your 'tableView:dataCellForTableColumn:row:' or not. (The "not" case happens when you don't implement that delegate method, or it returns nil.) When this second method is called, the cell has already been configured as far as the table view knows how (e.g. it's set the correct object value), so you can make any further adjustments you need. So, if your table column has a text field cell, you would use the first delegate method (for example) to change to an image cell in certain rows. Or, if a text field cell has been chosen for the row/ column, you would use the second delegate method (for example) to change the color of the text. Or, if you needed to change to an image cell for some rows *and* configure the image being displayed, you'd do that in two steps, using one delegate method for each. Does that help at all? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Reminder: Join me in Pearltrees
___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
(no subject)
On 20/04/2009, at 5:01 PM, Joe Yi wrote: hello all:I have no way to get the app window 's coordinate> 。please show me the detail method. RTFD. [window frame]; --Graham___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
(no subject)
Hi everyone: When I use QTMovie to play movies. I want to custom myself progress slider instead of the NSSlider. How to custom the progress slider? thks! Bright ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
(no subject)
Is the contentsScale property set correctly? For CALayers it defaults to 1.0,
UIKit ensures that it is set correctly for layers that it creates, but it is
your responsibility to do this for layers that you create yourself.
--
David Duncan
On Jul 11, 2010, at 4:03 PM, Carter Allen wrote:
> I am trying to create an app that scales up nicely on the iPhone 4.
> Currently most of it scales up perfectly, except for one crucial
> piece: the text that I draw inside a CALayer, inside its
> drawInContext: method. Here is my code:
>
> - (void)drawInContext:(CGContextRef)context {
> UIGraphicsPushContext(context);
>
> CGContextSetGrayFillColor(context, 1.0f, 1.0f);
> CGContextFillRect(context, self.bounds);
>
> CGContextSetAllowsAntialiasing(context, true);
> CGContextSetShouldAntialias(context, true);
>
> CGContextSetAllowsFontSmoothing(context, true);
> CGContextSetShouldSmoothFonts(context, true);
>
> CGContextSetAllowsFontSubpixelQuantization(context, true);
> CGContextSetShouldSubpixelQuantizeFonts(context, true);
>
> CGContextTranslateCTM(context, 0.0f, self.frame.size.height);
> CGContextScaleCTM(context, 1.0f, -1.0f);
>
> CGContextSetFillColorWithColor(context, [[UIColor blackColor] CGColor]);
> CGContextSelectFont(context, "CardKit", 30.0f, kCGEncodingMacRoman);
> CGContextSetTextDrawingMode(context, kCGTextFill);
> CGContextShowText(context, "A", sizeof("A"));
>
> UIGraphicsPopContext();
> }
>
> This short produce crisp text on both devices, but unfortunately, it
> produces blurry text on both. Here is how it appears:
> http://zcr.me/01h
> That image is taken at 100% zoom on the iPhone 4. What in the world?
> Any ideas how I can fix this?
>
> Sincerely,
> Carter Allen
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com
>
> This email sent to david.dun...@apple.com
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSClassDescriptionNeededForClassNotification
Hi,
I have never use it, and never look into this. Maybe a class method instead.
Op 21 mrt 2011, om 09:45 heeft Kevin Bracey het volgende geschreven:
> Hi there,
>
> I hope that I could "register class descriptions lazily", I like doing most
> things lazily.
>
> But I can't find where or how to listen for the
> NSClassDescriptionNeededForClassNotification.
>
> I've place [[NSNotificationCenter defaultCenter] addObserver:self
> selector:@selector( registerClassDescription: )
> name:NSClassDescriptionNeededForClassNotification object:nil]; in either my
> AppDelegate and my model object.
>
> It just doesn't seem to fire when classDescriptionForClass: does not find a
> class.
>
> I have fired it manually with [[NSNotificationCenter defaultCenter]
> postNotificationName:NSClassDescriptionNeededForClassNotification
> object:self]; and my
> - (void)registerClassDescription:( NSNotification *)aNotification
> {
> NSLog(@"Looking for Notification" );
> }
>
> logs fine.
>
> Can any shed some light on where and how to get notified of
> NSClassDescriptionNeededForClassNotification?
>
> cheers
> Kevin___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/appledev%40xs4all.nl
>
> This email sent to apple...@xs4all.nl
>
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: (no subject)
Subclass NSSliderCell and override the appropriate methods: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSSliderCell_Class/Reference/Reference.html Then change the cell type of you NSSlider to your custom subclass. Cheers, Dave On May 7, 2009, at 11:43 PM, Bright wrote: > Hi everyone: > When I use QTMovie to play movies. I want to custom myself progress slider > instead of the NSSlider. > How to custom the progress slider? > thks! > Bright ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
design question
Hi,
can someone look at and say is a returning of immutable objects necessary or
no?
@interface XMLElement : NSObject {
NSString *_name;
NSMutableString *_text;
NSMutableDictionary *_attributes;
NSMutableArray *_children;
XMLElement *_parent;
}
@implementation XMLElement
- (NSArray *) elementsForName: (NSString *) name {
NSMutableArray *children = [NSMutableArray new];
for (XMLElement *element in _children)
if ([[element name] isEqualToString: name])
[children addObject: element];
NSArray *lchildren = [children copy];
[children release];
return [lchildren autorelease];
}
- (void) setChildren: (NSArray *) children {
[_children release];
_children = [children mutableCopy];
}
- (NSArray *) children {
return [[_children copy] autorelease];
}
- (NSString *) XMLString {
return [[[self _XMLString] copy] autorelease];
}
//
@end
--
best regards
Ariel
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Changing tooltips in a custom view
I've got a sample project at: http://ericgorr.net/cocoadev/tooltip.zip What I would like to do is define a single tooltip rect for an entire view but be able to change the tooltip as the cursor moves inside of the view. Is there a way to do that? Is there a way to force it to hide the current tooltip and display a new one while calling view:stringForToolTip:point:userData:? I could create my own window that simulates a real tooltip, but wanted to make sure there was nothing built-in that would support this. thank you. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: design question
On 23/03/2011, at 6:29 AM, Ariel Feinerman wrote:
> Hi,
>
> can someone look at and say is a returning of immutable objects necessary or
> no?
>
> @interface XMLElement : NSObject {
>
>
> NSString *_name;
>
> NSMutableString *_text;
>
> NSMutableDictionary *_attributes;
>
> NSMutableArray *_children;
>
> XMLElement *_parent;
>
> }
>
> @implementation XMLElement
[]
> - (NSArray *) children {
>
> return [[_children copy] autorelease];
>
> }
No, but neither is performing all this excessive copying.
For example your -children method can simply be:
- (NSArray*) children
{
return _children;
}
That's because a) NSMutableArray IS a NSArray, and b) your method has told its
clients it is returning an NSArray, so the client has no right to go any
further than the methods of NSArray with that object, that is, it cannot make
use of knowledge it doesn't have to treat it as mutable. If you want the client
to know that the array really is mutable, your return type should say so.
The only issue is whether having returned the array, its contents could mutate
while someone else is retaining it. But if the client is holding onto it that
long (in a synchronous situation) its contents won't reflect the reality of the
content of the object it got it from in any case. Alternatively, once the tree
is built from the XML document, why would the structure change? If you're
writing an editor, the structure will change, but in that case you probably
won't have a case where a stale copy of 'children' is cached anywhere. In all
the typical cases, the copy is likely redundant. If a client knows that it will
be holding on to the array for "a long time", and that it got it from an object
whose contents are probably dynamic (according to this very common pattern)
then it can make a copy itself if it needs to. It is in a better position than
the vending object to know whether the copy is needed or not (which is why most
copying that is done is implemented by an object setter, not in a getter).
On the other hand whether to copy or not is really a (usually minor)
performance issue rather than anything more fundamental, so worrying about it
now is unlikely to be worthwhile. However I think that paranoia leading to
copying everything everywhere indicates a basic lack of understanding about the
design you're implementing. By habit and reflex, not copying is the norm, and
copying should only be done when it is understood that it is truly necessary.
Doing it "just in case" is pointless.
By the way if you're building an XML tree (presumably from running NSXMLParser)
perhaps the NSXMLNode family of objects would be a better choice. If you are
writing a streaming parser where the elements are short-lived, I wouldn't
expect the element lifetimes to be very long - there are unlikely to be clients
that will hold your 'children' array beyond the existence of those children. I
just wrote an XML parser like this myself - each parent element maintains a
stack of children which are pushed and popped as each child element comes into
being, gets processed and then is finished with. Thus the 'children' array
(really a stack) is quite dynamic, and usually rather short. The only object
that really cares about that stack is the object holding it, so while I do have
a method for returning that array, it doesn't perform a copy, and that hasn't
caused any problems (in fact, I couldn't swear it's ever used, but it's a
habit to provide accessors for private container ivars in the base class for
the implementing object - you never know when someone will want it).
To harp on this point about copying:
> - (NSArray *) elementsForName: (NSString *) name {
>
> NSMutableArray *children = [NSMutableArray new];
>
> for (XMLElement *element in _children)
>
> if ([[element name] isEqualToString: name])
>
> [children addObject: element];
>
> NSArray *lchildren = [children copy];
>
> [children release];
>
> return [lchildren autorelease];
>
> }
Why do you build an array in perfect isolation, then copy it before returning
it? The array you just built is not used anywhere else and as soon as it's
copied it is released and deallocated. The copy is just a waste of time - you
are perfectly within your contract with your clients to simply return the
mutable array.
--Graham
___
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: design question
On Mar 22, 2011, at 16:53, Graham Cox wrote: > That's because a) NSMutableArray IS a NSArray, and b) your method has told > its clients it is returning an NSArray, so the client has no right to go any > further than the methods of NSArray with that object, that is, it cannot make > use of knowledge it doesn't have to treat it as mutable. If you want the > client to know that the array really is mutable, your return type should say > so. I agree with this part. The client would have to examine the class at runtime to find out it was mutable, and that would be a bug. > The only issue is whether having returned the array, its contents could > mutate while someone else is retaining it. But if the client is holding onto > it that long (in a synchronous situation) its contents won't reflect the > reality of the content of the object it got it from in any case. > Alternatively, once the tree is built from the XML document, why would the > structure change? If you're writing an editor, the structure will change, but > in that case you probably won't have a case where a stale copy of 'children' > is cached anywhere. In all the typical cases, the copy is likely redundant. > If a client knows that it will be holding on to the array for "a long time", > and that it got it from an object whose contents are probably dynamic > (according to this very common pattern) then it can make a copy itself if it > needs to. It is in a better position than the vending object to know whether > the copy is needed or not (which is why most copying that is done is > implemented by an object setter, not in a getter). > > On the other hand whether to copy or not is really a (usually minor) > performance issue rather than anything more fundamental, so worrying about it > now is unlikely to be worthwhile. However I think that paranoia leading to > copying everything everywhere indicates a basic lack of understanding about > the design you're implementing. By habit and reflex, not copying is the > norm, and copying should only be done when it is understood that it is truly > necessary. Doing it "just in case" is pointless. I disagree with you on this part. It's slightly more complex than that. There are 2 basic *semantic* possibilities: 1. This method is the implementation of a property (whether or not it's an @property isn't important). 2. This method is just a method. If #2, there's nothing to be discussed. The behavior of the return value is a matter for the API contract for that method, and there's no general rule. Often, though, #2 isn't the intended meaning for a method that takes no parameters and returns a value. If #1, then there's a second pair of more interesting possibilities: 1a. The property is an attribute. 1b. The property is a to-many relationship. If #1a, then the return value should be unchangeable, in the sense that it should never change after being returned (regardless of whether the returned object is of a mutable class or not). That means, if an existing mutable array is the desired return value, which the owning class might mutate later, a copy *must* be returned instead. If #1b, then the return value should be assumed to be changeable, in the sense that it could change any time after being returned. (Again, the return value's class's mutability is irrelevant.) *Semantically, what's being returned is a "proxy" for the relationship*, not an array. In this case, the return type merely indicates whether the caller can mutate the relationship via the "proxy" or not. In practice, it works in reverse. If the method returns something unchangeable, the property is regarded as an attribute. If it returns something changeable, the property is regarded as a to-many relationship. This is consistent with Core Data properties, and keeping the distinction clear keeps the API design honest and helps write correct code -- it makes it easy to decide whether to return a copy of the underlying array or not. Your discussion about "how long" and "why" has different answers depending on which of the two kinds of properties is involved. The pitfall here is that if the property is intended to be a snapshot of the state of a relationship (an attribute, as opposed to the actual relationship), returning the underlying mutable array without copying is a bug, even if the return type is NSArray. ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: design question
On 23/03/2011, at 11:58 AM, Quincey Morris wrote: > 1b. The property is a to-many relationship. > > If #1a, then the return value should be unchangeable, in the sense that it > should never change after being returned (regardless of whether the returned > object is of a mutable class or not). That means, if an existing mutable > array is the desired return value, which the owning class might mutate later, > a copy *must* be returned instead. > > If #1b, then the return value should be assumed to be changeable, in the > sense that it could change any time after being returned. (Again, the return > value's class's mutability is irrelevant.) *Semantically, what's being > returned is a "proxy" for the relationship*, not an array. In this case, the > return type merely indicates whether the caller can mutate the relationship > via the "proxy" or not. > > In practice, it works in reverse. If the method returns something > unchangeable, the property is regarded as an attribute. If it returns > something changeable, the property is regarded as a to-many relationship. > > This is consistent with Core Data properties, and keeping the distinction > clear keeps the API design honest and helps write correct code -- it makes it > easy to decide whether to return a copy of the underlying array or not. > > Your discussion about "how long" and "why" has different answers depending on > which of the two kinds of properties is involved. The pitfall here is that if > the property is intended to be a snapshot of the state of a relationship (an > attribute, as opposed to the actual relationship), returning the underlying > mutable array without copying is a bug, even if the return type is NSArray. Right, and I agree. You've expressed it better than I did, sometimes it's hard to convey in writing something that you have only understood at some intuitive level. So this helps clarify something I hadn't made entirely clear in my own mind. The situation is #1b. And you know this, because you have more information than just a return type - you have the name of the method, -children. This pretty much tells you that you're dealing with a to-many relationship. If it doesn't, you've named it badly. Thus, a client can and should expect it to change, and so, if it actually wants a snapshot, it should perform the copy, but if not, it shouldn't cache it. Either way, in my view the onus is on the client as to whether to perform the copy - the vending object doesn't know what the client is going to use it for, so whether to copy it or not is not something it can know, so it should do the simplest thing (an instance of Occam's Razor?) which is, not copy. In practice, you rarely run into problems with this approach. I know everyone will have their favourite counter-examples, but that's why I say 'rarely', not 'never'. --Graham ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSOperation with unit test
Hi, I am trying to write a unit test for a class that inherits from NSOperation. And I've implemented this class just as I did in my application (which works) and the test case is running, but when the 'addOperation:myClass' on the NSOperationQueue is called within the test method, I don't see that my NSOperation class is being executed. Is there something different about running NSOperations within a unit test? ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSOperation with unit test
Your NSOperation is probably running on a background thread managed by the NSOperationQueue. Your test needs to wait until the NSOperationQueue has processed all its tasks. -Heath Borders heath.bord...@gmail.com Twitter: heathborders http://heath-tech.blogspot.com On Tue, Mar 22, 2011 at 10:35 PM, Shane wrote: > Hi, > > I am trying to write a unit test for a class that inherits from > NSOperation. And I've implemented this class just as I did in my > application (which works) and the test case is running, but when the > 'addOperation:myClass' on the NSOperationQueue is called within the > test method, I don't see that my NSOperation class is being executed. > > Is there something different about running NSOperations within a unit test? > ___ > > 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: > http://lists.apple.com/mailman/options/cocoa-dev/heath.borders%40gmail.com > > This email sent to heath.bord...@gmail.com > ___ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
