Re: Problem with setAttributesOfItemAtPath:error:
Make sure you use the do-not-traverse-symbolic-links form when constructing your FSRef for the FSSetCatalogInfo call. I do remember having to do that call in similar circumstances, which is why I was going to try FSCopyObjectAsync to see if that would solve all those issues as well as get in-progress status, but I held off until that APIs memory leaks were fixed (which became bad when copying a few thousand files), and it was fixed in 10.6.7 (it was present in all of 10.6 up to 10.6.6). - Gary L. Wade (Sent from my iPad) On Mar 23, 2011, at 11:14 PM, Laurent Daudelin wrote: > On Mar 23, 2011, at 19:49, Ken Thomases wrote: > >> On Mar 23, 2011, at 7:37 PM, Laurent Daudelin wrote: >> >>> I actually looked at FSMegaInfo but when I built it, I realized that it was >>> using a lot of deprecated functions in 10.6 so I decided against using any >>> part of it because of the amount of work that would be required to rewrite >>> some parts of it. >> >> First of all, deprecated doesn't mean "not available". Second, the disk >> image I have (maybe from some time ago) has a pre-built binary. >> >> >>> And yes, I do understand that different file systems will have different >>> attributes. But, I'm sharing that remote volume from an Intel iMac running >>> 10.5.8, connected to it through AFP. Shouldn't AFP supports basic file >>> attributes? >> >> Depends on what you mean by "basic". I don't recall you saying which >> attributes you were trying to set when you got errors. >> >> Regards, >> Ken >> > > The first problem I'm having is that "copyItemAtPath:toPath:error:" behaves > erratically when using it to copy the content of a folder to another folder > that resides on a remote volume accessed through AFP, with full permissions > for the folder where I copy the items. In the folder I copy, *all* the > subfolders get their modification dates set correctly by > "copyItemAtPath:toPath:error:". Now, *most* of the files that are directly in > the folder I copy have their creation dates missing and the modification > dates set to the time of the copy, e.g. NSFileManager doesn't seem to be able > to set those dates properly and will not call > "fileManager:shouldProceedAfterError:copyingItemAtPath:toPath:" nor will it > return an NSError to explain the problem, when that happens. Right there, > that's not good. Then, I did observe that all subfolders have their > modification dates set correctly but most of the files in those subfolders > don't, they have their modification dates set to the time of the copy, but > not all of them. Some of the files in the subfolders have their modification > date set correctly. > > Now, using "setAttributes:ofItemAtPath:error:", some of those files with the > incorrect modification dates will be fixed, some won't. When NSFileManager > fails to properly set the modification date, it will properly return the > error in the NSError object but, like I mentioned before, the message says > "You don’t have permission to save the file “XYZ” in the folder “Folder ABC”. > "Folder ABC" is the folder I copy, not at all the folder that contains file > "XYZ" and the error code is 513, which is "NSFileWriteNoPermissionError = > 513, // Write error (permission problem)" according to "FoundationErrors.h". > That is not the right error because NSFileManager was able to obviously copy > that file after it successfully copied the subfolder inside "Folder ABC". > Obviously, there was no permission problem to copy the subfolder and the > files in it. That's what is puzzling me. > > The only real attribute I'm interested in is the modification date. When > using "setAttributes:ofItemAtPath:error:", the only object I provide in the > attributes NSDictionary is the modification of the original file. > > Now, I had an older implementation, which I'm trying to replace by a more > efficient way to duplicate folders. This older implementation works well > using "copyPath:toPath:handler:". This implementation coupled with a call to > FSSetCatalogInfo() can successfully duplicate a given folder and all its > content with the proper modification dates. I tried in my new implementation > to replace my calls to "setAttributes:toItemAtPath:error:" with the > FSSetCatalogInfo() but although it fixes a lot of files with incorrect > modification dates, there are still a few that aren't fixed. Since the only > major difference is the call I make to copy the items in the first place, I'm > thinking that "copyPath:toPath:handler:" copies the files more reliably than > "copyItemAtPath:toPath:error:" but I haven't been able yet to replace my call > to "copyItemAtPath:toPath:error:" because the method sent by NSFileManager to > the "handler" only provide the source path. I could work around this but that > would require major modifications to my current implementation. Further, I > went from "copyPath:toPath:handler:" to "copyItemAtPath:toPath:error:" > because th
Finding per-process network usage?
[I'm not sure if this is the right forum to ask this, please direct me there if it's wrong] I'm trying to monitor the network traffic of applications by process but I'm having trouble working out how to query the system for that information. I've been looking at sysctl() and while I have some (antiquated) kernel experience, I'm having trouble navigating the data structures. Can anyone give me a few pointers? Thanks, Ben. smime.p7s Description: S/MIME cryptographic signature ___ 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: NSMatrix bindings
On Mar 18, 2011, at 10:14 PM, Ken Thomases wrote: > On Mar 18, 2011, at 3:45 AM, Christian Ziegler wrote: > >> I'm having hard times figuring out how to bind an NSMatrix properly. I got >> an NSMatrix with NSButtonCells (checkboxes) and I want to somehow bind to my >> model which of these checkboxes are selected. What should work is binding >> the content objects of the NSMatrix to an ArrayController and fill the >> arrayController's content with NSButtonCells programmatically. > > Huh? An NSMatrix is a view (in the Model-View-Controller design pattern), an > array controller is a controller, and it provides access to model data. > NSButtonCells are not model data, they are elements of the view. You don't > "fill the arrayController's content with NSButtonCells". > > You should have a model property somewhere which is an array of objects to be > presented in the matrix. This might be as simple as strings for the names of > the checkboxes, or it might be objects each of which has a property which > will be the name of a checkbox. You bind the array controller's contentArray > to this model property (the array of objects). > > You then bind the matrix's content to the array controller's arrangedObjects. > If the objects are not themselves the values for the checkboxes, you also > bind the matrix's contentValues to the array controller's arrangedObjects > with a model key path which obtains the values for the checkboxes. > > You can bind the matrix's selectedObjects or selectedValues to another > controller's property, which is a to-many property with the appropriate > mutation accessors. You bind selectedObjects if you want to track the > objects which correspond to each checkbox. You bind selectedValues if you > want to track the values, if there's a distinction (see previous paragraph). > > It should also work to bind the matrix's selectedObjects to the array > controller's selection. Then you can bind the array controller's > selectionIndexes to a property of your coordinating controller (e.g. File's > Owner). That way, your property which tracks the selection can be related > back to the property which provided the array controller's content, instead > of merely being another array which shares some elements. > > I hope that helps. > > Regards, > Ken > Hi, so I tried it the way Ken described it. However if I start the app, the Matrix is empty. I created the Matrix and all Cells with their titles in IB, assuming that these objects will be created after the nib was loaded. The arrayControllers class type is set to NSString. Other checkboxes (NSButtons) in my GUI which I set to "On" in IB are also "Off" after starting the app, so it seems that values set in IB are not being set on the model as an initial value. Can anybody confirm that or am I doing something wrong? Cheers, Chris ___ 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: Exporting and Importing CoreData
On 23 Mar 2011, at 23:13, Siegfried wrote: > Also, now on the mechanics, I think creating a mutable string and go > appending parts of the XML in a loop is adequate for this task, and using > NSXMLParser to parse it back should work. Indeed, the file will not be that > big (usually a few hundreds of KBs, really extremes cases are 1 or 2MB). If you do this, use KSXMLWriter from: https://github.com/karelia/KSHTMLWriter It'll handle escaping etc. properly for 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: Exporting and Importing CoreData
On 24/03/2011, at 08:52, Mike Abdullah wrote: > > On 23 Mar 2011, at 23:13, Siegfried wrote: > >> Also, now on the mechanics, I think creating a mutable string and go >> appending parts of the XML in a loop is adequate for this task, and using >> NSXMLParser to parse it back should work. Indeed, the file will not be that >> big (usually a few hundreds of KBs, really extremes cases are 1 or 2MB). > > If you do this, use KSXMLWriter from: > https://github.com/karelia/KSHTMLWriter > > It'll handle escaping etc. properly for you. Mike, thanks a lot for providing both the link and your work. It's really helpful! Best regards, Siegfried___ 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: Exporting and Importing CoreData
Siegfried, I am late in this thread, but I don't understand why you need import/export. Is it just meant for backup purposes or is it a facility for the users to get data from other applications into yours (and out of it)? If it is the second case, why not stick with "delimited text" or "CSV-style" files? XML is not easy to edit for the average user, although it sure is human-readable. CSV, on the other hand, is pure text and can be imported by Excel, Numbers or any other spreadsheet app. Users could get data from others sources (HTML tables, SQL databases, spreadsheets, whatever...) into your app and out of it. I do this a lot: select table contents in web page, copy and paste into Numbers. I can delete some unneeded rows and columns, export into CSV and then insert into a database, for example. PHPMyAdmin can generate and import CSV files. When validating aCSV file for importing, if a line does not conform to a pre-defined format, you'll have to drop it. You can always show a dialog at the end of the process that says something like "Some lines could not be imported." and generate a report in a file for the user to see which lines were dropped. If you go the XML route, I am almost sure you'll need a DTD for validation. I hope it helps... Cheers, Flavio On 23/03/2011, at 21:55, Siegfried wrote: > Hello, > > I need to create an export / import system for my app, and just thought that > asking the list for some advices could help a lot. > > The CoreData database I have is fairly simple. No relationships, only 3 > entities with no more than 4 properties each: numbers and strings. So I think > exporting this as XML is the more appropriate solution. Also, it would allow > users make changes in the file easily. > > Are there any serious drawbacks from using this method? Or may a better > solution? What worries me most is the XML validation. It's not a high > priority, but having an at least decent XML is worthwhile. The big question: > A header saying XML version 1.0 is enough? Or do I need to create a DTD? > > Also, now on the mechanics, I think creating a mutable string and go > appending parts of the XML in a loop is adequate for this task, and using > NSXMLParser to parse it back should work. Indeed, the file will not be that > big (usually a few hundreds of KBs, really extremes cases are 1 or 2MB). > Well, at least I'm not aware of a framework to export / import CoreData, I > don't even think it is possible. > > Any "yes" or "no" on my ideas are really appreciated. > > Thanks, > > Best wishes, > > Siegfried ___ 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: Exporting and Importing CoreData
Hello Flavio, On 24/03/2011, at 11:53, Flavio Donadio wrote: > I am late in this thread, but I don't understand why you need import/export. > Is it just meant for backup purposes or is it a facility for the users to get > data from other applications into yours (and out of it)? I've clarified that in another message I think, sorry. I should have included it in the main message; anyway, the export will be a facility for backing up the database and sharing it with other users. > > If it is the second case, why not stick with "delimited text" or "CSV-style" > files? > > XML is not easy to edit for the average user, although it sure is > human-readable. Yes, I'm aware of that, but editing is not obligatory. I'm just providing an extra feature for the user who knows what is a XML and thus wants to edit it. > CSV, on the other hand, is pure text and can be imported by Excel, Numbers or > any other spreadsheet app. Users could get data from others sources (HTML > tables, SQL databases, spreadsheets, whatever...) into your app and out of it. > > I do this a lot: select table contents in web page, copy and paste into > Numbers. I can delete some unneeded rows and columns, export into CSV and > then insert into a database, for example. PHPMyAdmin can generate and import > CSV files. CSV is not something I had thought about, but maybe it could be included in the app for convenience. Thanks for the idea. > > When validating aCSV file for importing, if a line does not conform to a > pre-defined format, you'll have to drop it. You can always show a dialog at > the end of the process that says something like "Some lines could not be > imported." and generate a report in a file for the user to see which lines > were dropped. > > If you go the XML route, I am almost sure you'll need a DTD for validation. Yes, I'll have to do it. I think XML is the path to follow. > > I hope it helps... Certainly Sir! Thanks for providing your opinions and help, Best wishes, Siegfried > On 23/03/2011, at 21:55, Siegfried wrote: > >> Hello, >> >> I need to create an export / import system for my app, and just thought that >> asking the list for some advices could help a lot. >> >> The CoreData database I have is fairly simple. No relationships, only 3 >> entities with no more than 4 properties each: numbers and strings. So I >> think exporting this as XML is the more appropriate solution. Also, it would >> allow users make changes in the file easily. >> >> Are there any serious drawbacks from using this method? Or may a better >> solution? What worries me most is the XML validation. It's not a high >> priority, but having an at least decent XML is worthwhile. The big question: >> A header saying XML version 1.0 is enough? Or do I need to create a DTD? >> >> Also, now on the mechanics, I think creating a mutable string and go >> appending parts of the XML in a loop is adequate for this task, and using >> NSXMLParser to parse it back should work. Indeed, the file will not be that >> big (usually a few hundreds of KBs, really extremes cases are 1 or 2MB). >> Well, at least I'm not aware of a framework to export / import CoreData, I >> don't even think it is possible. >> >> Any "yes" or "no" on my ideas are really appreciated. >> >> Thanks, >> >> Best wishes, >> >> Siegfried > ___ 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: NSMatrix bindings
On Mar 24, 2011, at 2:51 AM, Christian Ziegler wrote: > so I tried it the way Ken described it. However if I start the app, the > Matrix is empty. I created the Matrix and all Cells with their titles in IB, > assuming that these objects will be created after the nib was loaded. The > arrayControllers class type is set to NSString. > > Other checkboxes (NSButtons) in my GUI which I set to "On" in IB are also > "Off" after starting the app, so it seems that values set in IB are not being > set on the model as an initial value. Can anybody confirm that or am I doing > something wrong? It sounds like you're expecting to use IB to populate your model based on how you set up the view. That's not how it works. Loading a NIB doesn't (and shouldn't) adjust your model. If there are bindings, then the view reads its settings from the model (via the controller layer) upon being loaded and displayed. You need to set up the model data independently, perhaps programmatically or perhaps by loading from a data file or the like. Regards, Ken ___ 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: Exporting and Importing CoreData
On Wed, Mar 23, 2011 at 4:38 PM, WT wrote: > How about using a property list file instead? Easier to import and export, > and can be edited with tools such as Property List Editor, though your users > might not know how to use it, or even have it. I'd recommend *not* going the property list route. Property lists have a very simple internal structure that makes it difficult to express things like references to other objects. They're also pretty slow, particularly the XML flavor. Also, don't use NSKeyedArchiver. That ties your on-disk representation to whatever class hierarchy was used to produce that file. Using a custom XML format is definitely the way to go, especially if you publish a DTD. It makes it easy for others to import your file or otherwise manipulate it using the rich set of XML tools on the market, including XSLT. A custom format means you can be much more selective in the amount of processing you perform on input, speeding up your import process. --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
Parsing XML to CoreData
So, after discussing some methods to import and export a CoreData database, I
ended up sticking with my initial XML idea.
Now I'm stuck in a problem when parsing that is probably simple, but I can't
solve. Basically, my XML is like this:
Value
Value
Value
Value
Value
Value
When parsing with NSXMLParser, everything runs properly (well, almost) except
for the fact that every property (child elements here) from every entity (elem
here) gets the value from the last imported property, child3 in this case.
For me, that means my currentEntity ivar is keeping track of every entity
created, in some way that I probably just managed to do due to little CoreData
knowledge.
Here is the main code:
-(void)parser: ... didStartElement: {
...
// Entity
if ([elementName isEqualToString:kEntityContent]) {
if (currentEntity) [currentEntity release]; // currentEntity is an ivar
currentEntity = [[NSEntityDescription
insertNewObjectForEntityForName:kContent
inManagedObjectContext:managedObjectContext]
retain];
return;
}
// Attribute
if ([elementName isEqualToString:kAttrName]) {
[currentXMLValue setString:@""]; // currentXMLValue is another ivar
return;
}
...
}
-(void)parser: foundCharacters:(NSString *)string {
[currentXMLValue appendString:string];
}
-(void)parser: ... didEndElement {
// Database - Save the Import
if ([elementName isEqualToString:@"database"]) {
NSError *error;
if (![self.managedObjectContext save:&error]) {
NSLog(@"There was an error while saving "
"the imported database: %@", error);
}
}
// Attribute
if ([elementName isEqualToString:kAttrName]) {
[currentEntity setValue:currentXMLValue forKey:kAttrName];
return;
}
...
}
Thanks in advance for any help.
Regards
Siegfried___
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: Parsing XML to CoreData
On Mar 24, 2011, at 12:06 PM, Siegfried wrote:
> So, after discussing some methods to import and export a CoreData database, I
> ended up sticking with my initial XML idea.
>
> Now I'm stuck in a problem when parsing that is probably simple, but I can't
> solve. Basically, my XML is like this:
>
>
>Value
>Value
>Value
>
>
>Value
>Value
>Value
>
[snip]
> When parsing with NSXMLParser, everything runs properly (well, almost) except
> for the fact that every property (child elements here) from every entity
> (elem here) gets the value from the last imported property, child3 in this
> case.
> -(void)parser: ... didEndElement {
>
>// Database - Save the Import
>if ([elementName isEqualToString:@"database"]) {
>
>NSError *error;
>if (![self.managedObjectContext save:&error]) {
>NSLog(@"There was an error while saving "
> "the imported database: %@", error);
>}
>}
>
>// Attribute
>if ([elementName isEqualToString:kAttrName]) {
>[currentEntity setValue:currentXMLValue forKey:kAttrName];
>return;
>}
You need to copy currentXMLValue, because in your code, every item that refers
to it ends up referring to the same mutable string, which will change every
time the parser:foundCharacters: method is called.
NSString *newValue = [currentXMLValue copy];
[currentEntity setValue:newValue forKey:kAttrName];
[newValue release];
Assigning strings like you did works with immutable ones, but not with mutable
ones.
Hank
___
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: Parsing XML to CoreData
On 24/03/2011, at 13:13, Hank Heijink (Mailinglists) wrote: > On Mar 24, 2011, at 12:06 PM, Siegfried wrote: > >> So, after discussing some methods to import and export a CoreData database, >> I ended up sticking with my initial XML idea. >> ... > > You need to copy currentXMLValue, because in your code, every item that > refers to it ends up referring to the same mutable string, which will change > every time the parser:foundCharacters: method is called. > > NSString *newValue = [currentXMLValue copy]; > [currentEntity setValue:newValue forKey:kAttrName]; > [newValue release]; > > Assigning strings like you did works with immutable ones, but not with > mutable ones. Ah Hank! How can I thank you? Such a simple thing but was driving me crackers. Thanks so much, Best regards, Siegfried___ 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: Exporting and Importing CoreData
On 24/03/2011, at 12:24, Kyle Sluder wrote: > On Wed, Mar 23, 2011 at 4:38 PM, WT wrote: >> How about using a property list file instead? Easier to import and export, >> and can be edited with tools such as Property List Editor, though your users >> might not know how to use it, or even have it. > > I'd recommend *not* going the property list route. Property lists have > a very simple internal structure that makes it difficult to express > things like references to other objects. They're also pretty slow, > particularly the XML flavor. > > Also, don't use NSKeyedArchiver. That ties your on-disk representation > to whatever class hierarchy was used to produce that file. > > Using a custom XML format is definitely the way to go, especially if > you publish a DTD. It makes it easy for others to import your file or > otherwise manipulate it using the rich set of XML tools on the market, > including XSLT. A custom format means you can be much more selective > in the amount of processing you perform on input, speeding up your > import process. > > --Kyle Sluder Thanks Kyle, I'll do it in with the XML. Best regards ___ 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: Problem with setAttributesOfItemAtPath:error:
Thanks, Gary, I'll double-check. Anybody else with suggestions for "copyItemAtPath:toPath:error:" that can't copy items reliably to a remote volume mounted through AFP? Anyone? I can't believe I'm the only one on the Cocoa-Dev list that is using this method? -Laurent. -- Laurent Daudelin AIM/iChat/Skype:LaurentDaudelin http://www.nemesys-soft.com/ Logiciels Nemesys Software laur...@nemesys-soft.com On Mar 24, 2011, at 00:01, Gary L. Wade wrote: > Make sure you use the do-not-traverse-symbolic-links form when constructing > your FSRef for the FSSetCatalogInfo call. I do remember having to do that > call in similar circumstances, which is why I was going to try > FSCopyObjectAsync to see if that would solve all those issues as well as get > in-progress status, but I held off until that APIs memory leaks were fixed > (which became bad when copying a few thousand files), and it was fixed in > 10.6.7 (it was present in all of 10.6 up to 10.6.6). > > - Gary L. Wade (Sent from my iPad) > > On Mar 23, 2011, at 11:14 PM, Laurent Daudelin > wrote: > >> On Mar 23, 2011, at 19:49, Ken Thomases wrote: >> >>> On Mar 23, 2011, at 7:37 PM, Laurent Daudelin wrote: >>> I actually looked at FSMegaInfo but when I built it, I realized that it was using a lot of deprecated functions in 10.6 so I decided against using any part of it because of the amount of work that would be required to rewrite some parts of it. >>> >>> First of all, deprecated doesn't mean "not available". Second, the disk >>> image I have (maybe from some time ago) has a pre-built binary. >>> >>> And yes, I do understand that different file systems will have different attributes. But, I'm sharing that remote volume from an Intel iMac running 10.5.8, connected to it through AFP. Shouldn't AFP supports basic file attributes? >>> >>> Depends on what you mean by "basic". I don't recall you saying which >>> attributes you were trying to set when you got errors. >>> >>> Regards, >>> Ken >>> ___ 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: Parsing XML to CoreData
I guess you could also alloc a new NSMutableString every time you enter "didStart" ... copy will essentially be doing that for you. If you do this - don't forget to release in "didEnd" ... or even right before allocing - just in case you somehow break out before reaching didEnd. -Luther On Thu, Mar 24, 2011 at 11:24 AM, Siegfried < triebschen.siegfried.id...@gmail.com> wrote: > On 24/03/2011, at 13:13, Hank Heijink (Mailinglists) wrote: > > On Mar 24, 2011, at 12:06 PM, Siegfried wrote: > > > >> So, after discussing some methods to import and export a CoreData > database, I ended up sticking with my initial XML idea. > >> ... > > > > You need to copy currentXMLValue, because in your code, every item that > refers to it ends up referring to the same mutable string, which will change > every time the parser:foundCharacters: method is called. > > > > NSString *newValue = [currentXMLValue copy]; > > [currentEntity setValue:newValue forKey:kAttrName]; > > [newValue release]; > > > > Assigning strings like you did works with immutable ones, but not with > mutable ones. > > Ah Hank! How can I thank you? > > Such a simple thing but was driving me crackers. > > Thanks so much, > > Best regards, > > Siegfried___ > > 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/lutherbaker%40gmail.com > > This email sent to lutherba...@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
Re: CoreData questions: How to reset NSManagedObject, how to "Un-manage" an NSManagedObject.
Thanks Andreas, for such a complete and helpful answer. Regarding reset issue, I was curious --- after all, NSManagedObject gets its initial dictionary from the Model definition somehow, doesn't it? why can't I do it, or even better, why isn't it implemented as a NSManagedObject API? I find resetting an object a very basic functionality. I'll see how I can write some generic code to do it for all my entities. Regarding the other issue (sigh) Well, we are contractors for a big company. They have their old server-client code modules, and they try to keep them cross-platform (Yup, Windows). That's why they refrain from any Core-Data direct calls in the background thread client code. It's not because it's on a thread, it's because this code is not "Mac only" code. We DO employ the technique you demonstrated, (a flavor of it) and we do have 2 contexts (one writing, one reading) to achieve transactional behavior on the UI side, (updating the UI on controllable sets of changes). The big-company guys, simply duplicated all the model classes generated from the model, polluting the namespace, and introducing pitfalls all over the place (If the model changes, it is no longer in sync with those data objects). I was hoping to propose a solution that will eliminate those duplicate model classes. Thanks again! Motti. On 23/03/2011, at 20:27, Andreas Grosam wrote: > On Mar 23, 2011, at 8:21 AM, Motti Shneor wrote: > >> Hi. >> >> 1. When you create an NSManagedObject, it is initialized with default values >> defined in the model. How can I reset an existing NSManagedObject to these >> default values? > Unless there is a better way, I would suggest to use a dictionary > representation of a freshly created managed object through taking a > "snap-shot" of this object using dictionaryWithValuesForKeys:. Then "reset" > any managed object by sending it setValuesForKeysWithDictionary:. You may > declare this dictionary as a class variable of your custom class and > initialize it once when you create the first managed object. You may get the > key paths using the entity description. > >> >> 2. We have a multithreaded application, and we only keep one core-data >> context. Our network-related code receives data in a background thread, but >> is unable to write it to the model directly. So it saves it in some >> intermediate data object, and passes it to the main-thread for writing into >> the model. >> I would like to use an NSManagedObject to replace the intermediate data >> object --- It is quite ugly to have duplicated model classes definition for >> everything. My question: > I wonder why you cannot modify the model (that is save a context) within the > background thread. Business logic should be honored regardless of the thread. > So, usually you would do the following: > >> >> Can I somehow detach an NSManagedObject from its context, and use it in an >> "Unmanaged" way? > No, a managed object must be registered with a managed object context. >> Hopefully I can later attach it to the context, or create another >> NSManagedOBject from its data? > You could use a dictionary representation and initialize a managed object > from it. > > Regards > Andreas Motti Shneor, Spectrum Reflections LTD. --- ceterum censeo microsoftiem delendam esse ---___ 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: CoreData questions: How to reset NSManagedObject, how to "Un-manage" an NSManagedObject.
On Mar 23, 2011, at 12:49, Motti Shneor wrote: > Regarding reset issue, I was curious --- after all, NSManagedObject gets its > initial dictionary from the Model definition somehow, doesn't it? Managed objects don't "have" dictionaries -- properties aren't implemented that way. They have internal (private) storage that's similar in behavior to instance variables, but isn't actual instance variables. > why can't I do it, or even better, why isn't it implemented as a > NSManagedObject API? You can and it is, but you just missed seeing it in the documentation. Look at NSEntityDescription. Presumably, this is what Core Data itself uses to initialize objects. > Regarding the other issue (sigh) > > Well, we are contractors for a big company. They have their old server-client > code modules, and they try to keep them cross-platform (Yup, Windows). That's > why they refrain from any Core-Data direct calls in the background thread > client code. It's not because it's on a thread, it's because this code is not > "Mac only" code. You may have a valid reason, but what you *say* doesn't make any sense. This is what you wrote earlier: > On Mar 23, 2011, at 12:49, Motti Shneor wrote: > >> 2. We have a multithreaded application, and we only keep one core-data >> context. Our network-related code receives data in a background thread, but >> is unable to write it to the model directly. So it saves it in some >> intermediate data object, and passes it to the main-thread for writing into >> the model. >> I would like to use an NSManagedObject to replace the intermediate data >> object --- It is quite ugly to have duplicated model classes definition for >> everything. If the corporate bigwigs are forcing you to use platform-agnostic code for the background thread, then they're forcing you to use platform-agnostic intermediate data objects, and so you wouldn't be trying to replace them with managed objects. If you're free to replace them with managed objects, you're free to use a managed object context (an extra one) in the background thread. Which of the two problems are you trying to (allowed to) solve? ___ 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: CoreData questions: How to reset NSManagedObject, how to "Un-manage" an NSManagedObject.
On Mar 23, 2011, at 8:49 PM, Motti Shneor wrote: > Thanks Andreas, for such a complete and helpful answer. > > Regarding reset issue, I was curious --- after all, NSManagedObject gets its > initial dictionary from the Model definition somehow, doesn't it? (see Quincey's reply) > why can't I do it, or even better, why isn't it implemented as a > NSManagedObject API? Unfortunately, there is no convenience method which would reset a managed object to its default values defined in the model. > > I find resetting an object a very basic functionality. I'll see how I can > write some generic code to do it for all my entities. ... but you can certainly use the entity description for getting the default values. However, this is much more elaborated than just setting up a dictionary holding the initial state. But I agree, I can think of a generic solution. So, you might go this route and implement your own reset method for your custom entity class. > > Regarding the other issue (sigh) > > Well, we are contractors for a big company. They have their old server-client > code modules, and they try to keep them cross-platform (Yup, Windows). That's > why they refrain from any Core-Data direct calls in the background thread > client code. It's not because it's on a thread, it's because this code is not > "Mac only" code. OK, just let us assume, your platform agnostic code handles the import of data objects, running in a separate thread. The result is one or more arrays of "records" existing in some intermediate form. These may be in RAM or on a file, doesn't matter. If I understood you correctly, your "internal Mac specific task" is now to read these "records" and create managed objects from them: > We DO employ the technique you demonstrated, (a flavor of it) and we do have > 2 contexts (one writing, one reading) to achieve transactional behavior on > the UI side, (updating the UI on controllable sets of changes). This sounds fine. > > The big-company guys, simply duplicated all the model classes generated from > the model, polluting the namespace, and introducing pitfalls all over the > place (If the model changes, it is no longer in sync with those data > objects). I was hoping to propose a solution that will eliminate those > duplicate model classes. Uhm, I fear we are entering a wide, wide area of complex problems now, which may include problems from distributed databases, synchronizing, client-specific restrictions, etc.,etc. I cannot give a specific answer to this problem. It depends too much on your actual requirements. I can imagine that there may be client-applications which can handle virtual any model, so model changes wouldn't hurt or wouldn't make the client unusable. But these applications cannot perform more complex business logic. So, viewing any sort of hierarchically structured data could have a generic solution. But if you want to do more complex things, like creating a sales order - you should know a priory what your data is and what the corresponding business logic is. Simply put, if you have a client application which essentially does some useful and complex stuff, you cannot change the model on neither side (namely change the specification or the API) without expecting any issues. So, you should agree on an API manifested in a specification. Well, I would suggest to use a client-platform independent model on the server side. That is, the server implements its (private) data model and the corresponding business logic. The server here is the "authoritative" regarding business logic. While the server side internal model may be private, the server communicates through an API defined in the specification. This could be materialized in sending objects in a JSON format, for instance. On the client side, there is a client specific data model which is quite similar to the server side model exposed by the specification (including business logic) but may be tailored to optimally meet client side requirements and restrictions. The client as well may implement all or part of the business logic. How much of it depends whether you can communicate with the server all the time, or if you want to be able to operate in "offline" mode. The server is the *authority* over what is created, deleted or modified in its store. In its simplest form, the client would not implement any complex business logic, just acting as a "view" then sending "form data". If you have to meet business logic AND if your client shall operate offline, the scenario becomes exponentially more complex. "Importing" then becomes "synchronizing" - and this is a very complex topic. With business logic, synchronizing must not happen on the database level, it must happen at the business logic level. In this more complex form, the client would fully replicate the business logic implemented on the authoritative server - and would then be able to operate independently. Nonetheless,
iOS - Hide Master view in a split view
I am trying to figure out how to hide the master view in a split view while in landscape mode. Searching, I found the suggestion to try: [[master view] setFrame:CGRectMake(0, 0, 0, 0)]; [[detail view] setFrame:splitBounds]; However, this does not appear to work. What is the recommend method for hiding the master view in landscape mode so the detail view can make use of the entire screen? Thanks. ___ 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: iOS - Hide Master view in a split view
On Mar 24, 2011, at 6:27 PM, Eric Gorr wrote: > I am trying to figure out how to hide the master view in a split view while > in landscape mode. Searching, I found the suggestion to try: > > [[master view] setFrame:CGRectMake(0, 0, 0, 0)]; > [[detail view] setFrame:splitBounds]; > > However, this does not appear to work. What exactly doesn't work? Hiding or resizing the detail view? > What is the recommend method for hiding the master view in landscape mode so > the detail view can make use of the entire screen? > > Thanks. I just ran a very quick test and the following code snippet successfully toggles between showing and hiding the master view: UIViewController* vc; vc = [splitViewController.viewControllers objectAtIndex: 0]; vc.view.hidden = !vc.view.hidden; All you need to do then is adjust the frame of the detail view, which is the object at index 1 in the array splitViewController.viewControllers. Of course, you want to make sure that this code only runs when the device orientation is landscape and you'll want to cache the two frames the detail view will be having. WT___ 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: iOS - Hide Master view in a split view
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/24/11 4:11 PM, WT wrote: > On Mar 24, 2011, at 6:27 PM, Eric Gorr wrote: > >> I am trying to figure out how to hide the master view in a split view while >> in landscape mode. Searching, I found the suggestion to try: You could also look at MGSplitViewController: http://mattgemmell.com/2010/07/31/mgsplitviewcontroller-for-ipad etc. It's licensed under the BSD license, but Matt Gemmell explicitly offers a commercial license for a fee (no idea how much...) if needed. - -- Conrad Shultz Synthetiq Solutions www.synthetiqsolutions.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNi9DraOlrz5+0JdURAgxBAJ9D+ElHsX+u4fx2lJbjIzB4wZt3kQCggZBf nWtP2JYlIHr9quACWF1V0lo= =UXBY -END PGP SIGNATURE- ___ 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: iOS - Hide Master view in a split view
Sent from my iPhone On Mar 24, 2011, at 7:11 PM, WT wrote: > On Mar 24, 2011, at 6:27 PM, Eric Gorr wrote: > >> I am trying to figure out how to hide the master view in a split view while >> in landscape mode. Searching, I found the suggestion to try: >> >> [[master view] setFrame:CGRectMake(0, 0, 0, 0)]; >> [[detail view] setFrame:splitBounds]; >> >> However, this does not appear to work. > > What exactly doesn't work? Hiding or resizing the detail view? The code has no effect at all. > >> What is the recommend method for hiding the master view in landscape mode so >> the detail view can make use of the entire screen? >> >> Thanks. > > I just ran a very quick test and the following code snippet successfully > toggles between showing and hiding the master view: > > UIViewController* vc; > vc = [splitViewController.viewControllers objectAtIndex: 0]; > vc.view.hidden = !vc.view.hidden; > > All you need to do then is adjust the frame of the detail view, which is the > object at index 1 in the array splitViewController.viewControllers. Of > course, you want to make sure that this code only runs when the device > orientation is landscape and you'll want to cache the two frames the detail > view will be having. I don't think it is so easy to adjust the frame of the detail view considering the above code fails. I did try this, and, you're right, the master view will hide, but the detail view will not resize. > ___ 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: iOS - Hide Master view in a split view
On Mar 24, 2011, at 8:18 PM, Eric Gorr wrote: >> On Mar 24, 2011, at 7:11 PM, WT wrote: >> >> I just ran a very quick test and the following code snippet successfully >> toggles between showing and hiding the master view: >> >> UIViewController* vc; >> vc = [splitViewController.viewControllers objectAtIndex: 0]; >> vc.view.hidden = !vc.view.hidden; >> >> All you need to do then is adjust the frame of the detail view, which is the >> object at index 1 in the array splitViewController.viewControllers. Of >> course, you want to make sure that this code only runs when the device >> orientation is landscape and you'll want to cache the two frames the detail >> view will be having. > > I don't think it is so easy to adjust the frame of the detail view > considering the above code fails. I did try this, and, you're right, the > master view will hide, but the detail view will not resize. Hmm... could it be that the detail view has the autoresize masks set in a way to prevent it from expanding to the left? The solution might be as simple as just (re)setting them appropriately in which case you don't need any setFrame: code at all and hiding/showing the master view would suffice. I can't try that right now but, if you do, please share the outcome.___ 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
Mutable and immutable class cluster implementation / "method swizzling" question
[This is a re-send as my previous message has been sitting in the moderators
queue for ~week now...]
I've got an odd question. I haven't found anything via Google that matches
it exactly, but it could be that I'm just searching for the wrong thing.
I have a need to create subclasses of NSArray and NSDictionary. The
@interface line is "@interface MYArray : NSArray" (etc). No problems here-
implemented the various required class cluster interfaces. (In the examples
below, I only discuss the "array" collection class, but assume that the same
"thing" applies to the dictionary collection class, modulo the obvious
differences)
I also have a need to create mutable versions of my custom subclasses
(if you're curious as to why I'm doing all this, the short answer is
"performance"... and yes, /all/ of it is justified by extensive (hours and
hours) of profiling / Shark.app... which are in no way "micro-benchmarking"
results. It's for serializing/deserializing JSON-
https://github.com/johnezang/JSONKit - I can serialize and deserialize JSON
faster than binary plists can for the exact same data... I beat binary plist
serialization by such a huge margin I can literally gzip the result and
STILL beat binary .plists!).
In all cases, the classes are guaranteed to only be created by my code and
it is documented that it is verboten to directly instantiate objects of
these special classes. It is also documented that it is verboten to do any
kind of subclassing of these classes. They are purely "private
implementation details".
They DO need to behave and respond "identically" to an instantiated instance
of their respective class (that is to say the class and instance methods
used to instantiate objects of these special classes are documented to be
verboten / undefined behavior). Unless there is an exceptionally good
reason, they should be completely compatible in every way and
indistinguishable from their NSArray / NSMutableArray Cocoa concrete
instances.
There is no .h header file publicly exposed for these special classes- they
don't add any extra behavior. In effect, they are the epitome of "duck
typed" collection objects- the exposed public interfaces that eventually
return these custom classes are prototyped with -(NSArray *).
I am currently using "@interface MYMutableArray : NSMutableArray". But just
like NSMutableArray is a subclass of NSArray, MYMutableArray is a subclass
of MYArray, not really NSMutableArray.
The "problem" is that with the @interface written as MYMutableArray :
NSMutableArray", I don't inherit the MYArray methods, which I'd very much
like to.
While one possible solution is to just copy and paste the code from MYArray
in to the MYMutableArray and chalk it up to "required bloat", I would much
rather only have a single copy of the reusable immutable code- one advantage
is that changes, if required, only need to be made in one place, instead of
remembering to keep both copies in sync.
To accomplish this, I've used a form of "method swizzling", but it's not
quite method swizzling as the term is normally used. It's more like "method
copying". Here's the current code:
static void _swizzleInstanceMethod(Class fromClass, Class toClass, SEL
selector) {
fromClass = class_isMetaClass(fromClass) ?
objc_getClass(class_getName(fromClass)) : fromClass;
toClass = class_isMetaClass(toClass) ?
objc_getClass(class_getName(toClass)) : toClass;
class_replaceMethod(fromClass, selector,
method_getImplementation(class_getInstanceMethod(toClass, selector)),
method_getTypeEncoding(class_getInstanceMethod(fromClass, selector)));
}
static void _swizzleClassMethod(Class fromClass, Class toClass, SEL
selector) {
fromClass = class_isMetaClass(fromClass) ? fromClass :
objc_getMetaClass(class_getName(fromClass));
toClass = class_isMetaClass(toClass) ? toClass :
objc_getMetaClass(class_getName(toClass));
class_replaceMethod(fromClass, selector,
method_getImplementation(class_getClassMethod(toClass, selector)),
method_getTypeEncoding(class_getClassMethod(fromClass, selector)));
}
I'm not 100% certain that the from / to MetaClass bits are needed as they
are probably redundant / unnecessary with the later class_getClassMethod /
class_getInstanceMethod calls (i.e., they probably automatically do the
exact same meta class checks).
I am using class_replaceMethod, which for now isn't a problem since I'm
assuming a "modern" 10.5+ runtime. I can't find a handy reference for the
minimum version of iOS that this function is supported (I'm sort of assuming
"all" as it started as a "modern" objc abi). If, for some reason, < 10.5 /
"modern" ObjC run time support is required, I suppose I could hack up
class_replaceMethod equivalent behavior, but this isn't a pressing issue
right now.
These functions are used in the mutable classes +load method to:
{
Class MYMutableArrayClass = objc_getClass("MYMutableArray"); Class
MYArrayClass = objc_getClass("MYArray");
// We swizzle the methods from MY
Re: Mutable and immutable class cluster implementation / "method swizzling" question
The corner case you mention below ( [myMutableArrayInstance isKindOfClass:[NSMutableArray class]] ) is a nonissue for a somewhat surprising reason. All instances of NSArray are actually implemented via the concrete class NSCFArray, which is a subclass of NSMutableArray. Thus any instances of mutable or immutable arrays return YES to isKindOfClass for both NSArray and NSMutableArray. The only time that is not true is when people implement custom subclasses of NSArray. Thus no one can depend on that particular construct working unless they have implemented their own subclasses. For that reason, you can probably completely ignore the issue. If you care about behaving like Apple's imps I would suggest that you should make your immutable class a subclass of NSMutableArray, and just have it's mutation methods throw exceptions. Implement your mutable array as a subclass of that. That will actually give you the same (somewhat counter intuitive) behavior as the builtin classes. Better yet, you could do exactly what they do, have a single implementation and control whether mutation works or throws by setting a bit. (Everything I said about arrays is equally applicable to dictionaries, sets, and strings) Louis On Mar 25, 2011, at 12:49 AM, John Engelhart wrote: > I've considered the "assume everyone and everything practices proper duck > typing" and just make @interface MYMutableArray : MYArray. There is one > corner case that I can think of where this breaks: > [myMutableArrayInstance isKindOfClass:[NSMutableArray class]]. Granted, > doing this is frowned on as "not proper Objective-C programming", but none > the less, I'm sure some people do it. I'm also not entirely sure how this > might interact with serialization, either NSCoder or property lists. > Currently, my spot checks of NSCoder behavior causes the instances to be > serialized as NSArray or NSMutableArray, which is just fine and what I want > since the sole reason that I'm creating these custom classes is for bulk > creation of collection objects very, very quickly. > > Can anyone think of corner cases in which these would not behave > "identically" to their respective concrete Cocoa versions? KVO / KVC? > Anything "weird" but still considered legitimate? The CoreFoundation > CFArray... / CFDictionary calls seem to work as expected (but I can't say > I've done a comprehensive test of everything). Fast enumeration and block > based enumeration works, though come to think of it I haven't tried the > "parallel" option. Distributed Objects... CoreData? I'd like to provide > "maximally compatible" if at all possible, and if not, then clearly document > the limitations / caveats. ___ 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: Mutable and immutable class cluster implementation / "method swizzling" question
On Mar 24, 2011, at 10:49 PM, John Engelhart wrote: > I'm curious if anyone sees any problems with this approach... Again, I > haven't found anything on the web that covers this exactly, so there's no > prior experience to draw on / best practices. This is the first time I've > had to do both mutable and immutable classes of a collection class cluster. > I didn't even anticipate that there was a problem until I literally wrote > "@interface MYMutableArray : NSMutableArray ergh, but how exactly do I > inherit the MYArray methods I already wrote... ? h" I would suggest doing: @interface MYMutableArray : NSMutableArray and @interface MYArray : NSArray then for the 'shared code', instead of putting it in MYArray.m and copying it in MYMutableArray.m, put it into a shared code file. Most times I've seen it done, developers use a '.i' extension. Then you can just include the '.i' file in both MyArray.m and MYMutableArray.m Pros: -don't need to worry about not updating common code -inheritance tree makes sense to you six months from now. You don't have to write a long explanation about why your non-mutable class subclasses a mutable class, then disables the mutable methods Cons: -object code larger than absolutely necessary -some extra design effort to make sure the non-shared code interacts with the shared code and header files properly [as now it's split into more files and used by two classes] And the 'Pros' win! 42 words to 38 words for 'Cons'! Eli ___ 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: Mutable and immutable class cluster implementation / "method swizzling" question
On Fri, Mar 25, 2011 at 1:30 AM, Louis Gerbarg wrote: > The corner case you mention below ( [myMutableArrayInstance > isKindOfClass:[NSMutableArray class]] ) is a nonissue for a somewhat > surprising reason. All instances of NSArray are actually implemented via the > concrete class NSCFArray, which is a subclass of NSMutableArray. Thus any > instances of mutable or immutable arrays return YES to isKindOfClass for > both NSArray and NSMutableArray. The only time that is not true is when > people implement custom subclasses of NSArray. Thus no one can depend on > that particular construct working unless they have implemented their own > subclasses. > I've spent quite a bit a time plumbing the depths of the system, on this issue and others. And even though I was vaguely aware (and had differently observed it over the course of implementing my solution) that both NSArray and NSMutableArray concrete, instantiated objects both share the class "NSCFArray" at run time... that last little leap that NSCFArray -> NSMutableArray -> NSArray quite never happened, for some reason. Sometimes, a fresh pair of eyes... :) (thanks, btw) > For that reason, you can probably completely ignore the issue. If you care > about behaving like Apple's imps I would suggest that you should make your > immutable class a subclass of NSMutableArray, and just have it's mutation > methods throw exceptions. Implement your mutable array as a subclass of > that. That will actually give you the same (somewhat counter intuitive) > behavior as the builtin classes. Better yet, you could do exactly what they > do, have a single implementation and control whether mutation works or > throws by setting a bit. > Yep, a quick check shows that the immutable variant do indeed -respondToSelector: for the mutating methods, but the immutable variants throw a 'NSInternalInconsistencyException' with a '*** -[NSCFDictionary setObject:forKey:]: mutating method sent to immutable object' reason. > (Everything I said about arrays is equally applicable to dictionaries, > sets, and strings) > This is obviously the "better" way when you need to implement both the mutable and immutable versions of the systems class clusters. I can't recall seeing this approach advocated in any of the official documentation. On a zero order approximation, I can't find anything wrong with it in terms of "acceptable and commonly accepted Cocoa programming practices" from either an "Officially Documented" and "in practice" perspective. Since this is code that is intended to be used by others (who will likely use it on iOS), there is a very strong desire to do it "correct", for some strong definition of correct. ___ 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
