[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
|