DylanThinking: How to explain it?
Peter Robisch
or
How Dylan weaves together functional and object-oriented
thinking in an elegant way.
Yesterday on the #dylan channel Bruce Hoult in a discussion with Mike
Austin has given a very enlightening example about DylanThinking with a
very short code snippet:
let names = map(person-name, people)
The code takes a list of people and return a list of their names.
This code snippet reflects several points vital to the DylanThinking:
(1) use higher-order function whereever possible.
(2) use the OO-style of dylan
(A class encapsulates slots.
Slots are not fields, but functions)
(3) Dylan separates the code in several modules,
but has only one namespace.
(To avoid name collision when using a functionality
from other modules Dylan requires a renaming during
the import process).
To dive into DylanThinking requires to read this from the end:
(3) Dylan has only one namespace
(2) Dylan allows to use the slot accessor function
of a class directly. (As shown in the short code
snippet above).
Most languages would require that you create an
anonymous function before you can use a higher-order
function on a class slot.
(1) Dylan simplifies the use of higher-order function
in the context of classes.
So Dylan does in an elegant way weaves togehter
the functional and the object-oriented thinking.
IMHO, for anyone who likes to dive into DylanThinking the statement of
Bruce is very central.
It should be part of the Dylan Wiki.
I claim for a section: DylanThinking - How to explain it? on the
DylanWiki. This topic: "How Dylan weaves together functional and
object-oriented thinking in an elegant way."
would be one of several subtopics.
I tried here to rephrase Bruce statement for an audicene familiar with
the idea of higher-order functions, but unfamiliar to Dylan. In the
appendix I have attached the original discussion.
Please comment the text to improve it for the DylanWiki.
Greetings, Peter
APPENDIX The original discussion between Bruce and Mark.
========
<MikeAustin>
if I create a method "do-it" for two separate classes, with different
number of arguments, wouldn't I have to rename the methods that cause a
collision?
<brucehoult>
is it suppposed to be semantically the same do-it in each class?
if so, then they should have compatable argument lists.
if not, then you should use modules to separate them, just as you
would in C++ using namespaces
<MikeAustin>
Don't get me wrong, so far I love Dylan. I always seem to find ways to
abuse a language.
<brucehoult>
calling unrealted things the same name is bad
<MikeAustin>
they could be completely unrelated classes, with methods of the same
name, but used in the same source file.
<brucehoult>
if they're completely unrelated then they shouldn't be *defined*
in the same source file.
If, despite that, you want to *use* them in the same source file then
you can rename one of the methods (or both) on import possibly by
prepending or appending the module name, or some abbreviation of it
<MikeAustin>
hmm, maybe I just don't know Dylan well enough. That's the point, you
have to manually rename conflicing methods.
<brucehoult>
that makes the resulting code clearer to read.
Dylan *is* a bit unusual in having only one namespace.
Most people find that not having struct field names in different
namespaces is the surprising and frustrating thing that is most
likely to cause collisions.
It does allow some pretty nice things though
e.g.
let names = map(person-name, people)
to take a list of people and return a list of their names
<MikeAustin>
hmm. I see.
<brucehoult>
most languages would make you create an anonymous function to give
to map, whereas in Dylan you can just use the existing
slot acessor function
<MikeAustin>
thanks, and I'll learn sooner or later. :)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG