Re: wishlist : structures

new topic     » goto parent     » topic index » view thread      » older message » newer message

On Tue, 07 Nov 2000, David.Cuny at DSS.CA.GOV wrote:
> =A9koda wrote:
>
> > Two good reasons why structures are needed:
> >
> > - More stable code (acessing sequence members
> >   that don't exist causes error now)
>
> Following Robert's argument that 'quietly initializing variables to zer=
o' is
> a bad thing, I would expect an error if I tried to access sequence memb=
ers
> that don't exist.

If structures were properly implemented, the error would come _prior_ to
running the program ( "coord.X has not been declared" )
There's no way to trap that error if you are referring to it as coord[2],
except at run time - and then, only if the sequence being passed
doesn't  happen to _have_ two components.

 > > - More easy and organized programming
> > (my[3] turns to my.width)
>
> Currently, one of the biggest problems with named indexes is namespace
> collisions. I don't see adding namespaces as making this a lot nicer; w=
ith
> namespaces, you would write:
>
>    my[rect.width]
>
> This isn't compellingly better than:
>
>    my[RECT_WIDTH]

No, but when _declaring_ the variables, we would gain a lot. Those consta=
nts
RECT_WIDTH =3D 1, RECT_HEIGHT=3D2, etc.. look ugly, cause namespace colli=
sions -
and will continue to do so,  if two "structures" in the same file need th=
e same
index name ,such as the ubiquitous X or Y, but MAINLY theycause problems =
when
adding or deleting members from "structures":  Suppose we have:

NAME =3D1, ADDR =3D 2, CITY =3D 3...........etc with perhaps 30 - 60 fiel=
ds, for my
usual work.  OK, now we need to add a second address line.
1. Do we renumber everything from 2 thru 60 ? (tedious, error prone)
2. Add it as the last item in the  sequence, ADDR2 =3D 61 ? (stupid)

How much nicer if the language were smart enough to enumerate for itself =
the
items in a structure,  when you declare the item's name. e.g:
struct customer =3D
 {name,
   addr,
   city,
   ... and so on}

Even a "toy" language like Pascal can manage this.
And, local name collisions are no longer a problem - commonly used names =
can
take on different values _within_ the same file:

structure point
   x : integer;   {x is  point[1]}
   y : integer;
    ....
structure label
   text : string;
   x : integer; {x is label [2]}
   y : integer;
.....
>
> Personally, I'm leaning toward implementing them as associative lists (=
like
> JavaScript or Python).

Associative lists are nice for such things as keyword lookups, but
please tell me that I won't have to store "name" , "addr", .... once for =
each
customer "record" I add to my customer file.  Even if I could somehow thi=
nk
up 60 meaningful but short  (4-letter or less) keywords for the "fields" =
in my
customer database,  I'd still be taking up 240 extra bytes for each recor=
d,
which would  add approximately 50% to the size of the data files, 50% to =
the
load time,  etc....

> Another feature that people want is for structures to map into C struct=
ures.
> This would make it easier to interface to the 'outside world' via DLLs.

Yes.

> -- David Cuny

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu