List was dropped. Sent from my iPhone
On Jun 1, 2009, at 4:19 PM, David Brownell <davi...@pacbell.net> wrote: > On Monday 01 June 2009, Rick Altherr wrote: >> On May 31, 2009, at 7:41 PM, David Brownell <davi...@pacbell.net> >> wrote: >>> On Sunday 31 May 2009, Michael Bruck wrote: >>>> >>>> The 'struct foo_s' syntax is code bloat that obscures the actual >>>> algorithms. 'foo_t' is shorter. >>> >>> Disagree about obscuring. And "shorter" doesn't matter here. >>> >>> If I see "foo_t" I have no idea what kind of thing it is. >>> If I see a "struct foo" there's no such confusion. >>> >>> Ergo, "foo_t" has obscured. >>> _______________________________________________ >>> Openocd-development mailing list >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >> >> If encapsulation is the goal, then you don't care about the >> underlying >> definition of foo_t unless you are the module that implements foo. > > It's *a* goal, not *the* only goal. And "encapsulation" is > not a binary thing; it's a spectrum. Plus, remember that the > costs of hiding can easily exceed the benefits thereof... > Sure. You don't want to waste a lot of time in simple accessors if they are called frequently enough. The main benefit in encapsulation is removing the burden of "doing the right thing" from the caller. Since we are already moving towards accessor functions instead of direct struct access, we may as well hide the fact that it is one. It opens up our options for growth in the future. > >> A foo_t is simply a foo and as a caller you dont need to know any >> more > > This is C, not a language that incorporates a strong notion > of abstract data types. Somewhat the opposite; from the very > beginning, it's tried to make some things subtly visible. > The language doesn't actually do either. It offers features that allow either styles to be used. Either way, with encapsulation, knowing the underlying implementation data type isn't relevant to anyone outside that module. Since we are moving towards accessor methods, we might as well finish the encapsulation and hide the internal data type. > >> In that case declaring it as struct everywhere exposes an >> implementation choice with no benefit. If foo were to ever change in >> type (consider a change from a pointer to a struct to an int or vice >> versa), you'd need to change all of the function protoypes. For >> encapsulation in C, the API should expose an opaque handle that the >> module can convert to the internal representation. A typedef that >> expands to a pointer to a struct hides the implementation choices >> from >> the callers and reduces the chances of doing inappropriate things to >> the handle. Further, the implementation can do the "conversion" by >> simply defining the underlying struct. Thus, the public for the >> module >> contains a forward struct declaration and the handle typedef while >> the >> private just adds the actual struct definition. > > Again, that presumes you're going after a strong notion of abstract > data types. I've certainly worked in languages structured around > such notions. > > Now, as a *designer* I really don't need extra help from C or > idioms in order to achieve "strong enough" typing. In fact one > thing I like about C (versus, say, C++ or Java; or assembler) is > that it makes it easy to achieve the *right* level of information > hiding, which is somewhere between "all" and "none" and varies > based on the task at hand. > > As a member of a programming team, I've unfortunately seen more > folk abuse strong typing than one who use it well. "Very Strong" > information hiding requires a preternatural level of advance > knowledge about what the interface will need to do and how it will > evolve -- or a commitment to evolve the relevant interface(s) in > ways that don't block other developers. That latter is very > hard to achieve, at least without having everyone on the team > "know" (wink, wink) how the "interface" is implemented. > > In short, it just works better if I don't take strong/purist > stances on ADTs except as part of a well defined messaging > framework (kernel/userspace, client/server, etc) where it's > widely acknowledged to be a core architectural issue. > > - Dave > C and C++ are both strongly typed and any sort of weak typing requires some layer on top of the language primitives. It is cetainly possible to go overboard with weak typing and/or encapsulation, but proper use of an abstract type can greatly simplify the implementation as the efforts to simplify the target APIs has shown. We are already adopting most of the encapsulation paradigm for targets and ADTs build on that. We may as well make our lives simpler and follow that paradigm as well since we are currently doing so half-heartedly. I recently spent 2 years defining a C API that uses encapsulation and ADTs and we've already shown that by doing so we have reduced the time to add new derived types since the infrastructure already exists. Further, users get a simpler view of the types since the only need to worry about the abstract types and the actual types in use are an implementation detail that can and has changed. No one in this case has had to "know" how the interface works and yet we've been able to easily expand the functionality with no impact on the user-visible API. I think that a well thought out implementation of an abstract target type and interface will do wonders to the code base and maintenance. Using encapsulation will make this even better for future expansion and enhancement. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
