Why using manystatic methods in a class
in [C++]
|
From: Maciej Sobczak on 14 Apr 2010 18:09 On 15 Kwi, 08:54, Pete Becker <p...(a)versatilecoding.com> wrote: > > Why should I (or anybody else), as a library writer, care about > > enforcing the verbosity of notation in the client code? > > Because I can. And besides, it's good for them. I know better than they > do what their code should look like. Unfortunately the coding standard in my company prefers terseness over verbosity in our own code (we don't care about the internal implementation of third-party libraries, but we like to influence our own coders). That means that your library, which enforces verbosity in client (ours) code, will not be accepted in my company and some competing product will be selected instead that allows us to fulfill our own coding standards. This is what happens when the library author knows better how his clients should write their code. This is also a question on what are the limits for the library author to promote idioms, patterns and conventions. I think that forcing clients to use fully elaborated names for library entities is beyond those limits. (and it even makes it more difficult to write library tutorials :-) ) I agree that precise definition of such limits is subjective. -- Maciej Sobczak * http://www.inspirel.com YAMI4 - Messaging Solution for Distributed Systems http://www.inspirel.com/yami4 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Tony Delroy on 14 Apr 2010 18:08 On Apr 15, 8:40 am, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > On 14 Kwi, 20:45, Tony D <anthony...(a)gmail.com> wrote: > > > Rather, as a library writer, you can force your app-writing > > clients to use the verbose notation. A ban written in some coding > > standards is much less practical than utilising the compiler. > > This brings some interesting point. > > Why should I (or anybody else), as a library writer, care about > enforcing the verbosity of notation in the client code? You've twisted my words a bit there... I spoke of a verbose notation, not the verbosity of notation. Verbosity itself is not the aim, explicit scoping is. Pete's hit the nail of the head. Most big companies have some hot shot library developers, a few hot shot application developers who support the most important clients, and a mass of plodders in between and out the side. These kind of policies are about protecting the plodders from themselves. The predictable verbosity mentioned here also facilitates programmatic analysis and checks of the corporate code base - you can search for X::Y::Z and have a pretty good chance of finding all references... try that with namespaces... :-/. (Again for the record, I disagree with using class/ struct for scoping... just explaining the "other-side" arguments here as they're the ones less understood.) > I understand for example banning the copy operations where they could > break the library internal state. Or banning the unrestricted > instantiation of some class where many instances could similarly > corrupt the library. Etc. - whenever there is a benefit for the > library integrity, it makes sense to ban the client from doing > something. > > But enforcing the verbosity of notation in the client code? > What would be the benefit for the library? What would that protect? > > The only reason to do so is when the library and the client code are > both managed by the same entity (a company) with common development > policy, so that you can enforce the client-side policy already at the > library level. But that brings you back to coding standards anyway. ....that's a fair summary of the discussion from earlier posts. Again, coding standards aren't as effective. > BTW - no matter how elaborate are you class names in the library, the > client will freely use the preprocessor to make them shorter and nicer > and look like Python and whatnot. > Now try to prevent *that*. :-) Yes, few things are perfect, and lots of things can happen. People hack around "private" and "protected" too. But you'd need to have quite deeply nested classes and verbose class names before anyone would even be tempted.... Cheers, Tony -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Ulrich Eckhardt on 14 Apr 2010 18:05 Tony D wrote: > On Apr 14, 8:18 pm, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: >> On 14 Kwi, 09:50, Tony Delroy <tony_in_da...(a)yahoo.co.uk> wrote: >> > Some people - like John Lakos, author of Large Scale C++ Design or >> > whatever it's called - have written and used corporate coding >> > standards that demand classes/structs be used in place of namespaces >> > precisely because it forces the above usage >> >> Note that you can also force the above usage by banning the "use >> namespace" construct. [...] > That's like saying the private keyword can be replaced by banning > people from accessing any variables whose names have a "private_" > prefix! Rather, as a library writer, you can force your app-writing > clients to use the verbose notation. Well, almost... // these are mostly equivalent using namespace foo; class X: foo { ... }; // these two also using foo::someclass; typedef foo::someclass someclass; > A ban written in some coding standards is much less > practical than utilising the compiler. Smart people don't have coding standards therefore, but coding guidelines, and they make a conscious and informed decision about how to write their code, which they validate in a peer review process. Uli -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Mark Zaytsev on 15 Apr 2010 07:33 On Apr 14, 7:40 pm, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > On 14 Kwi, 20:45, Tony D <anthony...(a)gmail.com> wrote: > > > Rather, as a library writer, you can force your app-writing > > clients to use the verbose notation. A ban written in some coding > > standards is much less practical than utilising the compiler. > > This brings some interesting point. > > Why should I (or anybody else), as a library writer, care about > enforcing the verbosity of notation in the client code? Because, it is "the only way" to found where the code come from. If 5000 programmers busy making changes all over the place. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Keith H Duggar on 15 Apr 2010 07:33
On Apr 15, 5:09 am, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > On 15 Kwi, 08:54, Pete Becker <p...(a)versatilecoding.com> wrote: > > > > Why should I (or anybody else), as a library writer, care about > > > enforcing the verbosity of notation in the client code? > > > Because I can. And besides, it's good for them. I know better than they > > do what their code should look like. > > Unfortunately the coding standard in my company prefers terseness over > verbosity in our own code (we don't care about the internal > implementation of third-party libraries, but we like to influence our > own coders). and Tony Delroy wrote: > Pete's hit the nail of the head. I thought Pete's comment was a clever joke on the hubris of egos. But now that both Maciej and Tony took his comment literally I'm left hanging in sad wonderment. Hopefully Pete will confirm one way or another. Personally I try to lead herds to water without cattle prodding them into the deep end. If I recall correctly Scott Meyers said at a conference something to the effect of "As designers we should focus on making the right things easier to do." (That is not a direct quote, unfortunately I don't recall the exact words but I think the gist is correct.) I think that makes sense. Make what you think is the "One True Way" easy to do rather than make what you /think/ is "bad" hard/impossible to do. KHD -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |