OpenEuphoria

Re: goto

• Posted by Al Getz <xaxo at aol.com> Jan 06, 2001
• 513 views

Hey there Kat,

  I ran into problems like that too.  I'm not so sure a goto is the answer
anymore though.  I have seen how that disrupts the program read-through
flow, and now favor the 'continue' statement and possibly an "exit_all"
statement.  Compare the following two code fragments:

------------------------------------------------
--CODE FRAGMENT #1

integer exitflag

exitflag=0
while 1 do
  while 2 do
    while 3 do
      if condition3=bad then
        exitflag=1
        exit
      end if
    end while --3
    if condition2=bad or exitflag then
      exitflag=1
      exit
    end if
  end while --2
  if condition1=met or exitflag then
    exit
  end if
end while --1

CallProgramEnder()

---------------

--compare the above with the following:
--  (requires the inclusion of keyword "exit_all")

--CODE FRAGMENT #2

while 1 do
  while 2 do
    while 3 do
      if condition3=bad then
        exit_all
      end if
    end while --3
    if condition2=bad then
      exit_all
    end if
  end while --2
  if condition1=met then
    exit
  end if
end while --1

--exit_all would continue here:

CallProgramEnder()

-----------------------------------

I was going to ask, again, for an improvement in namespace assignment.
If we could declare a local variable to be local to the file (ie all
procedures in that file) but be invisible to the rest of the program, that
would make programing in class like style much nicer.  That would also mean
we would have reusable variable names for even global variable names.  The
only names to be prefixed would then boil down to the function names.


However i did discover the following interesting style which seeks to
eliminate the global variable all together, replacing it with corresponding
global interface functions:

For example:

  Base program:
    BaseProg.exw contains:
      sequence Objects
      include Class_PrimaryObjects.ew
      include Class_SecondaryObjects.ew
      include DataClass_Objects.ew
      InitializeObjects()
      Objects=GO_GetObjects() --loads Objects
      DoOperationsOnObjects() --modifies Objects
      Objects=GO_GetObjects() --loads the newly modified Objects

  the first ew file:
    Class_GetPrimaryObjects.ew contains:
      sequence Objects
      global function OPO_GetObjects()
        --do the work here--
        return Objects
      end function

  the second ew file:
    Class_GetSecondaryObjects.ew contains:
      sequence Objects
      global function OSO_GetObjects()
        --do the work here--
        return Objects
      end function

  the third ew file:
    DataClass_Objects.ew contains:
      --this is the main data class for the program.
      sequence Objects
      global function O_GetObjects()
        return Objects
      end function
      global procedure InitializeObjects()
        Objects=OPO_GetObjects()&OSO_GetObjects()
      end function
      global procedure DoOperationsOnObjects()
        for k=1 to length(Objects) do
          --do work here--
        end for
      end procedure

Notice all the 'classes' have their own "Objects" so they can all do
operations using several local or global functions within that file,
while at the same time maintaining their invisibility to the rest of the
program.  Im not sure how well this works out memory wise, when the Objects
sequence grows extremely large.  Are there going to be three copies of
almost the same data resident in memory after a small modification
operation?


This idea would change the programming style in general, pushing it more
towards class like style, where the data variable is invisible outside of
the 'class' file.  To read a class data variable, simply use a class
interface global function (such as O_GetObjects above).


It would be nice to have an equally nice solution for global constants,
however, as i find include files that contain some constants and dont
contain others, and its not easy to find out which ones are and which ones
arnt included, untill you get an error, or care to search through the
entire file for global constants.  The only easy way around this i see at
the moment is to provide an "if defined" statement, or better yet provide a
supressable warning "warning: global variable already declared". For
example:

  global atom THIS_CONSTANT=10
  --then in another place in the program:
  global atom THIS_CONSTANT=10 -- triggers "warning: global variable
                                            already declared"


  this would take care of that problem!  Since the interpreter would see
  this, it wouldnt have to declare a separate variable either, so it
  wouldnt waste variable space just because a global atom was repeated in
  someone elses include file.


Take care now,
Al