Object>>#is:? (was: Re: PackageDependencyTest)

Andreas Raab wrote:

On 3/4/2010 12:33 PM, Juan Vuletich wrote:

I believe #isKindOf: is really bad. Reasons for this are given in
http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf . This was
also discussed here, you can google for the name of the pdf in the
archives.

In the Cuis implementation of Object>>#is: there is no call to
#isKindOf:. The idea is to ask for a protocol, not for inheritance.

But inheritance implies protocol. There is nothing wrong with asking for protocol conformance based on inheritance; it is the same as implementing isNumber in class Number for the purpose of having subclasses inherit that.

The implementation that I've proposed is making that point. Thus (42 is: #Number) returns true, since 42 conforms to the Number protocol. If you had some other class that conforms to the number protocol without subclassing it, it is free to implement, e.g.,

ComplexNumericRepresentative>>is: aSymbol
   "I conform to the number protocol"
   ^aSymbol == #Number or:[super is: aSymbol]

As a consequence, the #is: test is not an inheritance test at all.

Cheers,
 - Andreas

What you say is right. The reasons for me not doing it that way are perhaps subtle and aesthetic. I prefer making it as clear as possible that this is not about inheritance but protocol.

I also think that my approach is easier to explain and understand. Besides I don't like it looking like there are "special" or "privileged" classes or hierarchies. Perhaps more important, I prefer not having "implicit" protocol conformance without anybody declaring (for example) that #BorderedMorph is now considered a protocol. In addition, I believe that this should be used only when really needed. In general, a better design might make all these queries unneeded. So, forcing people to declare their protocols might discourage abuse.

Anyway, I think both solutions are acceptable and it comes down to taste.

Cheers,
Juan Vuletich

On 5 March 2010 06:37, Colin Putney <[hidden email]> wrote:
>
> On 2010-03-04, at 1:18 PM, Stéphane Rollandin wrote:
>
>> I got it; see my answer to Juan. I guess I'm just programming in bad style: I do indeed consider that Object is part of my packages (or, more accurately, that Object is not a forbidden place for my package to go in).
>
> Hear hear. I've been wondering why people are so enthusiastic about #is: - good to see I'm not the only one.
>
> I think #isA: is fine, as an easy way to do #isKindOf: without a direct class reference. Being able to avoid class references makes it easier to avoid dependencies, which makes it easier to have a modular system.
>
> Juan's implementation of #is: puzzles me though. It replaces polymorphic dispatch with boolean logic. Good OO design generally goes in the opposite direction.
>

Agreed. But then expect an Object class to have thousands of isXXXX
methods, since we having way many things which we can imagine and may
want to model them. Then the Object class will become a flat space of
system-wide methods. Is this what can be called good OO design which
using polymorphic dispatch?

> Furthermore, Juan's version of #is: makes it more difficult to modularize the system. If I write a package that needs to add the concept of "greenness" to the system, I can add #isGreen extension methods wherever I want, without breaking any existing code. Somebody else can add #isPurple methods without breaking my code. But if we both need to override #is:, we have a gratuitous incompatibility.
>

But you are still free to do that, so what the problem?
But in 90% of cases, i think you can use #is: method , without the
need of adding extensions anywhere, because the only reason why you
adding it is to be overridden in subclass, which belongs to your
package.

> Note that #is: may work well in Cuis, but that's because Cuis is *not* a modular system.
>
> Finally, I also want to point out that "simpler" and "fewer methods" are not the same thing. Methods that answer booleans are dead simple to understand, no matter how many of them there are. A single #is: method increases incomplexity as the number of tests it encompasses increases.
>

I disagree. Adding a new protocols and corresponding way to test a
conformance to it - this is what increases system complexity in a
first place. The #is: method by itself puts zero weight into it, if
you not using it.

> So, consider this moral support for Stéphane, since he seems to be beset on all sides. Also,
>
> +0 for #isA:
> -1 for #is:
>
> Colin
>

--
Best regards,
Igor Stasenko AKA sig.

On 2010-03-04, at 1:18 PM, Stéphane Rollandin wrote:

> I got it; see my answer to Juan. I guess I'm just programming in bad style: I do indeed consider that Object is part of my packages (or, more accurately, that Object is not a forbidden place for my package to go in).

Hear hear. I've been wondering why people are so enthusiastic about #is: - good to see I'm not the only one.

I think #isA: is fine, as an easy way to do #isKindOf: without a direct class reference. Being able to avoid class references makes it easier to avoid dependencies, which makes it easier to have a modular system.

Juan's implementation of #is: puzzles me though. It replaces polymorphic dispatch with boolean logic. Good OO design generally goes in the opposite direction.

Furthermore, Juan's version of #is: makes it more difficult to modularize the system. If I write a package that needs to add the concept of "greenness" to the system, I can add #isGreen extension methods wherever I want, without breaking any existing code. Somebody else can add #isPurple methods without breaking my code. But if we both need to override #is:, we have a gratuitous incompatibility.

Note that #is: may work well in Cuis, but that's because Cuis is *not* a modular system.

Finally, I also want to point out that "simpler" and "fewer methods" are not the same thing. Methods that answer booleans are dead simple to understand, no matter how many of them there are. A single #is: method increases incomplexity as the number of tests it encompasses increases.

So, consider this moral support for Stéphane, since he seems to be beset on all sides. Also,

+0 for #isA:
-1 for #is:

Colin