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
several minutes ago. We don't need no stinkin' tactical nukes.
(By the way, do you have change for 10 million people?) --lwall
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Re: Duck Typing! (Score:1)
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
Re: Duck Typing! (Score:2)
Duck typing is a separate issue. The issue here is something like this:
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.
Reply to This
Parent
Re: (Score:1)
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
Re: (Score:1)
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
Re: (Score:1)
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.)