1. Request for 2.5
When you shroud a file, in particular a library, nested global
functions and procedures are no longer global, only the top level
global routines remain global. This is good.
However, the same does not happen for global variables and constants.
I appreciate why, and that changing this behaviour would cause all
manner of upsets on existing sources. I suggest a new keyword is
introduced, eg package, which behaves exactly as global on unshrouded
source, but the shrouder removes it.
Regards,
Pete
2. Re: Request for 2.5
Pete Lomax wrote:
> When you shroud a file, in particular a library, nested global
> functions and procedures are no longer global, only the top level
> global routines remain global. This is good.
>
> However, the same does not happen for global variables and constants.
>
> I appreciate why, and that changing this behaviour would cause all
> manner of upsets on existing sources. I suggest a new keyword is
> introduced, eg package, which behaves exactly as global on unshrouded
> source, but the shrouder removes it.
It seems to me the top level variables and constants
should also remain global. If this is not happening for you,
then it could be a bug in the binder/shrouder. Not many people
have created shrouded library code. Almost everyone creates
complete bound or shrouded programs, so you may be treading
on some rarely-used parts of the binder/shrouder. If you have
a small example you can send me, I'll look at it. Otherwise
I'll investigate this general issue some time before
the next release.
Thanks,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
3. Re: Request for 2.5
On Tue, 19 Aug 2003 15:24:28 -0400, Robert Craig
<rds at RapidEuphoria.com> wrote:
>Pete Lomax wrote:
>> When you shroud a file, in particular a library, nested global
>> functions and procedures are no longer global, only the top level
>> global routines remain global. This is good.
>>=20
>> However, the same does not happen for global variables and constants.
>>
>> I appreciate why, and that changing this behaviour would cause all
>> manner of upsets on existing sources. I suggest a new keyword is
>> introduced, eg package, which behaves exactly as global on unshrouded
>> source, but the shrouder removes it.
>
>It seems to me the top level variables and constants
>should also remain global. If this is not happening for you,
>then it could be a bug in the binder/shrouder.
Sorry, I wasn't clear enough. I also said variables <and constants>,
when actually it is just variables. It keeps all the global variables
still global, both toplevel (correct) _and nested_ (wrong).
>Not many people have created shrouded library code. Almost everyone =
creates
>complete bound or shrouded programs, so you may be treading
>on some rarely-used parts of the binder/shrouder.
Spot on. I can work round this by shroud -clear, edit the file
removing a few "global"s and re-shroud. No biggie.
>If you have a small example you can send me, I'll look at it.
There's a couple below.
>Otherwise I'll investigate this general issue some time before
>the next release.
Yes, this is a request for 2.5
Here's a more detailed explanation:
One small glitch occurs when you shroud a program which includes
misc.e without using any routines from it. It retains
integer pretty_end_col,pretty_chars,pretty_start_col,pretty_level,
pretty_file,pretty_ascii,pretty_indent,pretty_ascii_min,
pretty_ascii_max
sequence pretty_fp_format,pretty_int_format,pretty_line
when ideally, it should not. (So what, ... but a bug is a bug)
Now, (this is an example showing correct behaviour), if you include
ddl.e and have say:
atom iwinspool,iEnumPrinters
iwinspool=3Dopen_dll("winspool.drv")
iEnumPrinters=3Ddefine_c_func(iwinspool,"EnumPrintersA",
{C_INT,C_INT,C_INT,C_INT,C_INT,C_INT,C_INT},C_INT)
it shroud -clear's to:
constant C_INT=3D#01000004
constant M_DEFINE_C=3D51
function open_dll(sequence file_name)
function define_c_proc(object L,object routine_name,
<etc>
Notice the global keyword has (correctly) been removed.
If however you include database.e, you get:
global integer my_dir=20
global integer db_fatal_id
There is no need for that, and of course it is going to cause
namespace qualifier errors for anyone using the library.
Now that I've realised this is only variables, not constants, I no
longer think that changing this will break anything.
Regards,
Pete
PS the database.e is just an example, I've actually done some wrapping
to make sure it won't load two copies in memory, btw.
