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
