Re: Structures( forget implications and flames)
On Wed, 2 Feb 2000 10:31:11 -0800, Cuny, David at DSS <David.Cuny at DSS.CA.GOV>
wrote:
>Everett Williams wrote:
>
>> but the reality is that underneath it all is
>> that loveliness that you document so well...
>> peek and poke.
>
>Gosh, using memory access routines to access memory! We certainly can't have
>*that*.
>
>-- David Cuny
Cheapshot! That memory that you so blithely champion also contains
everything else that we do on the computer. By that logic, we should all
get out our old copy of debug and have at it. Again, that might create
fast, efficient, compact code...then again, it might not. What was being
accessed was structured data with named fields. All that documentation
is lost in the process. How much cleaner if we can easily directly map
structured data from within Euphoria. Peek and Poke put data out into an
area that is completely out of Euphoria's internal knowledge...essentially
reducing us to a level of programming that is closer to machine code than
to assembler. You, of all people, would seem to be one of those most to
be benefitted by the variable mapping to be provided by structures. For
backwards compatibility and the few situations where it is really needed, I
would keep peek, poke and allocate, but I think that our dependence on
these gut level constructs could be much reduced to the benefit of the
quality of our code.
Everett L.(Rett) Williams
rett at gvtc.com
|
Not Categorized, Please Help
|
|
