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

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