Re: wishlist : structures
- Posted by Irv <irv at ELLIJAY.COM> Nov 07, 2000
- 497 views
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