Re: [ba-ohs-talk] Node Object model; WAS: GUI Ideas and NODAL
To continue this strand...
Taking this model
Node <= {[Node <link> Node] && [Node <link> Node], ...}
Acually, each value node (2nd node in each pair) can be very effectively
represented as a child of the key node. So the top level node can just be a
vector of key nodes, and the child of a key node is a value node. (Hence my
plastering the term vector over previous mails. ;-)
That basic structure can handle map, struct, and sequence all with the same
interface.
Which means I can have a basic node that looks something like, (01)
(N.B. the following is pseudo-code of sorts.) (02)
class Node
{
private:
Enumeration e;
//ignoring any other frills for now (03)
public:
//yadayada...
} (04)
Then to handle the node type I just implement a modification of the Type
interface Jack just passed me
//in Java
public interface Type extends Nameable {
boolean accepts(boolean b);
boolean accepts(byte b);
boolean accepts(char c);
boolean accepts(double d);
boolean accepts(int i);
boolean accepts(Node v); //changed from Object to Node
boolean accepts(Date d); //added
//..and so on for all atomic types
// boolean accepts(String s); //needed if string is sequence of char?
Object as(boolean b);
Object as(byte b);
Object as(char c);
Object as(double d);
Object as(int i);
// Object as(Object v); //break this down into atomic types
// Object as(String s); //still needed?
} (05)
Then the atomic types are just restrictions (subclasses) of Node to hold a
specific type and to limit the number of entries in the vector.
e.g. (06)
class CharNode extends Node
{ (07)
private boolean full; (08)
public setNode(Object ch)
{
//setting stuff
full = true;
} (09)
//...etc
} (010)
Does that make any sense? Or am I way behind folks (Lee?) ? (011)
Cheers,
Peter (012)
----- Original Message -----
From: "Peter Jones" <ppj@concept67.fsnet.co.uk>
To: <ba-ohs-talk@bootstrap.org>
Sent: Tuesday, November 13, 2001 2:50 PM
Subject: Re: [ba-ohs-talk] GUI Ideas and NODAL (013)
> Lee Iverson wrote:
> > Convince me then. I've used systems (LISP for example) with very
> > simple, general building blocks and seen them evolve toward richer,
> > more targeted ones. It's a balancing act...
>
> Yes. I think I am looking at it from an access perspective, which is
> possibly not the view you are taking.
> So, I might well be missing something crucial.
>
> From an accessing perspective:
>
> Take Perl for instance.
> A hash (map/dictionary in other languages) in perl is accessed by
> $value = $hashname{$keystr}; #in perl
>
> No difference between that and a struct in perl really. In fact, perl
> basically deals with objects as hashes.
> So map and struct are definitely very similar, if you ignore the fearsome
> datatyping of certain other languages.
> Now, in NODAL, datatypes are a property set on the Node, but otherwise
> everything is treated as a Node object. Is that correct?
>
> So in a strongly typed language like C++ I might declare a map as
> map<Node, Node>; //in C++
> And if we escape from the specifics of the C++ language, me might well be
> talking
> Node <= {[Node <link> Node] && [Node <link> Node], ...}
>
> And to approach the sequence...
> float f = arrayname[index]; // in C/C++
> The difference between an array and the hash above is in the index for
> addressing. It's restricted to an integer value. Again in NODAL do we have
> to worry about datatyping in that structure?
> Node <= {[Node <link> Node] && [Node <link> Node], ...}
> So the only difference between a map and a sequence in terms of accessing
> the contents is the restriction on the key type.
> (And it wouldn't surprise me if that was what perl was doing under the
hood
> in reality when you use arrays.)
>
> Now, isn't it the case that in order to perform operations on Nodes, you
> have to check their datatype property after accessing them?
>
> So then, I think I'm really asking, if NODAL is above the particulars of
> datatyping in a specific programming language (is it?), then does it make
> sense to specify a uniform approach to the data storage that is
independent
> of the particulars of structs, maps, and sequences?
>
> Cheers,
> Peter
>
> ----- Original Message -----
> From: "Lee Iverson" <leei@telus.net>
> To: <ba-ohs-talk@bootstrap.org>
> Sent: Monday, November 12, 2001 9:21 PM
> Subject: Re: [ba-ohs-talk] GUI Ideas and NODAL
>
>
> > On Mon, 2001-11-12 at 12:58, Peter Jones wrote:
> > > >
> > > > Well, there are really a number of reasons to separate these out.
The
> > > > most obvious one in my mind is simply that manipulating these three
> > > > kinds of collections (from an object-oriented point of view) is very
> > > > different. The operations performed on a Struct, Sequence and Map
are
> > > > just completely separate. A Struct has a fixed set of fields and
one
> > > > may only assign new values to them. A Sequence has a set of items
of
> > > > uniform type and we can insert or delete subsequences or set
> individual
> > > > items. A Map indexes its values via keys of a defined type and we
can
> > > > either assign values to keys or remove keys. It is certainly true
> that
> > > > we could emulate these behaviours with simpler constructs, but then
we
> > > > would lose a great deal of the expressive power of our data
modelling
> > > > language.
> > >
> > > [ppj] Or you might gain a powerful generalisation, depending on what
you
> > > actually end up doing with the data.
> > > I see your point, but I'm just wondering whether it's possible to step
> > > beyond it by fixing aspects of the general (super)graph instead.
Perhaps
> it
> > > becomes too complicated.
> >
> > Convince me then. I've used systems (LISP for example) with very
> > simple, general building blocks and seen them evolve toward richer,
> > more targeted ones. It's a balancing act...
> >
> > > > Well, you are ignoring the fact that various systems define line
> endings
> > > > very differently (e.g. line ending semantics on MS vs. Unix vs. Mac
> > > > systems). The text encoding for exactly the same file is different
on
> > > > these systems but the data model is identical. (Properly then, the
> > > > "line" strings in such a file should exclude these line-ending
> > > > characters ("\r\n" in C parlance). That is not to say that you
can't
> > > > define a file type that is simply an undistinguished sequence of
> > > > characters for your own purposes. It's not what I have in mind
> though.
> > >
> > > [ppj] OK. Neat. I like the approach you're going for. But if that's
the
> > > case, why have you kept 'characters' as a primitive, and not just made
> the
> > > string type the primitive, leaving char[]'s up to the implementation
> > > concerned?
> >
> > I also want a general addressing mechanism and using the Node types as
> > the primitives for this allows one to address *inside* of strings just
> > as one would address inside of any other collection. The atomic types
> > are just that -- indivisible. We gain from having strings as a
> > Sequence, and don't really lose anything.
> >
> > --
>
> --------------------------------------------------------------------------
> -----
> > Lee Iverson
> > leei@telus.net #105-2700 Acadia Rd., Vancouver B.C. V6T
> > 1R9
> > http://www.ai.sri.com/~leei/ (604) 222-9312
> >
> >
>
> (014)