Re: Fair Criticism
What about type casting?
Of course it CAN be implemented, calling type checks all the time. But they
would soon drown out the productive code.
How about generating a structure skeleton when the structure contains other
structures?
Structures can be implemented, but it's certainly not appealing.
what's easier and more readable..
A) structure:
structure Date
integer Day,
integer Month,
integer Year
end structure
structure LastPurchase
Date PurchaseDate,
sequence Product,
sequence StoreLocation
end structure
structure customer
sequence FirstName,
sequence Lastname,
integer Age,
integer Gender,
LastPurchase Data,
end structure
Customer Account896
Account896 ={"John","Doe",35,'m',{"october 22,
2000",{"Panasonic","VCR","67994-8769-338-33449"},{"Castlerock","New
England"}}}
-- ERROR, typecheck failure, invalid structure
-- Expected sequence of length(3) for PurchaseDate
or B)
integer enum_count
enum_count=0
function enum()
return enum_count+=1
end function
constant Day=enum(),
Month=enum(),
Year=enum()
enum_count=0
type Date(object D)
if not sequence(Date) or length(Date)!=3 then return 0 end if
if not integer(D[Day]) then return 0 end if
if not integer(D[Month]) then return 0 end if
if not integer(D[Year]) then return 0 end if
return 1
end type
constant DatePurchased=enum(),
Product=enum(),
StoreLocation=enum()
enum_count=0
type LastPurchase(object L)
if not sequence(L) or length(L)!=3 then return 0 end if
if not Date(L[DatePurchased]) then return 0 end if
if not sequence(L[Product]) or length(L[2])!=3 then return 0
end if
for i = 1 to 3 do
if not sequence(L[2][i]) then return 0 end if
end for
if not sequence(L[StoreLocation]) or length(L[3])!=2 then
return 0 end if
for i = 1 to 2 do
if not sequence(L[3][i]) then return 0 end if
end for
return 1
end type
constant FirstName=enum(),
LastName=enum(),
Age=enum(),
Gender=enum(),
Data=enum()
enum_count=0
type Customer(object C)
if not sequence(C) or length(C)!=5 then return 0 end if
if not sequence(C[FirstName]) then return 0 end if
if not sequence(C[LastName]) then return 0 end if
if not integer(C[Age]) then return 0 end if
if not integer(C[Gender]) then return 0 end if
if not LastPurchase(C[Data]) then return 0 end if
end type
Customer Account896
Account896 ={"John","Doe",35,'m',{"october 22,
2000",{"Panasonic","VCR","67994-8769-338-33449"},{"Castlerock","New
England"}}}
-- ERROR, typecheck failure, invalid structure
-- Expected sequence of length(3) for PurchaseDate
PHEW!!!
Chris
----- Original Message -----
From: "Graeme" <graemeburke at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Sunday, August 12, 2001 4:40 AM
Subject: Re: Fair Criticism
>
> >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.
>
>
>
> At this point it seems to me that you're not really programming in EU. You
> are
> thinking in another launguage and translating. Perhaps an OO style method
of
> referencing elements might make some people feel more comfortable ... even
> potential
> new users. Could be a good thing, but it does NOT add any functionallity.
It
> dosn't
> DO anything apart from better suit some people's programming styles. If
you
> declare
> constants dynamically (for elements of a structure) then use them, why do
> you need
> to renumber anything?
>
>
>
> type string(sequence s)
> for x=1 to length(s) do
> if sequence(s[x]) then
> return 0
> end if
> end for
> return 1
> end type
>
>
> type record(sequence s)
> if not string(s[fFirstName]) then return 0 end if
> if not string(s[fLastName]) then return 0 end if
> if not string(s[fPhone]) then return 0 end if
> if not pos_int(s[fShoesize]) then return 0 end if
> -- .... etc ..
> return 1
> end type
>
>
>
> integer fEnum_count
> fEnum_count=0
>
> function fEnum()
> fEnum_count+=1
> return fEnum_count
> end function
>
>
> constant
> fFirstName =fEnum(),
> fLastName =fEnum(),
> fPhone =fEnum(),
>
> --........ add as many as u like here
>
> fShoeSize =fEnum(),
> NUM_FIELDS =fEnum_count(),
>
>
> .... i could go on but by now you should see where I'm coming from.
>
> If you add or remove something, nothing needs to be renumbered,
> it's all created dynamically and the actual order of fields is
> irrellivant. i dont see that much diffrence between record.fFirstName
> and record[fFirstName] The concept can be easily extended beyond this
> quick example to include complex data structures. If I were doing a
> customer structure and a product structure they would be seperate
> objects in seperate include files, including the routines and controls
> to access them.
>
> Immediately I hear you say that this is confusing and error prone and
> that you dont like the font color. To this I reply that every system is
> more confusing and error prone than the one you're used to, and that
> font color is just a matter of taste.
>
> This is the system I use, often without even bothering with the type
> statements, I'm used to it. I dont find it confusing. I find it VERY
> easy to debug if I make a mistake, or to alter at a later date.
>
> I think one point in favor of Rob adding dot notation or the like would
> be that it might make EU more attractive or friendly looking to potential
> new users. I reject the concept that because EU is not like
> Pascal it needs 'fixing'.
>
> Graeme.
>
>
>
>
>
|
Not Categorized, Please Help
|
|
