[REBOL] Re: Rebol Fluid
From: chaz:innocent at: 10-Dec-2000 2:49
You were talking about a REBOL "Fluid", how about an "Sea"?
There's a group called KOSH, "Kommunity Operating System and Hardware" and
they're trying to figure out how to implement something they call the
Object Sea
. It would be a very different way of interacting with a computer.
Seems to me that maybe this could be implemented using some kind of
combination of REBOL/Command and REBOL/View...
<crossposting>
Date: Tue, 14 Nov 2000 17:48:18 -0500
From: Dave Haynie <[dhaynie--jersey--net]>
To: "kosh List Member" <[kosh--chaossolutions--org]>
Subject: [kosh] Ideas :)
X-Mailer: Becky! ver 1.26.03
X-Return-Path: [List-Admin--chaossolutions--org]
X-MDMailing-List: [kosh--chaossolutions--org]
X-MDSend-Notifications-To: [List-Admin--chaossolutions--org]
Reply-To: [kosh--chaossolutions--org]
X-MDaemon-Deliver-To: [chaz--innocent--com]
On Tue, 14 Nov 2000 23:22:03 +0100 (CET), Marcus Petersson
<[d4marcus--dtek--chalmers--se]> jammed all night, and by sunrise was overheard
remarking:
> On Sun, 12 Nov 2000, chaz wrote:
> > Tell me a story, paint a picture in words, of what the Object Sea would
> > "look" like to a user in front of it.
> That's a pretty large request, but I guess it has been long overdue. :-)
Well, I think, from the casual user's point of view, the Object Sea is
not really something normally all that obvious. After all, are you
necessarily presented with functions, procedures, and libraries in the
normal, user-level experience in AmigaOS, Windows, MacOS, Linux, etc?
> Basically, the Object Sea is a collection of objects. You can have many
> different views of it. One view is the hierarchial one - it's a tree with
> a root, branches and leaves (or nodes). The root object is the grandparent
> of all other objects, and in a way it also contains all of them. This is
> actually what we call the Object Sea (or Cybersea as it's called elsewhere
> - a silly name in my opinion).
I coined the "Object Sea" phrase, that's how I've thought of the concept
for the last 10 years or so. Anyone's free to come up with a better
description.
Anyway, for programmers, what you say is somewhat true, in that classes
are objects (at least in my model).
But in a user's experience, you can still think of "files" if you like.
An object sea based OS could still seem to have a perfectly ordinary user
file structure. The difference is salient, but perhaps not something the
user ever cares about. In fact, one major point of the object sea idea is
to make things easier on the user.
Since everything is, in fact, an object, the user can directly do things
with any object, and something meaningful nearly always happens. For
example, if you click on an object, it'll probably either run or display
itself. If you drop a data object into a running program, it'll try to do
something useful -- directly, if the application knows that object
interface; via system level translators if this isn't the case (for
example, you could write a translator that does "image to text", and from
then on, any text file dropped into a graphics program would render
graphically as text, best as possible).
Stuff that, really, lives above the object sea would give rise to the
user's interactive experience. For example, what's the default action
when you click on a data object? In the Mac and BeOS world, this is
usually going to mean "launch the 'parent' application". But I don't
believe in parent applications; or more specicially, single ones. I guess
that's something I learned on the Amiga with graphics, and continue to
experience on the PC. So I would have the default method be "display"
(technically, you're sending a "mouse-click" method to the object, but
most will translate this into object-centric default actions).
When you call up a "display", you get what I call a "pad", a very basic
box for holding some kind of image, movie, sound, etc -- less than a
window. If you just clicked on a JPEG, you'd get that pad in a window. If
you dropped it into an application, the OS would provide the message of
object dropping. If the app handles the object type directly, it gets the
object. Otherwise, the OS builds a pad for that, which is handed to the
application (most applications would handle pads).
When you have a pad, anywhere, objects can be dropped into it, too. For
example, if I clicked on that JPEG alone, I would have a pad with the
JPEG image running in it. Let's say I then drag a "DPaint XIII" object
into that pad. The expected result would be that the DPaint tool bars
dock on an edge of that pad, and immediately, the image is made much more
active, under the rules of DPaint. If I then dropped "Imagine 10" onto
the pad, it, too, would fire up its control panel. Multiple apps on the
same pad would grow some kind of "activation box" -- you'd click on that
to make the associated app the one immediate to the pad (after all, you
can't have two sets of rules applied, unless they're somehow
complementary applications -- in a sense, a master and a plug-in).
> Every other object is a child of a parent object, it inherits its parent's
> propererties, but usually also include some characteristics of its own.
Well, yes and no. A class object contains a mix of data and methods,
which you could calls its characteristics. Class objects create instance
objects, which typically add additional, instance-specific data, but
rarely new functions. These are instances of said class object, not
children.
You can also create a new class object which inherits methods and global
data from one or more existing class objects, and extends these in some
way, either by making an interesting mesh of multiple classes, or perhaps
adding new, more focused/specific, or just plain different methods. This
is what you'd probably call a child object.
> The common user collection object is called a set. It differs from a
> directory foremost in being an object (which can be powerful enough), but
> also in that it can have attributes.
Here, I disagree. For one, a "set" has certain mathematical connotations
I don't think you want here.
A very, very basic feature of my abstract object model, which gave rise
to the whole object sea concept, is the notion of container objects: you
can have an object which can hold, in some reasonable way, other objects.
Methods on a container object can be things like add, delete, list, sort,
etc. More sophisticated operations include things like method broadcast
(eg, send a method to every object in the container), which forms the
basis for "translucent" containers. In a translucent container, the the
container plus contained takes on something of the appearance of an
object of both classes, but of course, it's dynamic. The simplest type is
basically a container than handles its own methods but broadcasts all
methods it doesn't understand.
When you have container objects, and you know that everything stored on
disc is inherently an object, it's easy to see that the equivalent of a
directory in a file system is nothing more than a container object,
perhaps optimized for some specific use.
--
Dave Haynie | V.P. Technology, [Met--box] AG | http://www.metabox.de
------------------------
To unsubscribe - post to [mdaemon--Chaossolutions--org] with Unsubscribe kosh
as the only line in the body.
Problems, complaints - [List-Admin--chaossolutions--org]
Web site - http://kosh.convergence.org
</crossposting>
At 09:05 PM 12/6/00 +1300, you wrote:
