Re: pass by reference
Chris,
Only one small point. There is no error recovery in Eu,
because there is no trapping. All code in Euphoria is
defensive. One must write checking code for every possible
error( a thing that one quickly realizes is not possible
in static data handling and flat unreasonable when handling
dynamic data ). Without some form of error trapping, we
are reduced to after-the-fact debugging of each error. If
we knew how to or could practically check all errors before
they happened, we would probably have a program so large that
it would not be practical to run or maybe even program. We
would also be prescient, and I can think of lots of better
uses for that talent than programming...take me to the race
track and let me start buying lotto tickets. A language
without some form of error trapping makes even debugging a
very difficult task. With error trapping, I can make a test
run, logging each error that I find. Then I can examine that
log and deal with a whole group of errors at once rather
than have to debug and restart after each error. The other
problem with such sequential bug chasing is that each fix
has the possibility of creating or enhancing or hiding other
errors, further complicating the process.
Everett L.(Rett) Williams
rett at gvtc.com
bensler at mail.com wrote:
>
> <SNIP>
>
>>for testing purposes (only)
>>
>
> Currently, yes, that's all that typechecks are good for.
>
> <SNIP>
>
>>>As a customer who purchases software, I would be appalled to run a
>>>program that I paid money for, to have it crash with some error message
>>>that doesn't help me at all. Reminds me of Microsoft :P
>>>
>
> This was a fairly inaccurate statement. As is, a program can have
> extensive error checking AND recovery if wanted. It's just alot of code.
> With typechecks that modify, one could typically reduce the error
> checking/recovery code by half if not more. This makes the code more
> readable, leading to less errors, leading to faster development time.
> And makes reading 6 month old code alot easier. Getting the code written
> faster also usually means more time for testing.
> Writing error checking routines is also boring. When I'm bored, I'm less
> productive.
> Error recovery is even more tedious.
>
>
>>Are you happier if a program you purchased crashes and burns, or if it
>>does not perform as advertised/is not fit for task?
>>
>>If I spend say 2 hours typing in stuff & the program crashes and
>>burns, losing all my stuff, then I am NOT HAPPY.
>>
>>If I spend say 2 hours typing in stuff & the program either pops up
>>some drivel warning or simply wipes all the stuff I was doing, then
>>
> I
>
>>am not just "NOT HAPPY", I am seething with rage at the useless <SNIP>
>>
>
> If someone writes an error recovery routine that doesn't fully recover
> from the error, that's the programmers fault, not the language.
>
> Obviously, someone shouldn't write a recovery routine that resets a
> spreadsheet database to DEAFULT. That's just STUPID, and that programmer
> should be shot.
>
>
>>If the type check fails so you save loads & loads of stuff for
>>possible recovery, then good on ya, but if you're gonna write code
>>that says 'This should never be 9. I don't care how, why or at all, so
>>I'll just set it back to a nice safe 0", then **** you.
>>
>>
>>>It makes alot more sense to at least ATTEMPT to rectify the problem
>>>before resorting to the BLACK screen of death.
>>>
>>As above, I fail to see how hiding the cause of the problem can
>>possibly help. If you suspect there is going to be a problem modifying
>>variable x then why not make it a private variable in a new include
>>file with all the routines, checks etc to modify it?
>>
>
> YOU just answered your own question. A new include file, ALL the
> routines/checks, etc..
>
> Not only is it ALOT more code, it's harder to follow AND harder
> implement.
>
> <SNIP>
>
>>>If I could mutate the variable from a type check, all I would need is
>>>a type defined like this:
>>>
>>>type color(object c)
>>> if sequence(c) then c = make_rgb(c) end if
>>> return 1
>>>end type
>>>
>>That's reasonable, however if you wrap your routines:
>>
>>procedure setColour(object c)
>>xsetColour(mapcolour(c))
>>end procedure
>>
>>then all is well.
>>
> Wrap what? There is nothing to wrap.
>
> This is what is currently in exoticaX:
> global function clear_surface(object col)
> if sequence(col) then col = make_rgb(col) end if
> return c_func(CLEAR_SURFACE,{col})
> end function
>
> This is what you propose?: (slightly easier to read, but also slightly
> slower)
> global function clear_surface(object col)
> col = setColor(col)
<snip>
>
>
>
|
Not Categorized, Please Help
|
|
