Lists Home |
Date Index |
- To: firstname.lastname@example.org
- Subject: Re: REST & types
- From: Gavin Thomas Nicol <email@example.com>
- Date: Fri, 1 Mar 2002 00:14:47 -0500
- In-reply-to: <200203010356.WAA22071@markbaker.ca>
- Organization: Red Bridge Interactive, Inc.
- References: <200203010356.WAA22071@markbaker.ca>
On Thursday 28 February 2002 10:56 pm, Mark Baker wrote:
> POST it a representation of some food, and it gets fed.
> POST it a representation of a hand, and it gets petted.
> (logically, of course 8-)
This is the point though... to a large degree all that's really
happening is decomposition/tunelling of higher-level communication
patterns on a lower-level substrate... there are advantages and
disadvantages to this.
> Yup. But everything that can be done by distributed computing can
> be done by distributed hypermedia. It's complete.
Sure... and all computation can accomplished using SK combinators.
One thing I've often done in developing object interfaces is to
essentially make everything a "bag" of properties (get/set/remove),
allowing arbitrary extension of "types" at runtime (in JAVA you can do
it through a custom classloader if you want). This can be very
beneficial (slot-based programming is similar BTW).
Anyone who's done this (especially if they're an old lisp hacker ;-))
will eventually question the need for objects/interfaces in the first
place... after all, the common substrate is all you need. The answer,
as it is for the applicability of anything, is "it depends".
Reductionism is fine (big fan of reductionism and minimalism in
general), but you also need the higher level of organization, and
labels to apply to them. Once you start operating at that level, the
underlying components become less relevant... that's the whole point
of abstraction. Once you start modelling higher-level applications
(working at a higher level of abstraction), will the choice of REST be
truly significant? Will the choice of REST using HTTP vs REST using
<whatever> be significant?