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
|
Not Categorized, Please Help
|
|
