2009/6/30 Eliot Miranda eliot.miranda@gmail.com:
On Mon, Jun 29, 2009 at 8:59 PM, Igor Stasenko siguctua@gmail.com wrote:
2009/6/30 Cameron Sanders csanders.personal@functional-analyst.com:
What you write (down below) is close to what I was thinking when I said have all #isXXX return false by default; although I would test that the first two characters match 'i' and 's' and that more characters exist, if so, return false, otherwise, normal #doesNotUnderstand: behavior.
I would treat #is by itself differently... it is ... or it couldn't be tested! So I would do nothing for simple #is. and I don't like #is: because it looks like a class type test... but that is part of the point, eh?
I wouldn't say that. It is more trait-based approach than class-based.
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@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.
Arguably not. (BTW VW has had it from 98). The crucial difference is that in VW an extension can be in more than one package. In Squeak a selector can only be in a single Monticello extension category. That leads to the awful bug that when an MC package patches a base selector to extend it to fix a bug it ends up in the package and its membership of the package it was in previously being lost. I understand that with method history this situation can be detected but if you e.g. condense changes then that history is lost, and the base package selector becomes only an extension Ouch. The VW "solution" is OK as far as it goes; a package is a set of class, selector pairs (more than this, but this is the essence). An MC package is defined by class and method categories. VW's parcels are intensional, MC packages are extensional. There's a tension in both; many VW'ers want, at least at the UI level, for packages to be extensional, but precision (knowing whether something is in a package or not, allowing things to be in more than one package so that one can include patches, etc) requires an intentional construct. When you also provide selector namespaces I don't think the situation changes because one still needs patches in the absence of a perfectly designed system. So IMO somehow MC needs to move to an intensional package definition, at least for extensions ;)
i just wanted to point that MC having an extension mechanism. Yes, it is different from VW one. And in the light of your description - it is done wrong (at least for me), but its still can be called 'extension mechanism' :)
Thanks. You have given me food for thought...
Ciao, Cam
On Jun 29, 2009, at 3:43 PM, David Goehrig wrote:
What I typically what I've been doing to eliminate all of these methods with a single simple change:
Object doesNoUnderstand: aMessage ^ false
-- Best regards, Igor Stasenko AKA sig.