Re: Fair Criticism
Kat wrote:
> I *much* prefer the Eu way of free-form structures. This leaves it up to
me what i want
> to put in "fields". In Pascal, i used a lot of variant fields, and was
constrained by the
> rule of only one variant and it had to be at the end of a pre-declared
fixed record. What
> would make arrays/records as complex as C++ or pascal, but far more
versatile, will
> be if/when Rob (or someone) adds the runtime var naming, like mirc.
No one, including Rob, seems to be able to grasp the fact that fixed-length
"structures".
have never been the issue here. All people want is a simple, maintainable,
and readable,
way to reference parts of a standard Euphoria nested sequence..
The fact that Rob had trouble with C structures is irrelevant to Euphoria,
except in that
it must have tainted his view of how useful structures can be. The fact that
Pascal's
structures and variant fields were useful to you, (and me, and lots of other
programmers) despite their limitations, should be only more reason to
include something similar in Euphoria, where you can have infinitely variant
fields without the constraints you mentioned above.
It would be nice, after that, if the elements of a structure could retain
their types, but I believe, given the nature of Euphoria, that would be
impossible. So perhaps "structure" would be
an overly ambitious name. Call 'em "indexed lists" or, "named nested
sequences" or whatever,
just as long as the names of the fields are somehow associated with the
sequence itself,
so that we have meaningful and non-colliding names for more than one
sequence in a given
program.
You know very well that a Pascal program which has both a customer structure
and a product
structure will never get confused when you refer to customer.name or
product.name.
And that you can go into the customer structure later and add a .phone field
without
having to renumber all the following fields in that structure. In most other
languages
this is a standard, in fact an *expected* feature. One which simplifies,
not complicates,
the language. One which reduces, not increases, errors.
Regards,
Irv
|
Not Categorized, Please Help
|
|
