[Prev][Next][Index][Thread]
Re: SICP & the Dumbing Down of American Comp Sci
-
Subject: Re: SICP & the Dumbing Down of American Comp Sci
-
From: Rob Myers <robm@lostwax.com>
-
Date: Fri, 15 Oct 1999 09:00:12 -0400 (EDT)
-
Organization: Lost Wax Media Ltd.
-
References: <7sp42b$71a$1@nnrp1.deja.com> <Pine.LNX.3.96.991001182426.1056I-100000@punaluu.informatik.uni-freiburg.de> <7tg1qu$49c@bobs.unbc.ca> <7tg98a$fo6$1@cronkite.cc.uga.edu> <37fbbc76$0$221@nntp1.ba.best.com> <pRPK3.3500$ns6.42632@ha1> <m3905ft7iz.fsf@soma.andreas.org> <Mi4L3.3782$ns6.48522@ha1> <m36709fzwz.fsf@soma.andreas.org>
-
Xref: grapevine.lcs.mit.edu comp.lang.functional:15533 comp.lang.dylan:10985
There's a good article on JavaWorld from a few months back regarding what
Objects are. One of its conclusions is that Objects are collections of
capabilities.
http://www.javaworld.com/javaworld/jw-07-1999/jw-07-toolbox.html
Whilst this might at first seem to go against the Dylan/CLOS data-object model,
stepping back it is clear that it is actually in-keeping with the Generic
Function approach of concentrating on (to mis-quote Andreas) the domain of
capabilities of a Generic Function, rather than hacking structs.
- Rob.
Andreas Bogk wrote:
> Basically design for those languages should focus on what your objects
> (in the sense of aggregated state) are and what you want to do with
> them (which gives generic functions). So instead of focusing on the
> objects and just treating the methods of that object as a detail of
> that object, you treat generic functions as entities in their own
> right.
>
> This doesn't contradict abstraction. In objects, the abstraction is
> represented through inheritance (so if I look at the state of an
> object, I'm ignoring the bits of that state which are not interesting
> to me by looking at the right level in the inheritance tree), in
> generic functions, it is represented by the domains of the methods of
> that function.
References: