Philip Brown writes: > Alan Coopersmith wrote: > > Sounds like the fastest way to chase away every engineer who would ever > > possibly want to work on the code. Not everything that can be used as > > an interface should be. > > Well, I guess we should then define what we mean when we say "an interface", > for this discussion, then :-} > > I dont consider "all macros and function calls" to be in the scope of this > discussion.
They are interfaces, in terms of architectural review. File names, paths, and formats are interfaces. Network packet layouts and interactions are interfaces. Data structures and calling conventions are interfaces as well. > Rather, "[this 'code module' over here] interacts with [that 'code module' > over there]. How they interact, is 'an interface'" > > I guess there's still some ambiguity about, "how big is a code module?" > > Well, let's say, "something big enough to get the ARC's attention". I don't see how "code module" is a atomic unit of 'interface' description sufficient for architectural review. There's a huge difference between one "code module" calling a documented stable function declared in another "code module" (on one hand), and a "code module" calling an undocumented private internal implementation detail in another "code module" (on the other hand). The two are quite different, but seem to be conflated together by the granularity you've chosen. How should we apply this new "no private interface" rule with that granularity? -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
