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

        • by btilly (5037) on 2009.04.01 23:29 (#67989) Journal

          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 break. Put an alternate way, something of the subtype ISA thing of the parent type, and any guarantees that are supposed to hold for the parent type need to hold for the subtype.

          Nothing technical enforces this. You are able to inherit from a parent class, override any method you want, and change the behavior to be what you want. But if you do this, then your inheritance relationships are now telling a lie. You have violated expectations in a way that is likely to cause code to break in nasty ways that is likely to be hard to debug.

          So as a first rule, Don't Do That. For the experts I'll amend that to Don't Do That Without Careful Thought And Good Cause. If you're unclear on why this is important, then you're a novice who can't judge what good cause is, and therefore should follow the simpler version of the rule.

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