1. Data hiding
I've been thinking about this topic, and I've identified several issues.
I can think of two basic methods to restrict visibility:
1. From within the declaring file
2. From outside the declaring file
We have a decent mechanism for restricting visibility based on #1, but
lose all control once it gets out. The solutions proposed by Pete and
CChris are what might be called hybrid methods.
For reference, here are the links to these two approaches:
http://oedoc.free.fr/Packages.htm
http://palacebuilders.pwp.blueyonder.co.uk/dhc.htm
(Pete, your links to the various replies are broken--missing the '#'.)
CChris' approach provides the package+identifier and restrict lists, which
are mostly #2 based, but the addition of the new internal and exported
keywords earn them a hybrid status.
Pete requires a #1 approach, but also relies a bit on #2 to enable
visibility.
Both used explicitly named scoping mechanisms, which throw up red flags
in my mind. They might not be a problem, but I'd be interested to hear
from the respective authors what happens when the same name is used in
two different places, for different purposes. IOW, does it cause an
error? Are the two scopes treated as one? Etc...
One concern I have about CChris' approach is that once a symbol is exported
from a package, there's no way to hide it from downstream users:
"An exported symbol is visible from any part of the system."
Here's a scenario where I think you'd want to be able to do this. You
have a library that relies on another library for some backend work. But
you don't want to expose any symbols from that library, which might have
already restricted visibility on some symbols, and therefore have exported
some of its symbols. Is there a way to do this, CChris? Maybe the
restrict keyword does this, but I'm not sure from the documentation.
Pete's system seems to be a lot simpler, but doesn't offer the ability
to do this either.
Now for an overview on how I'd implement import. For the file that issued
an import statement, it would be identical to an include. For files
that either include or import that file, no imported symbols would be
visible, unless included or imported via another route. This approach
doesn't rely on any explicit grouping, or knowing which files "belong" to
which group. It just defines the way global symbols propagate, allowing
the coder to stop the propagation at any point.
It's an admittedly minimalist approach, but that's part of what I like
about it (and why I think it's particularly suited for euphoria).
ex:
-- myapp.ex
include libMatt.e
import libPete.e
global object PETE
-- PETE is visible from libMatt.e
-- PETE is not visible from myapp.ex
--myapp.ex
include libMatt.e
import libPete.e
global object PETE
include libPete.e
-- PETE is visible from libMatt.e
-- PETE is visible from myapp.ex
Here is my [quick] evaluation of the current proposals:
CChris:
Pro - gives "transitional" capability to hide info from outside file
- high granularity of symbols to hide/expose
Con - seems overly complicated (5 new keywords, total 7 different uses)
- can't "firewall" symbols (unless that's what restrict does)
??? - how will package naming conflicts be dealt with
Pete:
Pro - simple implementation (2 keywords [assuming shared_scope = 1 word])
- high granularity of symbols to hide/expose
Con - requires editing source files
- can't "firewall" symbols up the include chain
??? - how will shared_scope naming conflicts be dealt with?
Matt (import approach):
Pro - very simple implementation (1 new keyword)
- can hide/firewall symbols at any point in include chain
Con - granularity of other proposals achievable, but requires changing
file layout (i.e., moving variables to files that are imported)
I'd be interested in hearing from people other than us 3. :)
Matt
2. Re: Data hiding
I've been following the discussion (much of which makes my head spin) but your
import proposal is probably closest to my own ideal.
I'll admit though that many of the aspects being discussed are very confusing.
Or maybe just the language being used to discuss them is what confuses me.
--
A complex system that works is invariably found to have evolved from a simple
system that works.
--John Gall's 15th law of Systemantics.
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
3. Re: Data hiding
Matt:
Instead of using all that effort on trying to patch around all the
present version of Euphoria; would it not be easier to create a new
spin-off version written in CPP and OOP.
That way you could redesign a name-space system and make interfacing
to other languages easier. Also create a new compiler.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
4. Re: Data hiding
Matt Lewis wrote:
>
>
> I've been thinking about this topic, and I've identified several issues.
> I can think of two basic methods to restrict visibility:
>
> 1. From within the declaring file
> 2. From outside the declaring file
>
> We have a decent mechanism for restricting visibility based on #1, but
> lose all control once it gets out. The solutions proposed by Pete and
> CChris are what might be called hybrid methods.
>
> For reference, here are the links to these two approaches:
> <a
> href="http://oedoc.free.fr/Packages.htm">http://oedoc.free.fr/Packages.htm</a>
> <a
> href="http://palacebuilders.pwp.blueyonder.co.uk/dhc.htm">http://palacebuilders.pwp.blueyonder.co.uk/dhc.htm</a>
> (Pete, your links to the various replies are broken--missing the '#'.)
>
> CChris' approach provides the package+identifier and restrict lists, which
> are mostly #2 based, but the addition of the new internal and exported
> keywords earn them a hybrid status.
>
> Pete requires a #1 approach, but also relies a bit on #2 to enable
> visibility.
>
> Both used explicitly named scoping mechanisms, which throw up red flags
> in my mind. They might not be a problem, but I'd be interested to hear
> from the respective authors what happens when the same name is used in
> two different places, for different purposes. IOW, does it cause an
> error? Are the two scopes treated as one? Etc...
>
> One concern I have about CChris' approach is that once a symbol is exported
> from a package, there's no way to hide it from downstream users:
>
> "An exported symbol is visible from any part of the system."
>
> Here's a scenario where I think you'd want to be able to do this. You
> have a library that relies on another library for some backend work. But
> you don't want to expose any symbols from that library, which might have
> already restricted visibility on some symbols, and therefore have exported
> some of its symbols. Is there a way to do this, CChris? Maybe the
> restrict keyword does this, but I'm not sure from the documentation.
>
> Pete's system seems to be a lot simpler, but doesn't offer the ability
> to do this either.
>
> Now for an overview on how I'd implement import. For the file that issued
> an import statement, it would be identical to an include. For files
> that either include or import that file, no imported symbols would be
> visible, unless included or imported via another route. This approach
> doesn't rely on any explicit grouping, or knowing which files "belong" to
> which group. It just defines the way global symbols propagate, allowing
> the coder to stop the propagation at any point.
>
> It's an admittedly minimalist approach, but that's part of what I like
> about it (and why I think it's particularly suited for euphoria).
>
> ex:
> }}}
<eucode>
> -- myapp.ex
> include libMatt.e
> import libPete.e
> global object PETE
>
> -- PETE is visible from libMatt.e
> -- PETE is not visible from myapp.ex
>
> --myapp.ex
> include libMatt.e
> import libPete.e
> global object PETE
>
> include libPete.e
>
> -- PETE is visible from libMatt.e
> -- PETE is visible from myapp.ex
> </eucode>
{{{
>
> Here is my [quick] evaluation of the current proposals:
>
> CChris:
> Pro - gives "transitional" capability to hide info from outside file
> - high granularity of symbols to hide/expose
>
> Con - seems overly complicated (5 new keywords, total 7 different uses)
> - can't "firewall" symbols (unless that's what restrict does)
>
From the short presentation section in Packages.htm:
"restrict <symbol> from <current context> to <new context>
Customises the scope of a symbol, in the rare cases the tools above won't help."
So yes, it does firewall a single symbol, in cases this is not covered by file
wide approaches. It can also extend it if the rules firewall a symbol too
narrowly.
See also, in the discussion of the "with package" directive:
"Once the scope of a symbol has been defined by its active package, it can be
changed only by a *restrict* directive. "
> ??? - how will package naming conflicts be dealt with
>
From the end of the introduction:
"Since a package is the way to specify that a few source files belong to a
single logical entity, the library, irrespective of their being clustered in one
or more directories, the package identifier should be chosen so as to be very
likely unique. Concatenating the library name, author name and version number
should be adequate."
There is a typo in the posted text, I'l correct it.
In my implementation, an error is raised if a package name appears in two
different *package* directives. I'll mention that explicitly.
Now that I think about it, adding the version info in the package name isn't a
good idea either. The rest should be enough.
Well, it looks like at last you read the paper 
. I don't agree with the
metrics you use for simplicity, but that is another topic.
> Pete:
> Pro - simple implementation (2 keywords [assuming shared_scope = 1 word])
> - high granularity of symbols to hide/expose
>
> Con - requires editing source files
> - can't "firewall" symbols up the include chain
>
> ??? - how will shared_scope naming conflicts be dealt with?
>
> Matt (import approach):
> Pro - very simple implementation (1 new keyword)
> - can hide/firewall symbols at any point in include chain
>
> Con - granularity of other proposals achievable, but requires changing
> file layout (i.e., moving variables to files that are imported)
>
> I'd be interested in hearing from people other than us 3. :)
>
> Matt
5. Re: Data hiding
Bernie Ryan wrote:
>
> Matt:
>
> Instead of using all that effort on trying to patch around all the
> present version of Euphoria; would it not be easier to create a new
> spin-off version written in CPP and OOP.
> That way you could redesign a name-space system and make interfacing
> to other languages easier. Also create a new compiler.
Erm. Because I'd still have the same issues. And people (including me)
like euphoria for what it is (even if there are some great opportunities
for improving it).
In short, I don't think it would be easier to spin off a new language.
Matt
6. Re: Data hiding
Matt Lewis wrote:
> Bernie Ryan wrote:
> > Instead of using all that effort on trying to patch around all the
> > present version of Euphoria; would it not be easier to create a new
> > spin-off version written in CPP and OOP.
> > That way you could redesign a name-space system and make interfacing
> > to other languages easier. Also create a new compiler.
> Erm. Because I'd still have the same issues. And people (including me)
> like euphoria for what it is (even if there are some great opportunities
> for improving it).
>
> In short, I don't think it would be easier to spin off a new language.
Matt, don't be lazy.
7. Re: Data hiding
CChris wrote:
>
> Matt Lewis wrote:
> >
> > Here is my [quick] evaluation of the current proposals:
> >
> > CChris:
> > Pro - gives "transitional" capability to hide info from outside file
> > - high granularity of symbols to hide/expose
> >
> > Con - seems overly complicated (5 new keywords, total 7 different uses)
> > - can't "firewall" symbols (unless that's what restrict does)
>
> So yes, it does firewall a single symbol, in cases this is not covered
> by file wide approaches. It can also extend it if the rules firewall a
> symbol too narrowly.
>
> See also, in the discussion of the "with package" directive:
> "Once the scope of a symbol has been defined by its active package, it
> can be changed only by a *restrict* directive. "
OK, so that moves to the Pro side.
> > ??? - how will package naming conflicts be dealt with
> >
>
> From the end of the introduction:
> "Since a package is the way to specify that a few source files belong
> to a single logical entity, the library, irrespective of their being
> clustered in one or more directories, the package identifier should be
> chosen so as to be very likely unique. Concatenating the library name,
> author name and version number should be adequate."
>
> There is a typo in the posted text, I'l correct it.
>
> In my implementation, an error is raised if a package name appears in
> two different *package* directives. I'll mention that explicitly.
>
> Now that I think about it, adding the version info in the package name
> isn't a good idea either. The rest should be enough.
Ok, so to summarize, non-unique package names cause errors, which would
be bad. Best practices will be documented to choose package names that
are unlikely to be duplicated. Less than ideal, in my book, but if the
suggestions are followed, it shouldn't be a real problem.
> Well, it looks like at last you read the paper .
I've looked at it several times, but either didn't have the time to slog
through it, or was too tired to figure it out. And each time I read it
I understood it a little better. Also, IMHO, we're finally on the
same topic. :)
> I don't agree with the metrics you use for simplicity, but that is
> another topic.
The metrics weren't really what drove my complexity evaluation. They
were really based upon my impression of how difficult I found it to work
out how to use it, and what some of the implications were. The keywords
were just illustrative, but I think they do a good job in showing that
your approach has many more "moving parts" and ways that things can
interact. It just adds up to more things that have to be understood
and used correctly to get the desired results.
Which, of course, doesn't necessarily make it worse, but given the
choice between two equivalents, I'll prefer the more simple of the two
nearly every time, so I consider higher complexity to be a Con.
Seeing examples might change my mind, as sometimes it's hard to simply
visualize. And, of course, I'll always have less trouble understanding
my own ideas, even if only because I've thought about them more.
One side benefit that I think would be encouraged by my approach is that
in the main include file of a library, you'd be more likely to have only
globals that were meant to be exported (the external interface of the
library). So intra-library API stuff that needed to be shared among the
files but that you wanted to hide would be put into its own file, and
imported by the other parts of the library. It would leave less stuff
in that interface file. I often go to the code to figure out how to
use it (in lieu of the docs). There would be a lot less stuff to
filter out.
Anyway, not really important, but an interesting side effect, I think.
Matt
8. Re: Data hiding
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Here is my [quick] evaluation of the current proposals:
> > >
> > > CChris:
> > > Pro - gives "transitional" capability to hide info from outside file
> > > - high granularity of symbols to hide/expose
> > >
> > > Con - seems overly complicated (5 new keywords, total 7 different uses)
> > > - can't "firewall" symbols (unless that's what restrict does)
> >
> > So yes, it does firewall a single symbol, in cases this is not covered
> > by file wide approaches. It can also extend it if the rules firewall a
> > symbol too narrowly.
> >
> > See also, in the discussion of the "with package" directive:
> > "Once the scope of a symbol has been defined by its active package, it
> > can be changed only by a *restrict* directive. "
>
> OK, so that moves to the Pro side.
>
> > > ??? - how will package naming conflicts be dealt with
> > >
> >
> > From the end of the introduction:
> > "Since a package is the way to specify that a few source files belong
> > to a single logical entity, the library, irrespective of their being
> > clustered in one or more directories, the package identifier should be
> > chosen so as to be very likely unique. Concatenating the library name,
> > author name and version number should be adequate."
> >
> > There is a typo in the posted text, I'l correct it.
> >
> > In my implementation, an error is raised if a package name appears in
> > two different *package* directives. I'll mention that explicitly.
> >
> > Now that I think about it, adding the version info in the package name
> > isn't a good idea either. The rest should be enough.
>
> Ok, so to summarize, non-unique package names cause errors, which would
> be bad. Best practices will be documented to choose package names that
> are unlikely to be duplicated. Less than ideal, in my book, but if the
> suggestions are followed, it shouldn't be a real problem.
>
> > Well, it looks like at last you read the paper .
>
> I've looked at it several times, but either didn't have the time to slog
> through it, or was too tired to figure it out. And each time I read it
> I understood it a little better. Also, IMHO, we're finally on the
> same topic. :)
>
> > I don't agree with the metrics you use for simplicity, but that is
> > another topic.
>
> The metrics weren't really what drove my complexity evaluation. They
> were really based upon my impression of how difficult I found it to work
> out how to use it, and what some of the implications were. The keywords
> were just illustrative, but I think they do a good job in showing that
> your approach has many more "moving parts" and ways that things can
> interact. It just adds up to more things that have to be understood
> and used correctly to get the desired results.
>
Sorry, but this doesnt take into account the range of problems solved or the
flexibility gained. You look only at the input (how many extra keywords, as if
that mattered) and don't check the ouput (the gain in functionality or
flexibility). It's a harmfully one sided way to assess things.
I'd define simplicity as a low enough output/input ratio of sorts, not just the
input.
> Which, of course, doesn't necessarily make it worse, but given the
> choice between two equivalents, I'll prefer the more simple of the two
> nearly every time, so I consider higher complexity to be a Con.
>
> Seeing examples might change my mind, as sometimes it's hard to simply
> visualize. And, of course, I'll always have less trouble understanding
> my own ideas, even if only because I've thought about them more.
>
I may find time this weekend to populate Pete's site, hopefully.
I started tidying up the code for the package implementation, as it also
contains another addition, the share and redefine directives. Since *share* aims
at reducing the use of global variables for interfile communication, it could be
part of the solution, but didn't include it out of simplicity - believe it or
not. Will have to test it again.
Updating CRoutine_id() and friends will take some time, as an extra piece of
info will be needed in the IL: the list of included files parents, plus the new
S_FILE_UPPER SymTab field. No problem with current IL, as the default value of 0
means no packaging. It also has to be known in translated code - the murkier part
(for me). So don't expect the files being posted within the next couple days;
timing is bad too.
> One side benefit that I think would be encouraged by my approach is that
> in the main include file of a library, you'd be more likely to have only
> globals that were meant to be exported (the external interface of the
> library). So intra-library API stuff that needed to be shared among the
> files but that you wanted to hide would be put into its own file, and
> imported by the other parts of the library. It would leave less stuff
> in that interface file. I often go to the code to figure out how to
> use it (in lieu of the docs). There would be a lot less stuff to
> filter out.
>
Is this always a good idea?
If a library covers several fields of functionality, it would make sense, to the
contrary, for interface symbols to apear in the relevant domain subinclude,
rather than in the all purpose main file. GUI libs are an obvious example, and
they are currently the most complex libs written in Eu AFAIK - Pete already wrote
about this. The subinclude files may need common services from both the main file
or common subsub include files.
Using the main file may be avoided if the interfile API is confined in some
library level scope aka package - back to square one.
> Anyway, not really important, but an interesting side effect, I think.
>
> Matt
CChris
9. Re: Data hiding
CChris wrote:
>
> Matt Lewis wrote:
> >
> > The metrics weren't really what drove my complexity evaluation. They
> > were really based upon my impression of how difficult I found it to work
> > out how to use it, and what some of the implications were. The keywords
> > were just illustrative, but I think they do a good job in showing that
> > your approach has many more "moving parts" and ways that things can
> > interact. It just adds up to more things that have to be understood
> > and used correctly to get the desired results.
>
> Sorry, but this doesnt take into account the range of problems solved or the
> flexibility gained. You look only at the input (how many extra keywords, as
> if that mattered) and don't check the ouput (the gain in functionality or
> flexibility).
> It's a harmfully one sided way to assess things.
>
> I'd define simplicity as a low enough output/input ratio of sorts, not just
> the input.
And I'd argue that you're really talking about some sort of efficiency
measure. Something that's complex but powerful isn't necessarily
better or worse than something that's simple and slightly useful. I
was merely talking about the relative complexity of the proposals,
which needs to be judged against the output. Other bullet points
were there to address those things.
> Updating CRoutine_id() and friends will take some time, as an extra piece of
> info will be needed in the IL: the list of included files parents, plus the
> new S_FILE_UPPER SymTab field. No problem with current IL, as the default
> value
> of 0 means no packaging. It also has to be known in translated code - the
> murkier
> part (for me). So don't expect the files being posted within the next couple
> days; timing is bad too.
You might take a look at what I did (it's in both the trunk and mwl branch)
for using that info in the translator (also bound/shrouded code, of
course).
> > One side benefit that I think would be encouraged by my approach is that
> > in the main include file of a library, you'd be more likely to have only
> > globals that were meant to be exported (the external interface of the
> > library). So intra-library API stuff that needed to be shared among the
> > files but that you wanted to hide would be put into its own file, and
> > imported by the other parts of the library. It would leave less stuff
> > in that interface file. I often go to the code to figure out how to
> > use it (in lieu of the docs). There would be a lot less stuff to
> > filter out.
> >
>
> Is this always a good idea?
> If a library covers several fields of functionality, it would make sense,
> to the contrary, for interface symbols to apear in the relevant domain
> subinclude, rather than in the all purpose main file. GUI libs are an
> obvious example, and they are currently the most complex libs written
> in Eu AFAIK - Pete already wrote about this. The subinclude files may
> need common services from both the main file or common subsub include
> files. Using the main file may be avoided if the interfile API is
> confined in some library level scope aka package - back to square one.
There's no reason that you couldn't have multiple external interface files,
and one or more internal interface files (which all get imported by the
various parts of the library that use them). To go back to your concerns
about the complexity argument, your solution certainly has more flexibility,
and probably slightly more power, but at the cost of a lot of complexity.
Perhaps once we can all get some decent examples, we can put another poll
out there to see what others think. Before that, I'd be especially
interested in what Rob and Derek think about all this--we'll probably
just get another 2 proposals. :)
Matt
10. Re: Data hiding
Matt Lewis wrote:
> I'd be especially
> interested in what Rob and Derek think about all this
So far, I think you have both lost the plot. I can't support much of what I can
see being suggested. Overly complex, un-intuitive and trying to solve problems I
don't think we have.
I think that the current name resolution mechanisms work for all cases except
one and that is the one that should be fixed. It can be fixed without introducing
new keywords.
The principle should be that a statement can only reference a symbol that is can
know about. And that means the symbol is either defined in the same file as the
referring statement, or is a global symbol defined in one of the files included
(at any depth) by the file with the referring statement. This also means that it
cannot be referring to a symbol defined in another include tree that it didn't
actually include.
If X is defined as global symbols inside fileA and fileB, then statements in
fileA can never refer to the X in fileB and visa versa, unless fileA includes
fileB in which case the author of fileA must use namespaces to disambiguate.
To put it another way, if fileA refers to X it is referring to the X in fileA.
If fileB refers to X it is referring to the X in fileB. If subsequently, fileA
and fileB are both included together in fileC, there should still not be a clash
and they still refer to the same X that they did before being included. If fileC
refers to an X, the author of fileC must disambiguate using namespaces.
Also, enable the file name to be an automatic namespace.
include fileB.e
include fileA.e
a = fileB:X
b = fileA:x
Making these rule changes will cover all cases, I believe. No new keywords, no
un-intuitive concepts to grasp, and solves the one potential problem for third
party library developers.
The other thing to help would be that when Euphoria detects an ambiguous
reference, it tells the coder about all the possible places that the symbol
resides in so the author can decide which namespace to use.
--
Derek Parnell
Melbourne, Australia
Skype name: derek.j.parnell
11. Re: Data hiding
Derek Parnell wrote:
>
> Matt Lewis wrote:
> > I'd be especially
> > interested in what Rob and Derek think about all this
>
> So far, I think you have both lost the plot. I can't support much of what
> I can see being suggested. Overly complex, un-intuitive and trying to
> solve problems I don't think we have.
I sort of agree with you. There are really two issues being discussed.
There's the issue of symbol resolution, and of data hiding. You've
addressed the symbol resolution issue similarly to what I've implemented.
I see two real outstanding issues related to this. The first is the
inherited namespaces (see my last response in the symbol resolution thread
to CChris) and whether we allow non-included symbols to be resolved.
I basically agree that data hiding is not a problem per se, but more of
a nice to have feature.
> I think that the current name resolution mechanisms work for all cases except
> one and that is the one that should be fixed. It can be fixed without
> introducing
> new keywords.
>
> The principle should be that a statement can only reference a symbol
> that is can know about. And that means the symbol is either defined
> in the same file as the referring statement, or is a global symbol
> defined in one of the files included (at any depth) by the file with
> the referring statement. This also means that it cannot be referring
> to a symbol defined in another include tree that it didn't actually
> include.
This is essentially what I've done already, with the exception that
referencing an un-included symbol results in a warning rather than an
error. This was largely for backwards compatibility. I guess it just
depends upon how strict we want to be with this. As I mentioned,
even the eu source code did this a lot (now fixed in the mwl branch).
<snip>
> Making these rule changes will cover all cases, I believe. No new keywords,
> no un-intuitive concepts to grasp, and solves the one potential problem for
> third party library developers.
Agreed.
> The other thing to help would be that when Euphoria detects an ambiguous
> reference, it tells the coder about all the possible places that the
> symbol resides in so the author can decide which namespace to use.
I thought it already does this....[looking]...Ah, I guess it stops
checking once it finds one conflicting symbol. So the change would be
to keep looking and report all possibilities. That would be useful.
Matt
12. Re: Data hiding
Matt Lewis wrote:
> Perhaps once we can all get some decent examples, we can put another poll
> out there to see what others think. Before that, I'd be especially
> interested in what Rob and Derek think about all this--we'll probably
> just get another 2 proposals. :)
Over the years, I've spent many many hours discussing
namespace-related language issues, and hypothetical problems
that might arise, in some program, someday. I've only rarely
encountered in my own code, or read about on this forum,
any actual problems, and those seemed fairly easy to fix
by *horrors!* tweaking the source. So either this is a
very minor problem, or I just don't have the right experience
to appreciate it. So I plan to sit on the sidelines until
there's a vote on a concrete proposal.
My gut feeling is obviously in favor of a minimalist approach
to addressing this issue.
I think a more important immediate issue
is to get a version of Win32Lib released
that actually works properly with the IDE,
without requiring an extra package of special fixes.
I think that must be putting off a lot of newbies.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
13. Re: Data hiding
- Posted by Igor Kachan <kinz at peterl??k.ru>
Oct 17, 2007
-
Last edited Oct 18, 2007
Matt Lewis wrote:
[snip]
> It's an admittedly minimalist approach, but that's part of what I like
> about it (and why I think it's particularly suited for euphoria).
>
> ex:
> }}}
<eucode>
> -- myapp.ex
> include libMatt.e
> import libPete.e
> global object PETE
>
> -- PETE is visible from libMatt.e
> -- PETE is not visible from myapp.ex
>
> --myapp.ex
> include libMatt.e
> import libPete.e
> global object PETE
>
> include libPete.e
>
> -- PETE is visible from libMatt.e
> -- PETE is visible from myapp.ex
> </eucode>
{{{
[snip]
There is one strange thing in Euphoria, namely the "as" word.
Rob considers it as not a key word, but just as an element,
so to say, of the second form of the 'include' command.
Good, why not?
But that famous "as" could to be the powerful metacommand.
Really it already is that metacommand, but with too little
duty.
To resolve the examples like to above one, I'd suggest some
new parameter for the "as" metacommand - "sublibrary":
-- lib_a.e
global object A, Z
A = "aa"
Z = "zz"
-- eof
-- lib_b.e
include lib_a.e as sublibrary -- all globals of lib_a.e
global object B, C -- are visible just in lib_b.e
B = "bb" -- 'sublibrary' is a parameter, not
C = "cc" -- a prefix of namespace
A = "AA" & C
-- eof
-- my_app.ex
include lib_b.e without C -- global C of lib_b.e is invisible
global object C -- in my_app.ex
C = "CC"
include mu_app_plugin.e -- global C of my_app.ex is visible
-- in my_app_plugin.e
-- eof
I think, we can implement some useful things using new
parameters for old good key words 'with', 'without' and 'as'.
For now, I do not see any need of new keywords in Euphoria.
> I'd be interested in hearing from people other than us 3. :)
OK, did you listen to me, may I continue ?
Regards,
Igor Kachan
kinz at peterlink.ru
14. Re: Data hiding
- Posted by Matt Lewis <matthewwalkerlewis at gma?l.co?>
Oct 17, 2007
-
Last edited Oct 18, 2007
Igor Kachan wrote:
>
> To resolve the examples like to above one, I'd suggest some
> new parameter for the "as" metacommand - "sublibrary":
>
include lib_a.e as sublibrary -- all globals of lib_a.e
> I think, we can implement some useful things using new
> parameters for old good key words 'with', 'without' and 'as'.
> For now, I do not see any need of new keywords in Euphoria.
>
> > I'd be interested in hearing from people other than us 3. :)
>
> OK, did you listen to me, may I continue ?
It's a good idea in that it doesn't create any new keywords. My only
concern is that we're overloading the 'as' usage of include.
Obviously, you couldn't have a namespace called sublibrary. How would
you namespace something that was included as a sublibrary?
The with/without directives are easier to add functionality to since their
next parameter defines the functionality by definition. Here, you've
changed the as keyword. It's easy enough to implement into the parser,
but I think it's not obvious that you're not just assigning a namespace.
Maybe something like:
include as private lib.e as lib
The difference being that the placement of 'as' changes its meaning, rather
than simply what comes after. I think I like 'private' over sublibrary.
It's a bit more direct and connected with what its really doing. But
this syntax seems to stand out more to me than changing 'include' to
'import.'
Matt
15. Re: Data hiding
- Posted by CChris <christian.cuvier at agric?lt?re.gouv.fr>
Oct 18, 2007
-
Last edited Oct 19, 2007
Robert Craig wrote:
>
> Matt Lewis wrote:
> > Perhaps once we can all get some decent examples, we can put another poll
> > out there to see what others think. Before that, I'd be especially
> > interested in what Rob and Derek think about all this--we'll probably
> > just get another 2 proposals. :)
>
> Over the years, I've spent many many hours discussing
> namespace-related language issues, and hypothetical problems
> that might arise, in some program, someday. I've only rarely
> encountered in my own code, or read about on this forum,
> any actual problems, and those seemed fairly easy to fix
> by *horrors!* tweaking the source. So either this is a
> very minor problem, or I just don't have the right experience
> to appreciate it. So I plan to sit on the sidelines until
> there's a vote on a concrete proposal.
> My gut feeling is obviously in favor of a minimalist approach
> to addressing this issue.
>
> I think a more important immediate issue
> is to get a version of Win32Lib released
> that actually works properly with the IDE,
> without requiring an extra package of special fixes.
> I think that must be putting off a lot of newbies.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
1/ Data hiding is essential to allow libraries to break up into smaller,
maintainable files (I don't consider a 33,000+ line giant as maintainable)without
this resulting in new undocumented global symbols popping out of the box and
clashing with applications. This is why I don't consider it as just "nice", but
"necessary" to have.
2/ I'm waiting for Andy to confirm whether the keyboard sticky shifts issue is
now settled (Judith appears to be getting correct behaviour). Then the (default)
print size issue neds be addressed; I hope I can do this over the weekend, RL
allowing. Then the library itself should be actually ready to go.
3/ The issue of EuCom breaking with 0.70.1/2, in my opinion, shows how flawed -
out of simplicity - the current namespacing scheme is. What would be your
solution to the current problem EuCom faces? Assuming it's the only set of source
files which is getting into trouble.
CChris
16. Re: Data hiding
- Posted by CChris <christian.cuvier at agri?ul?ure.gouv.fr>
Oct 18, 2007
-
Last edited Oct 19, 2007
Derek Parnell wrote:
>
> Matt Lewis wrote:
> > I'd be especially
> > interested in what Rob and Derek think about all this
>
> So far, I think you have both lost the plot. I can't support much of what I
> can see being suggested. Overly complex, un-intuitive and trying to solve
> problems
> I don't think we have.
>
> I think that the current name resolution mechanisms work for all cases except
> one and that is the one that should be fixed. It can be fixed without
> introducing
> new keywords.
>
If the number of keywords is such an important issue - I don't get it - , then
you can easily get rid of "end", "then" and "do" at least, just by using
indentation and line breaks instead, which are much clearer visually. This would
leave some room for more useful additions.
CChris
17. Re: Data hiding
Matt Lewis wrote:
>
> Igor Kachan wrote:
> >
> > To resolve the examples like to above one, I'd suggest some
> > new parameter for the "as" metacommand - "sublibrary":
> >
> }}}
<eucode>
> include lib_a.e as sublibrary -- all globals of lib_a.e
> </eucode>
{{{
> > I think, we can implement some useful things using new
> > parameters for old good key words 'with', 'without' and 'as'.
> > For now, I do not see any need of new keywords in Euphoria.
> >
> > > I'd be interested in hearing from people other than us 3. :)
> >
> > OK, did you listen to me, may I continue ?
>
> It's a good idea in that it doesn't create any new keywords. My only
> concern is that we're overloading the 'as' usage of include.
> Obviously, you couldn't have a namespace called sublibrary. How would
> you namespace something that was included as a sublibrary?
>
> The with/without directives are easier to add functionality to since their
> next parameter defines the functionality by definition. Here, you've
> changed the as keyword. It's easy enough to implement into the parser,
> but I think it's not obvious that you're not just assigning a namespace.
>
> Maybe something like:
> }}}
<eucode>
> include as private lib.e as lib
> </eucode>
{{{
>
> The difference being that the placement of 'as' changes its meaning, rather
> than simply what comes after. I think I like 'private' over sublibrary.
> It's a bit more direct and connected with what its really doing. But
> this syntax seems to stand out more to me than changing 'include' to
> 'import.'
Ok, I do not like very much that "sublibrary" too.
Maybe just "$" is better here.
Say:
include lib_a.e as $ -- we see only its own globals
include lib_a.e as $A -- we see only its own globals with prefix A:
include lib_a.e as $B. -- we see only its own globals with pefix B.
include lib_a.e as C -- we see all its globals (current syntax)
include lib_a.e as $D without EE -- we do not see just EE
The "$" sign already is reserved in Euphoria, so it can
be used in other contexts with some new duty and sense.
About "private" word I can say -- it is already used in
Euphoria documentation for saying about the hidden
*inner variables* of routines, so it seems to be not
very good to tell about *global* things.
Regards,
Igor Kachan
kinz at peterlink.ru
18. Re: Data hiding
Greetings all, it's been a while
I'm glad to see how Eu is progressing.
Robert Craig wrote:
>
> Over the years, I've spent many many hours discussing
> namespace-related language issues, and hypothetical problems
> that might arise, in some program, someday. I've only rarely
> encountered in my own code, or read about on this forum,
> any actual problems, and those seemed fairly easy to fix
> by *horrors!* tweaking the source. So either this is a
> very minor problem, or I just don't have the right experience
> to appreciate it. So I plan to sit on the sidelines until
> there's a vote on a concrete proposal.
> My gut feeling is obviously in favor of a minimalist approach
> to addressing this issue.
Forgive me if I'm reiterating what's already been discussed,
I haven't read the entire thread from the beginning...
Has it been established what exactly the issue is that is trying to be
addressed?
Aside from file name collisions, which has been conquered now,
I consider this issue be the next milestone for Eu's progress
as a fully capable language. There is already a large amount of contamination
of the global namespace for the sake of identifiers that are only relevant to
specific program states.
A huge majority of this issue revolves around the use of
constants that define indexes to some structured sequence.
It's not uncommon for a library to define a sequence structure
along with a set of global index constants.
It's also not uncommon for a large api to be divided amongst
several library files, some of which require globals for inter-communicating
although those globals may not be intended for end-user access.
Attempting to create modular library files such as widgets or simple objects
highlight the situation.
While there is workarounds, such as using prefixes or namespacing, they are not
exactly desirable or optimal.
The average project I work on is between 500kb and 4mb of source code.
When dealing with such a large amount of code on a regular basis, it's not
at all uncommon to run into namespacing problems which can only be resolved
with verbosity and/or cascading modifications throughout the project.
Tweaking is not a very practical option as people don't intentionally
program naming collisions into their own code. The issue arises when 3rd-party
libraries are introduced. I think it's taboo to consider modifying distributed
code
as a solution. Forget about how often the issue has been
encountered thus far. Consider how many ppl may have rejected Eu because of
these types of shortcomings. People who might have been contributing to the
archives,
which is the ultimate issue that Eu must address if it will compete with
other practical languages. Every programmer needs resources.
In it's purest form, Eu is extremely elegant and attractive, but the more
complex
the projects get, they begin to get obfuscated with workarounds because of Eu's
simplicity.
At the least, I find this problem distracts the workflow and abstracts code.
> I think a more important immediate issue
> is to get a version of Win32Lib released
> that actually works properly with the IDE,
> without requiring an extra package of special fixes.
> I think that must be putting off a lot of newbies.
That is valid, but a separate department.
Not everyone is going to be working on win32lib.
Chris Bensler
Code is Alchemy
