Le 19 juin 09 à 19:53, Eric Wasylishen a écrit : > Hey Quentin, > >> I'm not entirely convinced by this split, but I don't dislike it >> either :-) > > Okay :) If we decide against this, an alternative that might be good > is using more descriptive names than 'Etoile' for additions to these: > > NSIndexPath+Etoile > NSIndexSet+Etoile > NSInvocation+Etoile > NSString+Etoile > NSURL+Etoile > > For example, it could be +Convenience.
All categories are more or less convenience I would say. 'Convenience' doesn't seem clearer than 'Etoile'. This introduces another problem how do you name another category on NSString, NSURL etc. in another framework? Currently the rule I use is that a category on a class is named with the framework name, or 'Etoile' when this is the first category on a class in either EtoileFoundation or EtoileUI. My personal preference is also to have a single category per class and per framework, unless the category plays too many roles (e.g. if all NSObject categories were merged into a single one). What we have now is: NSString+Etoile <-- first category NSString+EtoileUI <-- second category in EtoileUI NSImage+Etoile <-- first category in EtoileUI I'd be in favor to simplify this further and simply name categories with the framework name, unless a category deserves to be split into multiple categories. So this would give: NSString+EtoileFoundation NSString+EtoileUI NSImage+EtoileUI If you prefer to have NSString+EtoileUIAdditions or NSString +EtoileUIConvenience, I'm fine with that. In Cocoa, categories are usually named this way. May be someone has another view on that? >>> ETFilter >> >> I'm not sure this class will survive in its current state. It is not >> used anywhere currently. >> Feel free to move it to branches/Deprecated/EtoileFoundation. > > I moved it to deprecated but then noticed that ETTransform is a > subclass of ETFilter, so I reverted the change. Ah right, I completely forgot ETTransform was using it. Sorry. So keep it in EtoileFoundation since ETTransform is used by EtoileUI to implement tree transforms with a visitor. >> I might miss something, but I think this class should really be named >> ETHistory and not ETHistoryManager. Each instance manage history >> entries and not histories, in other words each ETHistoryManager >> object >> just represents a simple history. >> For example, in the WebKit there is WebHistory which contains >> WebHistoryItem as elements. >> imo manager classes should only be created when they have no specific >> corresponding names in the real-word. > > Sounds good, I could rename it if you like. Truls said he is ok with this change and David told me the same a while back. So feel free to do it :-) >>> NSFileManager+NameForTempFile >>> NSFileManager+TempFile >> >> One of these two implementations is deprecated and has to be removed, >> but several modules depend on the old implementation. > > I could do this as well. Would be nice. -nameForTempFile has to be removed because it is unsafe. -tempFile should be used instead. -tempFile should be renamed -tempFileHandle. This would be more in line with GNUstep/Cocoa naming and make more obvious this method is not the symetric of -tempDirectory. -uniqueFileName: can be useful, so I suggest to keep it. May be we can consolidate these methods into an NSFileManager +EtoileFoundation category where we could add other small additions later? David, any comments? > Does this set of classes look more sensible to move to a "Utilities" > (or maybe "Convenience") subproject?: > > ETCArray > ETGetOptionsDictionary - function for processing command line args > ETTranscript - transcript for Smalltalk > NSFileManager+NameForTempFile > NSFileManager+TempFile > NSIndexPath+Etoile > NSIndexSet+Etoile > NSInvocation+Etoile - convenience factory method for NSInvocation > NSString+Etoile - some convenience methods for NSString > NSURL+Etoile - some convenience methods for NSURL Yes (except ETTranscript may be). It's fine for me. Feel free to rearrange it like that if David agrees (he is the other EtoileFoundation maintainer). Thanks for tidying all that :-) Quentin. _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
