OpenEuphoria

Re: Data hiding

• Posted by CChris <christian.cuvier at agric?lt?re.gouv.fr> Oct 18, 2007
• 578 views

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