I'd like to keep the 2 clients feel similar, so if you leave that package there, the Java package also seems useless but tolerable. Note from a "product quality" point of view this forces us to write a unit test for any public class the bundle declared, that's what I was questioning, if we're fine (an Open Source project may not ask for things like test coverage, but it is nevertheless good practice to do so) doing so, we can keep the oteherwise useless class in a separate package. It is only a detail, but another reason why you should be cautious exposing such non-functional implementation details is, that as soon as a public release is out (even "1.0.0-SNAPSHOT", "RC1" or whatever we should really call it right now) this is exposed and people can use it, so removing it later is impossible at least not without breaking compatibility with existing releases.
When you are involved in a project you want other people than yourself to use, then you must ask these questions. There are enough examples, see JDK 8, etc. where things that don't always make sense went into a public release. So we won't die if we leave it therere, but we have to write tests and ensure to keep it there if developers start using it since it is public and visible[?] Thanks, Werner On Fri, Jul 11, 2014 at 1:10 PM, eberhard speer jr. <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Werner, > > I'm sorry, I must be as dense a Reza when it comes to the OO-canon. > Be that as it may [totally uncalled for], it seems to me most > developers understand that these rules are 'best practices' not set in > stone and that in some cases 'the pattern' is even a bad thing. > I am not going to argue whether or not that is the case here. While > you other points shine thru with almost painful clarity, I'm not sure > I get your point about the API. > I would point out it is a bit late in the day to start bringing that > up seeing as us 'noobs' have been at this API for quite some time now. > > I have seen the 'insides' of *all* the DDRs you mention and some you > don't and I can tell you DeviceMap is in a different ball-park > altogether ! > > One night -- you know those nights -- I, total Java ignoramus, came up > with a "cunning plan" : I dropped the DeviceMap code in the latest > Apache web-server release...see where this is going ? > Don't ask me how, I was just 'noodling' around, but it compiled, ran, > worked. > Now *that* I'd call a Big Deal ! > That and more, is DeviceMap ! > And I'm sure if you go through the Apache web server code, you'll also > find loads of stuff the lads in Java-Vatican would sputter about as > 'unholy'. > > Step back, forget 'orthodoxy' and what that 'Other' and the rest are > doing/have done. 'See' what the code achieves, in Kligon for all I > care. Then try and compare if you must. > > This is not useful. > > esjr > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTv8YvAAoJEOxywXcFLKYci18H/AhKlpTU95AiSw0yhMJ6AK0M > GCBpfhCABFXX5AUu2UAEhif5MDN8qI6pVA8X5Rh+t3Jpb9NDjjBO4NOt20R4G0Z0 > 1gGGEDvN9x8M//HivRTcUyxPZelFOaqhSF+Z2dZrbMxz8Kbmr/QBV5DdZBS6OZTK > 43HJjllrCDmC45InN2Ftv5nfAqjjEllwPqVwGABAvuseFDbtA99kZZZL15Tr7GLY > xmQqYXsK6tvqb9D3fxds5ET94BF7dHqdDZEC847uczJvBvGUQo6WPQuT+XrS+t6+ > 6SMAGdUCdAwrHSHKAjfvkis53YJwpk5K7QOUX5qGWYQG6NIbIVF2jMlhj3sxUqc= > =jr1L > -----END PGP SIGNATURE----- >
