Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: "Program to an interface" - When to break a design pattern Date: Fri, 06 May 2011 23:37:36 +0200 Organization: A noiseless patient Spider Lines: 76 Message-ID: References: <9dt5s6dalhetgfe99qs92c02hf0dbas44e@4ax.com> <2psjssq4zj.fsf@shell.xmission.com> <2poc3gq3p2.fsf@shell.xmission.com> <2pk4e4q2sq.fsf@shell.xmission.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Fri, 6 May 2011 21:37:37 +0000 (UTC) Injection-Info: mx01.eternal-september.org; posting-host="Zjm1/7nnVMUmB9baN8E6xQ"; logging-data="12930"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+At9i3eqT5D7n4EDLHZ4PR" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 In-Reply-To: Cancel-Lock: sha1:2ZndOPJMNazKvMnXgVDRwb+y5eE= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:3718 On 06/05/2011 22:50, Arved Sandstrom allegedly wrote: > On 11-05-06 01:56 PM, Daniele Futtorovic wrote: >> On 06/05/2011 12:24, Arved Sandstrom allegedly wrote: > [ SNIP ] > >>> It's not about providing a Map with the same iteration order as >>> "another". There might be no "other". In the case of a stock >>> LinkedHashMap we know that the predictable iteration order is insertion >>> order. But mainly the contract we're after is predictable iteration >>> order, regardless of how the map was loaded. That is what the Javadoc >>> says. >> >> True, there might be no other: the Map may have been constructed and >> filled in the method itself. >> >> But I maintain that the iteration order of a LinkedHashMap is *not >> predictable*, *unless* you know the order in which elements were >> inserted in it (or can make reasonable assumptions as to that). >> >>> As far as your nuance is concerned, I'm interested (the _OP_ is >>> interested) in providing a map with predictable insertion order. Map >>> does not satisfy that; LinkedHashMap does. If I return Map then I am >>> making a mistake. >>> >>>> The return type being a LinkedHashMap, itself, doesn't tell you >>>> _anything_ about its iteration order. >>> >>> ??? It tells me that it has a predictable iteration order (which happens >>> to be insertion order). It's the _predictable_ bit that is important. >>> That it happens to be insertion order is a bonus but not the key point. >> >> I repeat: the iteration order is *not predictable* if you don't happen >> to know the insertion order (unlike e.g. a SortedMap). > [ SNIP ] > > I'm not ignoring the rest of the post here, by any means, Daniele. I do > respect you as a knowledgeable debater actually. Although if you make a > forceful case expect a forceful counter-case if I think you're wrong. :-) > > I believe that we are somewhat at cross-purposes here. I think you're > reading more into the use of the word "predictable" than is deserved. > All I read into this is that, assuming that I have a default > LinkedHashMap that tracks insertion order (there is a constructor that > lets you specify access order with a boolean flag), that (1) *if* I know > the insertion order then I know ahead of time what an iterator on that > map will do, and (2) as corollary, if I've otherwise captured that > knowledge with one iteration, and then subsequently track insertions, I > can also predict what future iterations will do. Well, I absolutely agree with that, but how is it at odds with what I said? Remember, the question was whether the one method #getSortedMap(), if it retuned a LinkedHashMap, should declare its return-type as LinkedHashMap or as the general Map. And I argued it should be Map. Because it being a LinkedHashMap does not add any significant functional knowledge. The method, as you rightly observed some posts ago, does not take an argument, so it is reasonable to assume that the caller has no prior knowledge of the returned data's ordering. Therefore, since it being a LinkedHashMap does not add any predictability unless you know the order, and since that's the only functional peculiarity of a LinkedHashap, I concluded that knowing it's a LinkedHashMap is irrelevant. And since one ought to use types as broad as possible and as narrow as necessary, I opined that the return-type ought to be Map. As I said, I believe the only exception to this is if the caller itself is the one inserting in that Map from somewhere else and needs to retain the prior order. So if the callee were a factory method, yeah, okay. But I don't see any other use case for LinkedHashMap either as a return-type or a argument type. -- DF. An escaped convict once said to me: "Alcatraz is the place to be"