1. Re: Namespace (was "indexes")
----- Original Message -----
From: "Jiri Babor" <jbabor at PARADISE.NET.NZ>
To: "EUforum" <EUforum at topica.com>
Subject: Re: indexes
Hi Jiri,
>
> >> Allow *any* local declarations in so included files to be
> >> accessible using the standard 'dot' notation.
>
> > Are you saying that not only global symbols, but local ones as well,
> > can be accessed from outside the include file? Why is that?
>
> First of all, Derek, this is *not* my preferred solution (see my
> previous suggestion, a combination of 'global' and 'export' keywords,
> 'global' with the current syntax for both legacy code and important or
> 'system-wide' declarations, and new 'export' to be used with the dot
> notation), just an alternative.
Fair enough.
>I thought, you as the developer and
> maintainer of a relatively large library, win32lib, would be quite
> interested in the 'monolithic' concept. It would allow you to break up
> the monster into more conveniently sized chunks *without* labelling
> just about everything global.
I certainly am interested. Very interested. I hope I haven't given anyone
the contrary impression.
> > I thought the idea of having local symbols was so that the author
> > can explictly hide implementation details from users of a library.
> > The implmentation details being in local routines, constants and
> > variables. This is pretty well agreed in computer science circles to
> > be a "good thing".
>
> To be quite honest, I do not give a damn about what 'is pretty well
> agreed in computer science circles to be a "good thing"'. I have been
> a scientist for more than 35 years now, and in my humble opinion,
> scientists rank only very close second behind managers in promotions
> of all sorts of dubious, impractical solutions to the real world
> problems. But I am diverging...
>
And of course, you are definitely NOT saying that all scientists, now and in
the past, should never be listened to.
> There is nothing inherently good, or bad, for that matter, with
> information hiding, that became suddenly so popular and important with
> emergence of OO designs. In case of OO, at least, it can be almost
> justified for reasons of safety.
Well I must disagree with this opinion. "Information hiding" has been
discussed since the 1960's and promoted by nearly everyone as a useful tool
for programming.
> > The idea being that the author of a library should be free to change
> > the internals of a library provided that the published interface
> > remains the same. If the author cannot be sure that changing an
> > internal object will not break somebody else's code, it makes things
> > a bit hard for everybody.
>
> I think, the key words in the preceding paragraph are 'the published
> interface'. In other words, proper documentation is really the
> decisive factor. Beyond that, if as a user you rely on 'undocumented
> features, you better know what you are doing ;).
>
Doesn't this mean that information hiding might be useful?
I certainly do not want to have the situation where I can't change some
internal aspect of win32lib.ew because it would or might break too many
people's code. To go and make changes, knowing this, is arrogant and
uncaring, and possibly not commercially viable either. I would much rather
declare that some parts of the library are off-limits and protecting myself
by actually making them off-limits as well. If people want to get access to
internal routines, then I guess there is nothing to stop them, but at least
they currently have to do it by explictly invalidating the "contract". That
is, they have to change the library code (add a "global" specifier) to get
access.
>
> >> 3. flag as an error duplicate use of the same 'as name' for
> >> different include files.
> >
> > Why is this a good idea? I can imagine situations that would be the
> > equivalent of ...
> >
> > include graphics.e as rds
> > include get.e as rds
> > include file.e as rds
>
> It would not be such a good idea, if not *all* symbols of included
> files were accessible from outside. But if they are, as in my second
> proposal, which by the way I like much less today than I did
> yesterday, then the potential for all sorts of name collisions is just
> too great.
>
I guess its the English semantics getting in the way of this proposed
keyword "as". Maybe if we start thinking about it as "into" it might work
better.
include graphics.e into rds
include get.e into rds
include file.e into rds
include file.e into dos
The "as" keyword suggests a renaming effect, but I'm more thinking about a
"list" effect. In other words, a namespace is a list of objects that could
be declared in many different places. I'm trying to seperate any connection
between the name of a symbol and where it is declared.
------
Derek Parnell
Melbourne, Australia
"To finish a job quickly, go slower."
