Every classes has required selectors

Hi,

every classes in the system (3.9) have required selectors which means
every classes are abstract! This is not cool.

My dynamic protocol display them but I don't like that and I think I
will hide them.

Here are the required selectors for Object and Class:

Object requiredSelectors
     an IdentitySet(#copyUniClassWith: #slotInfoButtonHitFor:inViewer:
#adaptToNumber:andSend: #contents: #step #readFrom:)

Class requiredSelectors
     an IdentitySet(#copyUniClassWith: #slotInfoButtonHitFor:inViewer:
#adaptToNumber:andSend: #contents: #step #sendCaches: #soleInstance
#readFrom:)


Bye

--
Damien Cassou

2006/9/22, Damien Cassou <[hidden email]>:
Bah. Imagine every class in Java was abstract. I can already see then
endless amount of flames and disses. It would always the mentioned as
one of the (other endlsess) bad points of Java. Every class in Squeak
is abstract? Well, that's just the way it is .....

Probably soon some post will that this is not problem at all.

Philippe

Please don't hide it - allow these design bugs to be fixed.

Daniel

Damien Cassou wrote:

>>>>> "Daniel" == Daniel Vainsencher <[hidden email]> writes:

Daniel> Please don't hide it - allow these design bugs to be fixed.

I'm unclear about why you and the additional poster think these are "design
bugs".

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Philippe do not be that cynical. I know you :)

We can fix that this should not be a problem.
But for now in 3.10
stef

Damien Cassou a écrit :
Strange why a so specific set (IdentitySet) is used? Symbole are always compare with identity.
Is there any particular reason of this?

Thanks
        Math

Randal L. Schwartz a écrit :
>>>>>> "Daniel" == Daniel Vainsencher <[hidden email]> writes:
>
> Daniel> Please don't hide it - allow these design bugs to be fixed.
>
> I'm unclear about why you and the additional poster think these are "design
> bugs".

Because the selectors listed are sent but not implemented. This means
that some method are implemented in Object but you can never call them
because they refer to unimplemented methods.

--
Damien Cassou

Daniel Vainsencher a écrit :
> Please don't hide it - allow these design bugs to be fixed.

I don't agree with you. Only a very few people will be interested in
those methods (one or two persons will be responsible for fixing this
bug). But it will annoy all users of DynamicProtocols. In the big
majority, people only want to see the required protocol displayed if
they effectively need to implement something in their class. This is not
the case for the previous methods.

If you are interested in seeing them, you can still modify the method
DPRequired class>>hiddenRequiredSelectors.

Bye

--
Damien Cassou

Damien

please do not hide them.
We should fix that.
Hidding them is like putting dust under the carpet.
Let us clean the house!

Stef

On 22 sept. 06, at 18:45, Damien Cassou wrote:

A user (reader) of Object is being exposed to a complexity of Morphic
(step) eToys (slotInfoButtonHitFor:inViewer:) and numbers (adapt...). If
these were class extensions allowing some functionality to be accessed
(String>>asUrl), then maybe it would be worth it. But the only reason
these methods are there, AFAICT, are that this code was written before
Traits were available, so the only way to allow any class to step
without imlementing the framework in it, or using up its one inheritance
slot was to put the framework into Object.

Such frameworks can now be placed each in a Trait, and composed in by
those classes that choose to implement the required method.

Making all classes seem abstract because of this misplacement is the
wrong solution, and hiding this workaround using another workaround in
the tools is also the wrong solution.

Daniel

Randal L. Schwartz wrote:
>> "Daniel" == Daniel Vainsencher <[hidden email]> writes:
>>    
>
> Daniel> Please don't hide it - allow these design bugs to be fixed.
>
> I'm unclear about why you and the additional poster think these are "design
> bugs".
>
>