Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Maybe I'm missing an obvious problem, but...why do you need both a URL and a path implementation of object? It seems like you could just store the path as a URL, and convert between the two as necessary. A reasonable implementation for your classes could be:</p> <pre><code>@interface FileSystemNode : NSObject { NSURL *URL; } @property (retain) NSURL *URL; @property (retain) NSString *path; - (id)initWithURL:(NSURL *)aURL; - (id)initWithPath:(NSString *)aPath; @end @implementation FileSystemNode @synthesize URL; - (id)initWithURL:(NSURL *)aURL { if ((self = [super init])) { [self setURL:aURL]; } return self; } - (id)initWithPath:(NSString *)aPath { return [self initWithURL:[NSURL fileURLWithPath:[aPath stringByExpandingTildeInPath]]]; } - (void)dealloc { [URL release]; [super dealloc]; } - (NSString *)path { return [[self URL] path]; } - (NSString *)setPath:(NSString *)path { [self setURL:[NSURL fileURLWithPath:[path stringByExpandingTildeInPath]]]; } @end @interface File : FileSystemNode @end @interface Directory : FileSystemNode @end </code></pre> <h1>Update (based on comments)</h1> <p>In the more general case, it may be easier to use a protocol for the top-level "object", and then have each concrete implementation implement the protocol. You could also use class clusters to make the public interface cleaner, so you just have <code>File</code> and <code>Directory</code> classes, instead of one for each type of backing store. This would also allow you to easily swap out implementations when you drop support for older versions of the framework. Something like this:</p> <pre><code>#import &lt;Foundation/Foundation.h&gt; // FileSystemNode.h @protocol FileSystemNode @property (readonly) NSURL *URL; @property (readonly) NSString *path; @end // File.h @interface File : NSObject &lt;FileSystemNode&gt; - (id)initWithURL:(NSURL *)aURL; - (id)initWithPath:(NSString *)aPath; @end // File.m @interface URLFile : File { NSURL *URL; } - (id)initWithURL:(NSURL *)aURL; @end @interface PathFile : File { NSString *path; } - (id)initWithPath:(NSString *)aPath; @end @implementation File - (id)initWithURL:(NSURL *)aURL { [self release]; return [[URLFile alloc] initWithURL:aURL]; } - (id)initWithPath:(NSString *)aPath { [self release]; return [[PathFile alloc] initWithPath:aPath]; } - (NSURL *)URL { [self doesNotRecognizeSelector:_cmd]; } - (NSString *)path { [self doesNotRecognizeSelector:_cmd]; } @end @implementation URLFile - (id)initWithURL:(NSURL *)aURL { if ((self = [super init])) { URL = [aURL retain]; } return self; } - (NSURL *)URL { return [[URL retain] autorelease]; } - (NSString *)path { return [URL path]; } @end @implementation PathFile - (id)initWithPath:(NSString *)aPath { if ((self = [super init])) { path = [aPath copy]; } return self; } - (NSURL *)URL { return [NSURL fileURLWithPath:path]; } - (NSString *)path { return [[path retain] autorelease]; } @end </code></pre> <p>I left out the implementation of <code>Directory</code>, but it would be similar.</p> <p>You could even go farther, I suppose. On Unix, a directory <em>is</em> a file with some special properties, so maybe <code>Directory</code> could even inherit from <code>File</code> (although that gets kind of ugly with class clusters, so exercise caution if doing so).</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COI need both implementations because some target platforms recommend NSURL (MacOS X 10.6), while others don't have them (Mac OS X 10.5). OK, granted, in that case, I could possibly fall back to a path-only implementation since MacOS X 10.6 still supports it (though deprecated and less efficient). But the question is more general than the example. Imagine abstracting 3D objects for OpenGL and DirectX for example (though I'm sure this is a terrible example for unrelated reasons).
      singulars
    2. CO@mipadi: I would agree with your approach, though I would probably implement it using a path-based NSString approach for the time being. In order to support 10.5, the URL methods, for the time being, would simply call the path-based equivalents. Any other code using this class could use the URL-based methods, with the anticipation that at sometime in the future, when 10.5-compatibility is no longer desirable, the internal implementation of the class could flip-flop and use NSURLs. Those classes that are already using the URL methods could then automatically take advantage without a re-write.
      singulars
    3. COWhile this may work in the specific case, it fails in the slightly more general case, where two target platforms have two different, mutually incompatible, implementations of the same functionality. Then if you want to unify (abstract away) those differences in your app, you will have to face similar issues.
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload