"Andrew Dalke" <[EMAIL PROTECTED]> wrote: > George Sakkis wrote: > > You're right, conceptually a path > > HAS_A string description, not IS_A string, so from a pure OO point of > > view, it should not inherit string. > > How did you decide it's "has-a" vs. "is-a"? > > All C calls use a "char *" for filenames and paths, > meaning the C model file for the filesystem says > paths are strings.
Bringing up how C models files (or anything else other than primitive types for that matter) is not a particularly strong argument in a discussion on OO design ;-) > Paths as strings fit the Liskov substitution principle > in that any path object can be used any time a > string is used (eg, "loading from " + filename) Liskov substitution principle imposes a rather weak constraint on when inheritance should not be used, i.e. it is a necessary condition, but not sufficient. Take for example the case where a PhoneNumber class is subclass of int. According to LSP, it is perfectly ok to add phone numbers together, subtract them, etc, but the result, even if it's a valid phone number, just doesn't make sense. > Good information hiding suggests that a better API > is one that requires less knowledge. I haven't > seen an example of how deriving from (unicode) > string makes things more complicated than not doing so. I wouldn't say more complicated, but perhaps less intuitive in a few cases, e.g.: > path(r'C:\Documents and Settings\Guest\Local Settings').split() ['C:\\Documents', 'and', 'Settings\\Guest\\Local', 'Settings'] instead of ['C:', 'Documents and Settings', 'Guest', 'Local Settings'] I just noted that conceptually a path is a composite object consisting of many properties (dirname, extension, etc.) and its string representation is just one of them. Still, I'm not suggesting that a 'pure' solution is better that a more practical that covers most usual cases. George -- http://mail.python.org/mailman/listinfo/python-list
