Re: Weighing in on everything
CChris wrote:
>
> Matt Lewis wrote:
> >
> > Yes, I agree with this statement. I'm just having trouble fitting it in
> > with "Inclusion of a parent file by a file provides a shaky basis for
> > inheritance." I guess you're saying you'd prefer a different way to
> > indicate that the file relies on its parent.
> >
>
> The point is that there are different reasons why a file has to rely on its
> parent.
> Inclusion may be used to aggregate several pieces of a program. Judith's
> IDE is the biggest example perhaps. The parts, ie included files, are not
> inheriting anything, and they are hardly meant to be reusable, since the
> amount of communication between branches and headquarters is large
> enough to defeat any attempt at genericity. Such files are usually marked
> aspieces of a program using comments. No need for back inclusion or warning
> here, its kludgy but harmless.
In a large project, I would argue that adding those extra includes promotes
easier maintenance. Consider that "Judith's" IDE did not start off as her
project. Nor is she the only one who hacks on the code.
> In other cases, inclusion is a device to enable access to common data and
> methods, oops routines. There, an included file is intended to be included
> by possibly several, different parent files. This is not exactly
> inheritance, since the parent needs to know about its derived classes,
> oops files, but that's the closest we can get so far. Such a file relies
> on another to include it. The practice can be seen as enhancing reusability,
> and should be encouraged. Yet, back inclusion forces to modify the included
> file (unless you wisely turn warnings off).
I agree that 'back inclusion' (a nice term, BTW) is not always the correct
pattern to use. Take a look at mode.e from the euphoria source for an
example of an alternative. Previously, the constants initialized through
mode were put in the .ex files (int.ex, eu.ex, etc) and were utilized
throughout. Now they are initialized from these files, and the actual
constants declared in global.e (which pretty much everyone already
included).
> So, back inclusion appears as added typing for either zero or slightly
> negative outcome. It does not add any functionality that I know of.
I don't see how there's any negative here. One thing it does is protects
the file when using third party code. Suppose that a user of your library
combines it with another library that defines a global of the same name.
Now your library will break if the other library is included first.
We talked about walking back up that chain, but therein madness lies, I
think. The metric would likely get very complex, and certainly confusing
to developers, who wonder why otherwise functioning libraries break for
strange reasons.
I remain baffled as to why you think it's a good idea to use symbols in
files that you don't include. Maybe it's just me.
How do others feel about this?
Matt
|
Not Categorized, Please Help
|
|
