[Prev][Next][Index][Thread]
Re: MI: why?
Classes as a concept don't have to contain methods,
and indeed even in C++ you can view a virtual method
as an entity that stretches down through the class
hierachy. Syntactically in C++, you implement
(non-inline) member functions outside the class
curlies, and then you have friend functions...
I *love* Dylan's Generic Function system. Current OO
thinking seems to regard Objects as consisting of
funtionality, not data. Priviledging methods/functions
equally compared to data objects makes this world-view
easier to express (strangely) as functions don't hang
off data so much, and I feel it gives a more balanced
view of the world.
Java's broken, broken, broken "OK, you've inhehited
ten ABCs now code the funtionality" interface system
is soooo weak (I program Java for a living). MI can
save time and effort, make elegant designs or be
mis-used like anything else. :-)
- Rob.
--- Scott Ribe <sribe@miqs.com> wrote:
Side note: I'm having difficulty finding my around the
Dylan libraries
because the methods are not contained in the classes!
But I don't think
this is an inherent flaw in the way Dylan libraries
are structured. I
think it's just a temporary thing while I get used to
a paradigm that
is
different than the one that I'm used to. I've used
different OO
languages and libraries, but for more than a decade
(closer to 2) I've
always thought of methods as being part of classes. My
problem with SI
libraries is not a problem with expectations or
perception; it is a
problem with the overly-complex structure of those libraries.
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
Follow-Ups: