[squeak-dev] Future of Squeak, and outsider's view

Cameron Sanders csanders.personal at functional-analyst.com
Tue Jun 30 04:23:53 UTC 2009


Oh... ... oh... the CVLambda class was/is trait based. Confession: I  
haven't done my homework on traits. That might explain a little!

I was not aware of the rules/origin for #is:  -- thank you!

<more down below>

On Jun 29, 2009, at 11:59 PM, Igor Stasenko wrote:

> 2009/6/30 Cameron Sanders <csanders.personal at functional-analyst.com>:
>>
> The concept of #is: are: When object foo having some trait, it should
> answer true on 'foo is: sometrait ', otherwise false.
> Obviously since most subclasses inherit the behavior & traits of base
> class, you should honor this rule in overrides of #is: method
> i.e.:
>
> Someclass>>is: object
> ^ (your tests here) or: [ super is: object ]
>
> otherwise, if you omit the super send, some of the traits will become
> unavailable. But of course, except when you doing this intentionally.
>
>
>> I'll have to go back to the original example (by  
>> siguctua at gmail.com, and
>> read more about lambdas) but I thought that CVLambda would implement
>> #isCVLambda  to return true when it can be verified to be one. The  
>> example
>> did not illustrate #doesNotUnderstand:.
>>
>> Back to the question of adding behavior to classes that you don't  
>> own.
>> VisualWorks has a means to extend a class in a different  
>> package ... as I
>> recall. As I recall, squeak has no such capability, right?
>>
>
> MC having this capability for a years.

So how do I do extend a class. Simply define it again for a given  
package?

I did not know this was in Squeak.

Again, thank you... now I am glad I offered up answers to things I  
didn't understand!

Cheers,
Cam




More information about the Squeak-dev mailing list