Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: typedef ... refactored Date: Fri, 28 Aug 2020 05:05:11 -0700 Organization: A noiseless patient Spider Lines: 39 Message-ID: <86mu2f9ds8.fsf@linuxsc.com> References: <7a5f16a3-d30d-46ec-9926-b0736428902do@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="9035d0fd7127b99c8fa8fe8c15caa128"; logging-data="7319"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+KcnZsW9lEMiQbPf+IOuKRw9SxB8efRuM=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:7BerFDDSWP/blDt5vMDPwc7iQPU= sha1:z95STSYc2q0FpHziux7W6ttVs98= Xref: csiph.com comp.lang.c:154096 John Bode writes: > On Sunday, August 9, 2020 at 3:07:38 AM UTC-5, G G wrote: > I've taken a pretty hard line against using typedefs - if the > user of the typedef name has to be aware of the representation of > the type it's aliasing in order to use it properly, then there's > no point behind using a typedef in the first place. "Making > declarations a little less eye-stabby" is not a sufficient reason > to use a typedef. "Leaky" abstractions are worse than no > abstractions IMO. > > If you're going to hide `struct treeNode` behind a typedef, then > you'd better be willing to create a full API to abstract away > *all* the operations on that type so the user doesn't have to be > aware of any aspect of its representation. Otherwise you're just > creating heartburn where it isn't necessary. I think I understand the position you're advocating. Partly I agree but also would like to offer some additional considerations. First is that structs being abstract types should very much be the common case and not the exceptional case. Abstraction and information hiding is a good thing, and structs in particular should follow this principle as a rule and not as an afterthought. Second is that abstraction is the right choice even if some clients need to look "under the hood" in certain cases. Obviously we would prefer abstractions that are 100% solid and never subject to client inspection or (especially) modification. In practice though some exceptions may be allowed to preserve the benefits of abstraction as long as the costs aren't prohibitive. In particular I don't think the choice is all-or-nothing; as long as the ROI is positive the choice should be to opt for abstraction even though it may prove necessary to grant exceptions to some clients in some cases. The important thing to guard against is unrestrained violation of the abstraction barrier.