Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • The Liskov Substitution Principal is academic nonsense. Do we need to have the Pathname debate again?

    What I really need to do is write an article on why PhD's should never be trusted.

    • I can only assume you're referring to your response to my O'Reilly Liskov write-up [oreillynet.com]. I didn't respond to you then, but since you've mentioned this twice, I feel compelled to respond: you've picked a most unfortunate counter-argument. I have a lot of respect for you and I'm sorry to be so blunt, but but consider what you wrote:

      Is a Path a kind of String? Yes. Can I choose to implement a Path class as a subclass of String. If we follow the LSP then the answer to the second question is no and I must delegate all string-like methods...

      A Path is a kind of String? By no stretch of the imagination is a path a type of string. A path represents a place on a disk. A directory structure is a tree and a path could be considered a limb on the tree, or a series of inodes, but a string? Now you're forcing an metaphor on people which may not be appropriate. When I cd into a directory, I'm not concatenating two paths. I might be pushing an inode onto a stack or moving to a new node on a graph or tree or something like that, but I'm not concatenating.

      In your argument, you are using a string as a metaphor for a path. If you want to do that, it's fine, but in this case, Liskov doesn't apply because your types don't match. You have forced a metaphor on people which may or may not be appropriate, but because you've no longer truly provided a subclass which is a more specialized version of the superclass, Liskov does not apply.

      To summarize: you describe a "parent class as metaphor" approach and not the "parent class as basic type" approach and since Liskov works well with types and not with metaphors, it's not fair to say that Liskov is nonsense. It's just not appropriate in your case.

      • I should point out that in the real world, hierarchical representations don't always work and that's part of the reason why Liskov can seem problematic. It's one of the many limitations of OO which causes people to misunderstand many fundamentals. That's why I'm so bullish on roles. I suspect they can help lead the way out of the OO mess we're in.