OpenEuphoria

Re: Att: Rob - namespace problem

• Posted by Al Getz <Xaxo at aol.com> Sep 22, 2005
• 441 views

Hi there,

As far as changing the source to make a regular 'include' be included
several times using a new instance...

I'd have to agree with Pete, if it's done that way, but if another 
keyword or something is used such as:

  include_repeatable MyFile.e as MF_1
  include_repeatable MyFile.e as MF_2

i have to say this would be an extreme boost of functionality for
Euphoria.  This is because basically the .e or .ew file functions
as a group of functions with a data class bound with them.  Being
able to invoke another instance of this file would be almost as
important as invoking another variable with statements like
"atom", "sequence", etc.  Imagine if you could only use a variable
name ONE TIME in your program, like "atom x".  Imagine how hard
it would be to 'not' use it again by accident.  You'd have to keep
changing the name every time you needed a variable like that:
atom x  atom x1, atom x2, atom xx, etc.
This is similar to the restriction now imposed by the include statement,
where you cant bring about another instance without changing the
file name.  Think about this...everything is exactly the same except
the file name itself.

Also, this would bring into being another 'scope' for variables like
shared variables.  Shared variables could be a scope for local or 
global variables that you want to be the *same* in ALL file instances.

For example:
  --MyFile.e
  atom x,y
  shared atom z

  x=0 y=0 z=0

  global procedure UpdateXYZ(atom xx,atom yy,atom zz)
    x=xx
    y=yy
    z=zz
  end procedure

  global function GetXYZ()
    return {x,y,z}
  end function


In instance 1 and 2 of MyFile.e  x and y are local variables, but
z is the same for both files so that if either file changes z it's
reflected in BOTH files, not just one.  It's not global, however,
because only the instances can see them.

  include_rep MyFile.e as MF1
  include_rep MyFile.e as MF2

  ?MF1:GetXYZ() --prints {0,0,0}
  ?MF2:GetXYZ() --prints {0,0,0}

  MF1:UpdateXYZ(1,2,3)
  ?MF1:GetXYZ() --prints {1,2,3}
  ?MF2:GetXYZ() --prints {0,0,3}


You can see how interesting this addition would be and that it could
never 'hurt' the language in any way.

Also, if the 'shared' concept was extended to routines also, routines
could be shared among several 'class instances' meaning the overall 
program length wouldnt increase much if you only had say one
sequence that had to be unique among all the instances.

BTW, i chose the keywords somewhat randomly so there might be better
names.  There might also be additional ideas that come about once
the multiple instance concept is accepted which can only increase
the functionality of the language.

The trace mechanism would have to be updated to include the
namespace prefix with the file name so that the user would know
which instance they were stepping through...
  MF1:MyFile.e
  MF2:MyFile.e
  etc.


Take care,
Al

And, good luck with your Euphoria programming!

My bumper sticker: "I brake for LED's"