Re: Fair Criticism
- Posted by Graeme <graemeburke at hotmail.com> Aug 12, 2001
- 557 views
>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.