[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

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)