Re: Should I retain a variable returned from this accessor?
Re: Should I retain a variable returned from this accessor?
- Subject: Re: Should I retain a variable returned from this accessor?
- From: "mm w" <email@hidden>
- Date: Wed, 13 Aug 2008 09:45:57 -0700
no as far as possible, you shouldn't retain an accessor, you are not
the owner of this accessor
the accessor is owned by an the his object, you are the owner
of an instance of one object when you create it
for an example
myobject {
private dict;
}
string title();
...
string title() {
return dict['title'];
}
obj = new myobject();
obj->title();
it's a non-sense if you retain and release it, in certain case you
could copy an accessor returned value
this is not a particular cocoa thing
Cheers!
On Tue, Aug 12, 2008 at 2:01 PM, has <email@hidden> wrote:
> Peter N Lewis wrote:
>
>> I'm no Cocoa expert, but I think you're wrong on this, you've missed
>> out a crucial line:
>>
>> At 3:12 PM -0400 11/8/08, Sean DeNigris wrote:
>>>
>>> // Get uid to return
>>> NSString* todoUid = [newTodo uid];
>>>
>>> // Clean up
>>> [newTodo release];
>>> newTodo = nil;
>>>
>>> return todoUid;
>>
>> [newTodo release] is not [newTodo autorelease]. So it may
>> immediately call dealloc and dealloc the uid returned by by [newTodo
>> uid].
>
> I don't think so.
>
> The problem here is that you're thinking about Scripting Bridge in
> conventional Cocoa/proxy object terms. This is understandable given that
> this is the illusion that the SB API is intended to create. *However*, the
> thing to realise about Apple event IPC is that it's *RPC plus queries* (a
> very un-Cocoa-like beast), and what SB does is plaster over this mechanism
> with a load of obfuscations in a well-meaning (but misguided) attempt to
> make it look and feel like regular Cocoa (which it isn't, and never will
> be).
>
> For example, the whole:
>
> iCalTodo* newTodo = [[[iCal classForScriptingClass:@"todo"] alloc] init];
> [[myCalendar todos] addObject:newTodo];
> [newTodo release];
>
> rigmarole is just a bunch of pseudo Cocoa-isms on top of a standard 'make'
> Apple event, which in AppleScript would appear as:
>
> tell application "iCal" to make new todo at end of todos
>
> and in objc-appscript - which, unlike SB, is bluntly honest about what's
> going on beneath - as:
>
> ICCommand *cmd = [[[iCal make]
> new: [ICConstant todo]];
> at: [[ICApp todos] end]];
> id result = [cmd send];
>
> (I'll spare you the equivalent C though as we'd be here all day.)
>
> Basically, all that SB is doing in that first line is creating a temporary
> SB object representing an application object that doesn't actually exist
> yet. This SB object contains one or more values that will be used as
> parameters to a 'make' event that will be sent later. (The one parameter
> that's always required is 'new'; others may be optional or required
> depending on the application implementation, type of object being created,
> etc.)
>
> As soon as you pass this object to -addObject:, a 'make' event containing
> those parameters is sent off to the target application to handle. Once
> that's done, your original temporary object no longer has any real part to
> play; unlike Distributed Objects, there is no permanent two-way connection
> where a local object acts as the official proxy for a remote object as long
> as both objects remain live.
>
>
> The fact that you can subsequently refer to this temporary object to set and
> get properties belonging to iCal's newly created todo object is kinda
> incidental. All that's happening here is that SB is stuffing the object
> specifier (i.e. query) returned by the 'make' command into your SB object,
> and subsequently accessing that object's properties is sending fresh
> 'get'/'set' events to the application with that object specifier as their
> direct parameter.
>
> However, even this aspect of SB's behaviour is misleading; for example, some
> applications may not return a result for the 'make' event (in which case
> you'll be talking to air), and many that do will return a by-index or
> by-name reference that is not guaranteed to identify the same application
> object the next time you want to talk to it. Also bear in mind that setting
> properties after -addObject: is called is not the same as setting them as
> part of the 'make' event; for example, read-only properties can often have
> values assigned at the time the object is created, but can't be set
> afterwards.
>
>
> As for memory management of the NSString returned by [newTodo uid], remember
> that it's the product of a 'get' event sent to the target application, and
> not something that belongs to or held in an ivar of the SB object that
> returned it. All SB does is add the NSString to the current autorelease pool
> before returning it, so once that pool is dealloced the NSString will be
> disposed of as well unless you -retain it beforehand.
>
>
> Anyway, hope that's of some use, though personally if I were the OP I'd see
> about using Leopard's new Calendar Store framework instead, thereby avoiding
> the need to muck about with Apple event IPC at all. Users will also
> appreciate it, since it means that other applications won't be magically
> launching while they're running yours.
>
> HTH
>
> has
>
> --
> Control AppleScriptable applications from Python, Ruby and ObjC:
> http://appscript.sourceforge.net
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
>
--
-mmw
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden