On 6/15/10 3:56 PM, lim goh wrote: > +1 to good discussion here. Good read for me. > > I think I agree with how developers should really know what they are > doing. I bet we all have experienced times where we wish people using > our functions use them properly. > > However, I think Ben still has a point in being DEFENSIVE. I agree > with Ben that finger-pointing wouldn't help Alice, Bob, nor Carol but > defensive programming of some sort by Alice might. > We can always blame Carol for not reading the API docs close enough as > she should, But that wouldn't actually be being defensive. If the one that wrote the interface in the first place used the Map interface as a return value, then he/she _is_ being defensive as he/she is sticking a return value to an interface and hence can change his mind about the implementation details without ever affecting the client code as long as it sticks to the most basic premise of sticking to the contract and not to the implementation details (which is known as programming by coincidence). The one providing the interface implementation is being defensive if he respects encapsulation and returns a Map that does not expose the internal state of the object (e.g. by returning a copy of the internal state), and oughta be kind in defining the contract of the class explicitly, and using the Map interface as a return value tells everything, there's no need to state anything in the javadocs about iteration order, it's returning a Map. Period. The consumer is free to be defensive (like in checking for nilness _and_ implementing the desired ordering), but IN ANY case he's obligated to stick to the contract of its collaborators.
So, being certain that most probably I introduced some of this problems myself by having worked on the app-schema code years ago, I still strongly argument against anyone that expects a given iteration order out of a method returning a Map, and not to enforce a method to return a LinkedHasMap at least absolutely necessary. My 2c. Gabriel >but this is like blaming any one that ran the red light > and caused a traffic accident that could still be avoided if the party > that has the right-of-way chose to slowdown when crossing the > intersection. > > Maybe people here just don't agree with the METHOD proposed by Ben > about changing to LinkedHashMap though I don't know how to better > defend Alice's API. > I learnt in my Win32/C++ experience that very defensive people creates > debug-only mines that blow up in the face of the developer not > following designs (in this case Carol). > Although random and maybe irrelevant, I think the following example > illustrates how can Alice be defensive when she wants to emphasize > that the returned HashMap is NOT "iteration-order-defined". Carol will > get a huge fail from compiler/debugger/anything before the code goes > public if she assumed iteration-order for the HashMap Alice provided. > I would suggest something as useful/clever along this line except > unfortunately I'm not experienced enough to link this example to a > Java Library development environment... > > A little (irrelevant) example here: > if someone calls a function that returns a bool to indicate succesfulness > bool bSuccessful = foo(); > if ( bSuccessful ) > bSuccessful = bar(); > > by replacing bool with some debug-only bool wrapper, the debugger will > breaks everytime someone does the following: > bool bSuccessful = foo(); > bSuccessful = bar() // BREAKS: bSuccessful reassigned before being checked!! > > > 2010/6/15 Justin Deoliveira<jdeol...@opengeo.org>: >> I have to add my +1 as well. We have run up against this before when we >> started supporting java 6 and the moral of the story was that it is up >> to the downstream developer to ensure that if they are iterating through >> a map in a case where order matters then the onus is on them to ensure >> they are using an ordered map. >> >> That and the shear effort to switch from using HashMap to another map >> implementation makes it quite a job. I know I use HashMap everywhere. >> >> Good debate though :) >> >> -Justin >> >> On 10-06-15 11:00 AM, Ian Turton wrote: >>> On Tue, Jun 15, 2010 at 10:35 AM, Mª®k<mc.pr...@gmail.com> wrote: >>>> +1 for Andrea and Christian. >>>> >>> >>> +1 from me too - When I learnt about maps and lists I was taught they >>> do different things and to be clear about which I needed. >>> >>> Ian >> >> >> -- >> Justin Deoliveira >> OpenGeo - http://opengeo.org >> Enterprise support for open source geospatial. >> >> ------------------------------------------------------------------------------ >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel >> > > > -- Gabriel Roldan OpenGeo - http://opengeo.org Expert service straight from the developers. ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
