1. Globals and shrouding
G'day all
A couple of thoughts on shrouding and globals:
1. Rob, could the shroud function be changed (with some sort of user
selection) to leave globals in clear code? Anything starting with
"global" could be left unshrouded - this would apply to both data
and function/procedure definitions. The code, and the use of the
global variables inside the code, would still be shrouded as they
are now.
This would give the curious (including other Eu developers) a way to
determine what global data is included in a shrouded library, as
well as what parameters are required for global routines.
This "unshrouding" could also be used with "include" lines, so that
users of the library could figure out what other libraries need to
be available to make this library work correctly.
2. Could libraries be developed in pairs, with one half containing
the global stuff and the other half the "non-global" (ie everything
else) stuff? That way, the non-global guts of the library could be
shrouded, but the global part be left in clear text. Any includes
could go with the global part.
Number 1 is work for Rob, number 2 is (lots of) work for everyone
else...
Another $0.02 contribution
Regards
Tony
2. Re: Globals and shrouding
On Wednesday 27 June 2001 23:48, Tony Bucholtz wrote:
> A couple of thoughts on shrouding and globals:
>
> 1. Rob, could the shroud function be changed (with some sort of user
> selection) to leave globals in clear code? Anything starting with
> "global" could be left unshrouded - this would apply to both data
> and function/procedure definitions. The code, and the use of the
> global variables inside the code, would still be shrouded as they
> are now.
>
> This would give the curious (including other Eu developers) a way to
> determine what global data is included in a shrouded library, as
> well as what parameters are required for global routines.
>
> This "unshrouding" could also be used with "include" lines, so that
> users of the library could figure out what other libraries need to
> be available to make this library work correctly.
Excellent! Please add to this the ability to leave a block of unshrouded
comments as well - so we can explain what does what.
Hey, wait a minute here! Why not just a new "with shrouding" command:
without shrouding
-- // My program.ex
-- This program writes "Hello World" on the screen
-- The variables available for your use are:
global atom x
global sequence hi
-- Functions you may safely access are:
-- function sayhi() - needs no parameters, returns the sequence 'hi'
with shrouding
hi = "Hello World"
function sayhi()
.return hi
end function
......more code (like it was needed!)
This would seem to be simpler for Rob to implement, and serves the
purpose quite well.
Regards,
Irv
3. Re: Globals and shrouding
On Thursday 28 June 2001 09:51, Tony Bucholtz wrote:
>
> Irv Mullins wrote:
> > Hey, wait a minute here! Why not just a new "with shrouding" command:
> > <snip>
>
> Irv, I agree, your "with/without shrouding" is much tidier, and
> <hint> should be easier for Rob to implement </hint>. The only
> thing I could add would be to ensure that these commands have no
> ill effects on code that *isn't* shrouded.
>
I can't see any possibility of ill effects - Euphoria itself would just
ignore "with shrouding" or "without shrouding" as meaningless.
The shrouder is the only thing that looks for these flags.
Of couse, I was careful to make my references to the functions and
procedure descriptions as -- comments, so that Euphoria would ignore
these as well, leaving the "real" functions and procedures safely hidden
away in the shrouded portion of the file. Should I forget to make these
as comments, no big deal, Euphoria will warn me right away,
because there are no matching end function or end procedure lines.
(does that already)
However, this introduces some extra work - if I change the functions or
parameters in my code, I must also be careful to change the "documentation"
in the comments at the top. I usually forget.
I can't think of a simple way around this. It's a shame when programmers
have to actually do work, isn't it :)
Regards,
Irv
4. Re: Globals and shrouding
On Thursday 28 June 2001 10:58, Tony Bucholtz wrote:
> It shouldn't be too hard to write a specialist preprocessor that
> would scan a source file for "global <whatevers>" and prepend them
> as a comment at the beginning of the code. It could even add the
> "without shrouding" and "with shrouding" statements - one less thing
> for the forgetful amongst us to worry about :)
Hooray!. Here's the best use of a pre-processor I've seen.
Especially since it would only run 'once' - just before the file was
shrouded - not every time you tried to run your program, as most
preprocessors must do.
Of course it will have a routine to produce an html document at the same
time, right?
Regards,
Irv
5. Re: Globals and shrouding
Tony Bucholtz writes:
> 1. Rob, could the shroud function be changed
> (with some sort of user selection) to leave globals in clear code?
> Anything starting with "global" could be left unshrouded - this
> would apply to both data and function/procedure definitions.
EUPHORIA\DOC\BIND.DOC:
"You can distribute a shrouded/scrambled .e include file that
people can include in their programs without seeing your source code.
Symbols declared as global in your main .e file will not be renamed,
so your users can access routines and variables with meaningful
long names, while the rest of your file remains shrouded."
There is also the -CLEAR_ROUTINES
option of the binder/shrouder, but it will make
*all* routine names unshrouded.
Both methods shroud all your statements etc.
but they leave certain routine and/or variable *names* visible
and usable for your users.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
