OpenEuphoria

RE: pass by reference

• Posted by bensler at mail.com Feb 22, 2002
• 471 views

<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)
   return c_func(CLEAR_SURFACE,{col})
end function

This is what I propose: (easier to read)
global function clear_surface(color col)
   return c_func(CLEAR_SURFACE,{col})
end function


Want another example?

Currently:
type phone_number(object x)
   if not sequence(x) then return 0 end if
   if length(x) !=7 and length(x) !=10 then return 0 end if
   for i = 1 to length(x) do
      if not integer(x[i]) then return 0 end if
      if x[i] <'0' or x[i] >'9' then return 0 end if
   end for
   return 1
end type

function format_phone_number(sequence num)
-- strip out any hyphens,periods, and parentheses
 integer found
   found = find('-',num)
   if not found then found = find('.',num) end if
   if not found then found = find('(',num) end if
   if not found then found = find(')',num) end if
   if found then
      num = num[1..found-1]&num[found+1..length(num)]
      return format_phone_number(num)
   else
      return num
   end if
end function

function get_phone_number()
 phone_number num
 sequence msg
   msg = "Enter a phone number :"
   num = 0
   while not phone_number(num) do
      if sequence(num) then
         msg = "Invalid phone number.\n"&msg
      end if
      num = format_phone_number(prompt_string(msg))
   end while
   return num
end function


I would like to see:
type phone_number(object x)
 sequence msg
   msg = "Invalid phone number entered.\nEnter a phone number :"
   if not sequence(x) or ( length(x) !=7 and length(x) !=10) then
      x = prompt_string(msg)
      return phone_number(x)
   else
      x = format_phone_number(x) -- same routine as above
      for i = 1 to length(x) do
         if not integer(x[i]) or x[i] <'0' or x[i] >'9' then
            x = prompt_string(msg)
            return phone_number(x)
         end if
      end for
   end if
   return 1
end type

function get_phone_number()
 phone_number num
   num = prompt_string("Enter a phone number :")
   return num
end function



Both versions function identically(In theory. I didn't test this code), 
but the latter hides all the formatting and error checking/recovery in 
the typecheck(IMO, where it belongs), leaving the actual routine clear, 
precise, and easy to understand.
And of course, I can plug that typecheck into any other routine I like, 
and have it perform the same way.

Chris