Hi Eduardo,

You have a point here.

However, suppose two libraries both wish to define a method named  
'foo' on an existing class, such as integer or string... message  
passing won't handle that so well :)

I think message passing is better suited to problems where you have  
control over the data types.

Slava

On 13-Aug-07, at 12:58 AM, Eduardo Cavazos wrote:

> Slava,
>
> Nice job on the object system and mixins! I like what I see.
>
> However, I need to come to the defense of message passing systems  
> on one
> point. (Slava already knows all this as we've discussed it before. I'm
> mentioning it for the record as an "open problem")
>
> In smalltalk, each class acts as a sort of namespace for the names  
> of methods.
> So there's no problem with names of methods from different classes
> conflicting. This is a problem with Factor's generics however  
> because the
> namespace for words is at the vocabulary level, not the "class" level.
>
> If you have two classes that would like to have a method 'foo', but  
> it doesn't
> make sense for them to have the same generic, and moreover, perhaps  
> the
> effects are incongruent, you must do GENERIC: foo in each of the class
> vocabularies. If you never call the two differnt foo's from the same
> vocabulary, then there's no problem. But if you need to, you have  
> to do bad
> things like:
>
>       USE: apples
>
>       ... use foo here
>
>       USE: oranges
>
>       ... use foo here
>
> I think what most people would do in that case is to define the foo  
> generics
> like so:
>
>       GENERIC: move-apple
>
>       GENERIC: move-orange
>
> Whereas in Smalltalk, it's perfectly natural to do:
>
>       anOrange move
>
> or
>
>       anApple move
>
> To me, qualifying method names with prefixes to work around  
> namespace issues
> is ugly. It's one area where "message passing" isn't beat.
>
> Ed
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Factor-talk mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/factor-talk


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Factor-talk mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/factor-talk

Reply via email to