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.
  • my $subpattern = shift; return $pattern->{payrate} * 40;
  • 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.

    • Your Turing Medal is in the post

    • I agree that treating it as an absolute rule is nonsense. But the basic principle - that you should be able to expect that objects of a subclass can be safely used in place of objects of a class - is sound. Furthermore in complex OO code it is common to have subclasses accidentally override methods of parent classes that they did not know about. And these cases area almost always real bugs.

      Therefore the Liskov Substitution Principle is a rule of thumb to be aware of, and there is value in catching accide

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

  • isn't this the problem that dynamic or duck typing solves!

    where you declare a method you don't say what type you want to go in. the documentation though would have the attributes needed from the object to perform the task or work asked to it by the method

    Ocaml, I believe have a way to declare the attributes the objects needs to have regardless of his class or type, so i think they are half way between static and dynamic sub-classing in my opinion should be only used as a purely technical method to sh
    • Duck typing is a separate issue. The issue here is something like this:

      while ( my $thing = $foo->next ) {
          $total += $thing->value;
      }

      You want value to always return something suitable for addition. In Perl, it's awfully tough to make this "just work". As Ben Tilly points out, this shouldn't be a global "you must always ..." debate, but the general principle is sound.

      • okay, I am not sure why making sure that value always returns something suitable for addition is a big deal.

        first of all, you should not try to modify value directly, you should ask $think to modify value for you

        second if $thing know how to perform addition on value, $thing will comply

        there are so many ways to know if $thing can perform addition on value

        1. ask $thing if he is of a certain type
        2. ask $thing if one of his ancestors is of a certain type
        3. according to your liskov, ask $thing if one of his deri

        • The principle is that if an OO class supports a given internal and external API, then any subclasses should support that API. If the parent class promises that a given method returns something that can be added, then subclasses should do likewise. If the parent class makes errors available through a particular mechanism, subclasses should do likewise. And so on.

          In short one should be able to use an object blessed into the subclass instead of an object blessed into the parent class and nothing should brea

          • The principle is that if an OO class supports a given internal and external API, then any subclasses should support that API.

            Nitpick: the principle talks about subtypes, not subclasses. This is an important distinction, as subtyping relationships do not require inheritance. (I see that someone has proposed merging the LSP page into the Inheritance page on Wikipedia. That disappoints but does not surprise me.)