Re: Weighing in on everything
Matt Lewis wrote:
>
> CChris wrote:
> >
> > Matt Lewis wrote:
> > >
> > > Good, working namespaces are now in there. The current debate is about
> > > the
> > > syntax, but not the functionality, except for the default namespace thing,
> > > but that's just a little nice to have thing, that may or may not be a good
> > > idea. I don't think we've explored that enough.
> > >
> >
> > Sorry to disagree, Matt.
> >
> > 1/ If a library uses several files, and a symbol is being used by several
> > of those files, it will be seen by an application using the lib, and
> > possibly interfere with it. In the changes you submitted, this condition
> > sometimes causes a warning, but that will drowned in the noise, as most
> > current warnings are pointless (short circuiting, locavl symbol not used,
> > etc). There is no way to tell that a symbol is intended for restricted
> > access from outside its definition file.
>
> I agree that the namespace implementation doesn't go this far, and that
> this is (at a high level, at least) where we need to go. I still stand
> by my characterization, though, because they at least make it possible
> to get working code without modifying 3rd party code.
>
> Ignoring the warning reflects more upon the programmer than the tool, IMHO.
> Warnings show something that the programmer should consider, because they
> are things that are easy to miss, and that can cause problems. I think
> there has been some talk of suppressing warnings, which would alleviate
> this a bit. But the warnings for not including a file are a Good Thing.
>
> > 2/ The current global resolution rules make any library routine difficult
> > to override. You can override it once, and twice for a builtin, and then
> > you have to mess around with namespaces, assuming this will always work.
> > Try out with print() and sprint(). And the prototypes must match, so
> > extending a routine is downright impossible, or quite clumsier than in
> > most other languages. And accessing the underlying routine from the
> > override requires another awkward call_func() and an extra symbol to hold
> > a routine_id.
>
> I guess so. Can you give me an example of where you'd [like to] do this?
> If your package solution fixed this particular issue, I don't recall the
> details.
>
I think http://oedoc.free.fr/Fichiers/ESL/complex.zip is a good nest of
examples, specially in the print/format section..
If a symbol is put inside a package so as to be kept off limits, so redefining
it becomes at all possible without artificially imposing a namespace on the user
of say a library.
> > 3/ Inclusion of a parent file by a file provides a shaky basis for
> > inheritance, which is a time proved way of having vleaner, easier to
> > maintain code. The latest changes didn't rule it out, but this generates
> > a warning as if it were a discouraged coding practice. This doesn't hurt
> > much admittedly, but is quite worrisome to me.
>
> I'm having trouble understanding this point. Could you expand on what you
> mean by inheritance? Are you talking in an OO sense?
>
An include file that relies on its parent's feature is exactly as useful and
legitimate as a class/object type that derives from an ancestor. It simply relies
on a context.
> > So, even though the namespace system will be improved, I can't really say
> > it's good.
>
> Then we can agree to disagree. Again, I'm not arguing that they can't be
> made better.
>
> Matt
CChris
|
Not Categorized, Please Help
|
|
