1. wishlist : structures
------=_NextPart_000_0017_01C048C2.F5533460
charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
Two good reasons why structures are needed:
a.. More stable code (acessing sequence members that don't exist =
causes error now)=20
b.. More easy and organized programming (my[3] turns to my.width)
Structures are in big programs very useful and neccessary. Look for =
example at Quake code, there's nothing but structures all over the =
place.
------=_NextPart_000_0017_01C048C2.F5533460
charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-2" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Two good reasons why structures are=20
needed:</FONT></DIV>
<UL>
<LI><FONT face=3DArial size=3D2>More stable code (acessing sequence =
members that=20
don't exist causes error now)</FONT>=20
<LI><FONT face=3DArial size=3D2>More easy and organized programming =
(my[3] turns=20
to my.width)</FONT></LI></UL>
<DIV><FONT face=3DArial size=3D2>Structures are in big programs very =
useful and=20
neccessary. Look for example at Quake code, there's nothing but =
structures all=20
------=_NextPart_000_0017_01C048C2.F5533460--
2. Re: wishlist : structures
©koda 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 zero' is
a bad thing, I would expect an error if I tried to access sequence members
that don't exist.
> - 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; with
namespaces, you would write:
my[rect.width]
This isn't compellingly better than:
my[RECT_WIDTH]
Personally, I'm leaning toward implementing them as associative lists (like
JavaScript or Python).
Another feature that people want is for structures to map into C structures.
This would make it easier to interface to the 'outside world' via DLLs.
-- David Cuny
3. Re: wishlist : structures
Koda,
I like the idea of structures too, but i have used the following
to emulate some simple structures which only have to be accessed
by other Euphoria code. For example:
my.width=145
my.height=233
become:
sequence my
constant WIDTH=1, HEIGHT=2
my={0,0}
my[WIDTH]=145
my[HEIGHT]=233
the only drawback is if you need WIDTH and HEIGHT for another struc,
you might have to super class all the constants:
sequence my
constant my_WIDTH=1, my_HEIGHT=2
my={0,0}
my[my_WIDTH]=145
my[my_HEIGHT]=233
sequence her
constant her_WIDTH=2, her_HEIGHT=1
her={0,0}
her[her_WIDTH]=145
her[her_HEIGHT]=233
I've used this method in several large programs and can still
understand what is being done after reading through the code
several months later.
Hope this helps some.
--Al
4. Re: wishlist : structures
Al Getz <xaxo at AOL.COM> wrote:
> the only drawback is if you need WIDTH and HEIGHT for another struc,
> you might have to super class all the constants:
>
> sequence my
> constant my_WIDTH=1, my_HEIGHT=2
> my={0,0}
> my[my_WIDTH]=145
> my[my_HEIGHT]=233
That would work also, but it slows down programming, because you have to
type those long words, and search them up if you don't rememeber them. So I
rather write numbers and then I have to look in my comments for where
something is saved in sequence (my artificial structures). Without those
comments I would be lost!
Look how simple is in Visual Basic: you type "my." and then it shows you
listbox from where you can select which member of structure you want. That's
super duper fast!
We will never have this luxury in Euphoria until we have structures.
5. Re: wishlist : structures
©koda wrote:
> Look how simple is in Visual Basic: you
> type "my." and then it shows you listbox
> from where you can select which member of
> structure you want. That's super duper fast!
> We will never have this luxury in Euphoria until
> we have structures.
This is a feature of the VB IDE, not the language. The IDE looks at the
*type* declaration, and determines what to display. You could add similar
functionality to a Euphoria IDE without having to alter the language, by
associating a list of attributes with a type. For example:
-- type foo
constant
this = 0,
that = 1,
the_other = 3
could flag to the IDE that the following type list is associated with the
type 'foo'.
Conversely, if you added structures but didn't change the IDE, you still
wouldn't get that cool dropdown.
-- David Cuny
6. Re: wishlist : structures
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
7. Re: wishlist : structures
On 7 Nov 2000, at 12:00, Al Getz wrote:
> Koda,
>
> I like the idea of structures too, but i have used the following
> to emulate some simple structures which only have to be accessed
> by other Euphoria code. For example:
>
> my.width=145
> my.height=233
>
> become:
>
> sequence my
> constant WIDTH=1, HEIGHT=2
> my={0,0}
> my[WIDTH]=145
> my[HEIGHT]=233
>
> the only drawback is if you need WIDTH and HEIGHT for another struc,
> you might have to super class all the constants:
>
> sequence my
> constant my_WIDTH=1, my_HEIGHT=2
> my={0,0}
> my[my_WIDTH]=145
> my[my_HEIGHT]=233
>
> sequence her
> constant her_WIDTH=2, her_HEIGHT=1
> her={0,0}
> her[her_WIDTH]=145
> her[her_HEIGHT]=233
>
> I've used this method in several large programs and can still
> understand what is being done after reading through the code
> several months later.
This reminds me of a large pascal program i wrote once, which could
easily be converetd to Eu, if i chose to do that. In it, i'd this in Eu:
constant
something 1
somethingelse 2
somethingmore 3
anotherthing 4
sequence stuff_1 {"","","",""}
sequence stuff_2 {"","","",""}
sequence stuff_3 {"","","",""}
ok,,,
stuff_2[somethingelse] = "etc"
stuff_2[anotherthing] = "whatever two"
stuff_3[something] = "whatever"
stuff_3[anotherthing] = "whatever three"
and just don't use those indexes i don't need. No need to redefine different
index values for each sequence. If i ever do need to use them, the space in
the sequence is already there, all i haveto do is use it. Really, in today's
puters and OSs, what is a wasted byte here or there?
Kat
8. Re: wishlist : structures
Irv wrote:
> ... enumerate
Yeah, that would be a nice addition. Euphoria is a bit odd when it comes to
types. You can't check for a user-declared type. For example:
window myWindow
declares myWindow to be of the 'type' window, but you can't ever really
_check_ the type. Calling:
window( myWindow )
runs the type routine, but it just runs *tests* on the parameter, it doesn't
know anything about what type it was declared as.
My guess is that the Euphoria runtime engine doesn't even know about the
user defined types. The code generator probably just uses the type to insert
a call to the type test routine after every assignment.
If that's the case, then you lose type information when you call; the
parameter is "recast" every time you pass it as a parameter.
It would be kind of neat if Euphoria actually allowed you to track the type.
OOPish stuff (and structures are OOPish) would be a lot easier to emulate.
> 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.
Point taken.
-- David Cuny
9. Re: wishlist : structures
>Cuny, David at DSS <David.Cuny at DSS.CA.GOV> wrote:
>Conversely, if you added structures but didn't change the IDE, you still
>wouldn't get that cool dropdown.
Yes, but while there are no structures we for sure won't get that cool
dropdown in any IDE.
> -- type foo
> constant
> this = 0,
> that = 1,
> the_other = 3
Noone would use these nopractical artificial structures. The same problem
still remains.
10. Re: wishlist : structures
Koda,
Alternately you could simply replace the struc name dot with an
underscore:
for
my.width=145
my.height=233
> -- was:
> sequence my
> constant my_WIDTH=1, my_HEIGHT=2
> my={0,0}
> my[my_WIDTH]=145
> my[my_HEIGHT]=233
becomes:
sequence my
constant my_width=1, my_height=2
my={0,0}
my[my_width]=145
my[my_height]=233
note:
my.width=145 => my[my_width]=145
and
my.height=233 => my[my_height]=233
This makes the program self documenting and almost as clean
as a C program file. You shouldnt have to look anything up.
The only difference now is that you must declare a sequence
and name that sequence as well as the element, as well
as initialize it first with a zero for every element you
wish to use later as an atom or as a sequence.
Of course if you have more then one struc of the same type you'll have
to go to a second class name:
my[my_driveway_width]=145
my[my_sidewalk_width]=36
By looking at the statement, you always know what struc your talking
about as well as what element, and the elements are fairly easy to
remember because they are the simple name of whatever real life
variable they represent (sidewalk_width) preceded by the struc name (my)
followed by an underscore (_).
I've done this a lot because it makes the program understandable
without having to look all kinds of things up first in rem notes.
If you have a really really long list of strucs and element names,
if helps to keep a list open in notepad or whatever listing
those names and what they are for.
Koda wrote:
>>
That would work also, but it slows down programming, because you have to
type those long words, and search them up if you don't rememeber them. So I
rather write numbers and look in comments......
<<
Good luck with it.
--Al
11. Re: wishlist : structures
©koda wrote:
>> -- type foo
>> constant
>> this = 0,
>> that = 1,
>> the_other = 3
>
> No one would use these nopractical artificial structures.
Your point is taken - there's little incentive to use an artificial system.
I used a pre-processor for a while to write code, but eventually abandoned
it because I got tired of the overhead.
> Yes, but while there are no structures we for
> sure won't get that cool dropdown in any IDE.
No, but I agree that it's unlikely that people will be happy with a
compromise - especially if it only worked in one particular Euphoria IDE.
But I think my point remains. Even if we had sequences added to Euphoria, it
would still take a bit of work to add that cool VB magic to the IDE. The
editor would have to be able to parse the source file (and included files)
that was being edited, and track the types of each variable, along with the
fields of each struct. There are a lot of things that could be added to the
editor right now, for example: keyword completion, or tooltip help showing
routine prototypes. While it's certainly possible, it's not entirely
trivial.
-- David Cuny
12. Re: wishlist : structures
- Posted by Dan B Moyer <DANMOYER at PRODIGY.NET>
Nov 07, 2000
-
Last edited Nov 08, 2000
David,
I have already made a "variation" for part of Judith's development of the
IDE which does better than "tooltips" for routine prototypes: I listed b=
oth
Euphoria and Win32Lib routines in combo boxes (in categories), and if you
click on any routine, its prototype is put into the clipboard, so a simpl=
e
"paste" then puts it right away directly into the Code Editor (along with=
,
for those Euphoria routines which need an include to work, a commented
"--include xyz.ew" following the routine prototype).
Dan Moyer
----- Original Message -----
From: "Cuny, David at DSS" <David.Cuny at DSS.CA.GOV>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Tuesday, November 07, 2000 3:43 PM
Subject: Re: wishlist : structures
=A9koda wrote:
>> -- type foo
>> constant
>> this =3D 0,
>> that =3D 1,
>> the_other =3D 3
>
> No one would use these nopractical artificial structures.
Your point is taken - there's little incentive to use an artificial syste=
m.
I used a pre-processor for a while to write code, but eventually abandone=
d
it because I got tired of the overhead.
> Yes, but while there are no structures we for
> sure won't get that cool dropdown in any IDE.
No, but I agree that it's unlikely that people will be happy with a
compromise - especially if it only worked in one particular Euphoria IDE.
But I think my point remains. Even if we had sequences added to Euphoria,=
it
would still take a bit of work to add that cool VB magic to the IDE. The
editor would have to be able to parse the source file (and included files=
)
that was being edited, and track the types of each variable, along with t=
he
fields of each struct. There are a lot of things that could be added to t=
he
editor right now, for example: keyword completion, or tooltip help showin=
g
routine prototypes. While it's certainly possible, it's not entirely
trivial.
-- David Cuny
13. Re: wishlist : structures
- Posted by David Cuny <dcuny at LANSET.COM>
Nov 07, 2000
-
Last edited Nov 08, 2000
Dan Moyer wrote:
> I have already made a "variation" for
> part of Judith's development of the
> IDE which does better than "tooltips"
And you've mentioned this several times before... *kicking self*
I *really* need to pay more attention to what libraries people are posting
these days... 
-- David Cuny
