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

Igor Stasenko siguctua at gmail.com
Tue Jun 30 04:55:34 UTC 2009


2009/6/30 Cameron Sanders <csanders.personal at functional-analyst.com>:
> 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!
>

Don't take a 'trait' word literally. I didn't mean an implemetation
specific Traits (introduced in Squeak 3.9)
but rather some 'label' which you, as developer want to put on some
kind/group of objects.
The main point is, that often, such labels not in sync with class
hierarchy (imagine you could treat a Number subclasses and
DatabaseConnection subclasses as objects which share some common
trait).

But of course, my #is: proposal lays perfectly on Traits basis.
If you implement this method in Trait, and then use this trait in
multiple different classes - then it will work exactly as i
describing.

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

you can put an extension method to any class, by putting it into a
category named by your package name, prepended by '*' character:

*MyPackage


> 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!
>
You welcome :)

> Cheers,
> Cam
>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list