[squeak-dev] Re: Object>>#is:?
siguctua at gmail.com
Sun Mar 7 06:01:09 UTC 2010
On 7 March 2010 07:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> On Thu, Mar 4, 2010 at 10:16 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> On 5 March 2010 06:37, Colin Putney <cputney at wiresong.ca> 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?
> I think this is alarmism. There may be 10's, even 100's but 1000's? Take
> for example the is methods in the parse node hierarchy. Object need only
> implement isParseNode, then ParseNode is where the various specifics such as
> isReturnNode. So the number of is methods in Object can grow to the number
> of domains, not to the sized of those domains. We already have a few (often
> indispensible) specifics such as isNil. But as domains grow we can be more
I am trying to find a way to not repeat myself, when coding.
If i need implement, say 10 isXXX methods during the year, then count
here others, who also has to implement their own.
Sure thing, not all will find their place in Object. But still this
pattern can be found all over the places.
That's fun, when Colin says that #is: 'replaces polymorphic dispatch
with boolean logic'.
But hey, this is not true. It doesn't replacing polymorphic dispatch,
it is the coder who replacing it, when writing:
object isFoo ifTrue: [ self doSomething ] ifFalse: [ self doOtherThing ]
(object is: #Foo) ifTrue: [ self doSomething ] ifFalse: [ self doOtherThing ]
object doSomethingWith: self
>> > 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
>> > 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.
Igor Stasenko AKA sig.
More information about the Squeak-dev