OpenEuphoria

Structures

• Posted by nonlerer at WEBQUEST.COM Feb 03, 1999
• 441 views

I have to agree about the value of structures.  I know that I can emulate
them using constants and sequences, but this kind of gets confusing in a
larger project, where the interpreter should enforce the record definition
anyway.  It would be nice to define a static structure layout (as opposed to
the wonderfully versatile sequence) that understands fieldnames:

<begin code>
record phonebook
  sequence name
  sequence address
  integer  zipcode
end record

phonebook pbAmy, pbMark, pbTom
sequence  AllPhoneBooks

pbAmy[name] = "Marc Anthony"
pbAmy[address] = "Alexandria, Egypt"
pbAmy[zip] = 11111

AllPhoneBooks = {pbAmy, pbMark, pbTom}
AllPhoneBooks[1][zip] = 22222
<end code>

Since a sequence of records is the same as any sequence anyway, why
complicate the issue with additional syntax for arrays of records?  Any
sequence should be able to contain a static record.  The only reason I want
these static records is so I can't accidentally change the individual
definition of the record.  I still want to be able to slice arrays of
records, and append and prepend them.

<begin code>
phonebook pbAmy, pbMark, pbTom
sequence  AllPhoneBooks, SomePhoneBooks

AllPhoneBooks = {}
AllPhoneBooks = append(AllPhoneBooks, pbAmy)
AllPhoneBooks = append(AllPhoneBooks, pbMark)
AllPhoneBooks = append(AllPhoneBooks, pbTom)
SomePhoneBooks = AllPhoneBooks[2..3]
<end code>

Use of records helps keep the code cleaner, removes fieldname confusion when
several types use the same fieldname, and simplify datafile i/o.

Notice that this would not specify the length of any contained sequences.
Do we really want to do this?  I'm not convinced.

<begin code>
record phonebook
  sequence name * 50
  sequence address * 50
  integer  zipcode
end record

phonebook pbAmy
pbAmy = {"Bob Marley", "Kingston, Jamaica", 00000}

puts(outfile, pbAmy)
<end code>

PS: My two cents (centavos, pesetas...)
I don't see the need to clutter the EU spec with cryptic syntax.  Like the C
+= class of operators, which always got me into trouble.  Or
short-circuiting logic evaluation (if length(s)>10 and compare(s,
"Rumplestilskin") then ...).  I see its convenience but I also see the
potential for bugs arising out of our forgetting how the short-cicuit works.
The pre-2.1 convention of multiple IF statements is more trouble but has the
definite advantage of being explicit.

if length(s)>10 then
  if compare(s, "Rumplestilskin") then
  ...
  end if
end if

Where the syntax is explicit, there is reduced possibility for confusion.  I
see the obstacle in programming as dealing with the complexity and tacit
assumptions (which we often fail to see) of our programming languages and
conventions.  By removing these "conveniences", we may make our jobs a
little mode tedious, but we lose a level of ambiguity and hidden
assumptions, allowing our code to be more readable and more trustworthy.

PPS:
Rob, now that 2.1 EXW can have multiple call-backs, does this mean we can
use threads??

Thanks,
nonlerer