Re: Weighing in on everything
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.
> 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?
> 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
|
Not Categorized, Please Help
|
|
