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.

Programmatic Enforcement Of Liskov Substitution Principle 3 Comments More | Login | Reply /

 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 c

      • 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.

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.