Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #3578 > unrolled thread

"Program to an interface" - When to break a design pattern

Back to article view | Back to comp.lang.java.programmer

Contents

  "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 12:21 -0700
    Re: "Program to an interface" - When to break a design pattern Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-05-05 15:43 -0400
      Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 17:19 -0400
    Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-05 21:47 +0200
    Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 14:14 -0600
      Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 13:26 -0700
      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-05 22:27 +0200
        Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 14:42 -0600
          Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-05 22:48 +0200
            Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 15:02 -0600
              Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 00:02 +0200
                Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 19:49 -0300
                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 02:28 +0200
                    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 07:24 -0300
                      Re: "Program to an interface" - When to break a design pattern Patricia Shanahan <pats@acm.org> - 2011-05-06 07:03 -0700
                        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 17:30 -0300
                      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 18:56 +0200
                        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 17:50 -0300
                          Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 23:37 +0200
                            Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 19:43 -0300
                Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 17:17 -0600
                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 02:28 +0200
            Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 23:25 -0700
              Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-06 18:25 +0200
                Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-07 16:26 -0700
                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-08 03:28 +0200
                    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-08 00:05 -0300
                      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-08 16:15 +0200
                        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-08 14:20 -0300
                          Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-08 19:48 +0200
                            Re: "Program to an interface" - When to break a design pattern markspace <-@.> - 2011-05-10 07:36 -0700
                              Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-10 13:04 -0600
                                Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-10 21:31 +0200
                              Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-10 20:01 -0300
                                Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 19:14 +0200
                                Re: "Program to an interface" - When to break a design pattern Patricia Shanahan <pats@acm.org> - 2011-05-11 10:41 -0700
                                  Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 19:55 +0200
                                    Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-11 16:42 -0400
                                      Re: "Program to an interface" - When to break a design pattern Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-05-11 23:34 +0200
                                        Re: "Program to an interface" - When to break a design pattern "John B. Matthews" <nospam@nospam.invalid> - 2011-05-12 00:51 -0400
                                          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-12 00:58 -0400
                                            Re: "Program to an interface" - When to break a design pattern Tom Anderson <twic@urchin.earth.li> - 2011-05-12 20:08 +0100
                                    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-15 13:25 -0300
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 17:24 -0400
            Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 16:00 -0600
            Re: "Program to an interface" - When to break a design pattern Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2011-05-06 15:01 +0300
              Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-06 12:17 -0400
                Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-07 16:28 -0700
      Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 17:21 -0400
        Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 15:58 -0600
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 18:18 -0400
        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 19:20 -0300
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-05 18:23 -0400
            Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 20:17 -0300
    Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 18:26 -0300
    Re: "Program to an interface" - When to break a design pattern Steven Simpson <ss@domain.invalid> - 2011-05-05 22:57 +0100
      Re: "Program to an interface" - When to break a design pattern Tom Anderson <twic@urchin.earth.li> - 2011-05-05 23:29 +0100
        Re: "Program to an interface" - When to break a design pattern Steven Simpson <ss@domain.invalid> - 2011-05-06 13:30 +0100
          Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-06 12:19 -0400
      Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 16:41 -0600
        Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-05 20:47 -0300
    Re: "Program to an interface" - When to break a design pattern Roedy Green <see_website@mindprod.com.invalid> - 2011-05-05 16:41 -0700
      Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-05 22:47 -0600
      Re: "Program to an interface" - When to break a design pattern Zapanaz <http://joecosby.com/code/mail.pl@foo.com> - 2011-05-05 23:28 -0700
    Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-06 17:15 +0200
      Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-06 20:53 -0300
        Re: "Program to an interface" - When to break a design pattern Lew <noone@lewscanon.com> - 2011-05-06 21:39 -0400
          Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-07 00:56 -0300
        Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-08 12:24 +0200
          Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-08 13:42 -0300
            Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-09 11:04 +0200
              Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-09 19:33 -0300
                Re: "Program to an interface" - When to break a design pattern Michal Kleczek <kleku75@gmail.com> - 2011-05-10 15:51 +0200
                  Re: "Program to an interface" - When to break a design pattern Jim Janney <jjanney@shell.xmission.com> - 2011-05-10 13:15 -0600
                  Re: "Program to an interface" - When to break a design pattern Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2011-05-10 19:40 -0300

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#3621

Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> writes:

> On 05/05/2011 23:02, Jim Janney allegedly wrote:
>> Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>  writes:
>>
>>> On 05/05/2011 22:42, Jim Janney allegedly wrote:
>>>> Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>   writes:
>>>>
>>>>> On 05/05/2011 22:14, Jim Janney allegedly wrote:
>>>>>> The point of programming to the interface is to make it easier to
>>>>>> substitute a different implementation, which implies that any
>>>>>> reasonable implementation can be used.  If this is not true, if the
>>>>>> code that uses the object relies on behavior only found in one
>>>>>> implementation, then there is no benefit to using the interface, and
>>>>>> you make it more inviting for someone to break things later on.  So
>>>>>> in this case, no, programming to the interface would be the wrong
>>>>>> thing to do.  The point of design principles is to make you think
>>>>>> before you break them :-)
>>>>>
>>>>> Entirely disagreed. The code shown did not contain any justification for
>>>>> breaking the pattern in question, and on the opposite, it contained all
>>>>> the reasons to think more about encapsulation, which is the true
>>>>> underlying rationale for coding to interfaces -- not polymorphism per se.
>>>>
>>>> The justification is not in the code shown, but in the accompanying
>>>> remark "I need the map to retain the insertion order."  There's no
>>>> interface in the JRE that promises this, and only one class that
>>>> provides it, which makes encapsulation, shall we say, difficult.
>>>
>>> That's not the point! Yes, you need a LinkedHashMap to retain
>>> insertion order in a Map. But retaining insertion order is
>>> relevant... only when inserting.
>>
>> Think a minute.  When does retaining insertion order actually matter?
>> When you build the map, or some time later when you iterate over it?
>> Hint: if you never iterate over it, the order doesn't matter at all.
>
> I don't need a full minute to see that this is even further beside the
> point.

In the absence of more code, we have to take the original poster's
word that callers to getSortedMap() actually depend on the insertion
order.  But there's no reason to suppose they don't: the effects are in
no way limited to map creation.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#3630

On 06/05/2011 01:17, Jim Janney allegedly wrote:
> Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>  writes:
>
>> On 05/05/2011 23:02, Jim Janney allegedly wrote:
>>> Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>   writes:
>>>
>>>> On 05/05/2011 22:42, Jim Janney allegedly wrote:
>>>>> Daniele Futtorovic<da.futt.news@laposte-dot-net.invalid>    writes:
>>>>>
>>>>>> On 05/05/2011 22:14, Jim Janney allegedly wrote:
>>>>>>> The point of programming to the interface is to make it easier to
>>>>>>> substitute a different implementation, which implies that any
>>>>>>> reasonable implementation can be used.  If this is not true, if the
>>>>>>> code that uses the object relies on behavior only found in one
>>>>>>> implementation, then there is no benefit to using the interface, and
>>>>>>> you make it more inviting for someone to break things later on.  So
>>>>>>> in this case, no, programming to the interface would be the wrong
>>>>>>> thing to do.  The point of design principles is to make you think
>>>>>>> before you break them :-)
>>>>>>
>>>>>> Entirely disagreed. The code shown did not contain any justification for
>>>>>> breaking the pattern in question, and on the opposite, it contained all
>>>>>> the reasons to think more about encapsulation, which is the true
>>>>>> underlying rationale for coding to interfaces -- not polymorphism per se.
>>>>>
>>>>> The justification is not in the code shown, but in the accompanying
>>>>> remark "I need the map to retain the insertion order."  There's no
>>>>> interface in the JRE that promises this, and only one class that
>>>>> provides it, which makes encapsulation, shall we say, difficult.
>>>>
>>>> That's not the point! Yes, you need a LinkedHashMap to retain
>>>> insertion order in a Map. But retaining insertion order is
>>>> relevant... only when inserting.
>>>
>>> Think a minute.  When does retaining insertion order actually matter?
>>> When you build the map, or some time later when you iterate over it?
>>> Hint: if you never iterate over it, the order doesn't matter at all.
>>
>> I don't need a full minute to see that this is even further beside the
>> point.
>
> In the absence of more code, we have to take the original poster's
> word that callers to getSortedMap() actually depend on the insertion
> order.  But there's no reason to suppose they don't: the effects are in
> no way limited to map creation.
>

Actually, he doesn't exactly say that /callers/ depend on insertion 
order. He said:
> where I'm creating sortedMap above, I need the map to
> retain the insertion order

I interpret "where I'm creating the map" as being in the getSortedMap() 
method. Perhaps he really meant the code that calls getSortedMap(), in 
which case this method would be a factory method. But I assumed it 
wasn't, because of the getter-like name, and also because of what he 
said further below.
If it were a factory method -- then yes, by all means. If it's a factory 
method that creates a map retaining insertion order, then its return 
type should be LinkedHashMap.
But that's actually the only exception I can think of. I cannot fathom 
any other, normal OO case where LinkedHashMap would make sense as the 
type of a parameter to, or the return type of any method.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3639

On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
<da.futt.news@laposte-dot-net.invalid> wrote:

>But the code that *calls* 
>getSortedMap() doesn't have to care about whether or not it's a 
>LinkedHashMap

yes, it does.

The code that calls getSortedMap() has to know whether the results
will be sorted or not.
-- 
Zapanaz
International Satanic Conspiracy
Customer Support Specialist
http://joecosby.com/ 
Isn't round the funny side that never ends?

:: Currently listening to For His Namesake, by Amboy Dukes/Ted Nugent, from "Journey to the Center of the Mind"

[toc] | [prev] | [next] | [standalone]

#3698

On 06/05/2011 08:25, Zapanaz allegedly wrote:
> On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
> <da.futt.news@laposte-dot-net.invalid>  wrote:
>
>> But the code that *calls*
>> getSortedMap() doesn't have to care about whether or not it's a
>> LinkedHashMap
>
> yes, it does.
>
> The code that calls getSortedMap() has to know whether the results
> will be sorted or not.

Not unless the calling code inserts in that Map *and iterates* over it, 
it doesn't.

A LinkedHashMap is not sorted. At least not in the absolute sense. It is 
sorted relatively to another sorting, viz. it (possibly) replicates the 
iteration order of another Map. But as I have tried to explain before, 
knowing that it's a LinkedHashMap *without knowing in what order the 
insertion took place* doesn't tell you *anything* about the iteration order.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3771

On Fri, 06 May 2011 18:25:31 +0200, Daniele Futtorovic
<da.futt.news@laposte-dot-net.invalid> wrote:

>On 06/05/2011 08:25, Zapanaz allegedly wrote:
>> On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
>> <da.futt.news@laposte-dot-net.invalid>  wrote:
>>
>>> But the code that *calls*
>>> getSortedMap() doesn't have to care about whether or not it's a
>>> LinkedHashMap
>>
>> yes, it does.
>>
>> The code that calls getSortedMap() has to know whether the results
>> will be sorted or not.
>
>Not unless the calling code inserts in that Map *and iterates* over it, 
>it doesn't.
>
>A LinkedHashMap is not sorted. At least not in the absolute sense. It is 
>sorted relatively to another sorting, viz. it (possibly) replicates the 
>iteration order of another Map. But as I have tried to explain before, 
>knowing that it's a LinkedHashMap *without knowing in what order the 
>insertion took place* doesn't tell you *anything* about the iteration order.

I am using the word "sorted" in an incorrect way, it's true.

This is from a real-world application, the results in the map are
presented in a UI, and they do in fact have to be in a particular
order in that UI. They are ordered by an algorithm based on a set of
user-entered choices, and inserted in that order. So if that order
isn't preserved in the map, the way the items appear in the UI would
not be what the user had selected.


-- 
Zapanaz
International Satanic Conspiracy
Customer Support Specialist
http://joecosby.com/ 
You know you're in Saskatchewan when you can sit on your front porch 
and watch your dog run away for three days

:: Currently listening to Todesfuge, 2003, by Diamanda Galás, from "Defixiones, Will and Testament"

[toc] | [prev] | [next] | [standalone]

#3773

On 08/05/2011 01:26, Zapanaz allegedly wrote:
> On Fri, 06 May 2011 18:25:31 +0200, Daniele Futtorovic
> <da.futt.news@laposte-dot-net.invalid>  wrote:
>
>> On 06/05/2011 08:25, Zapanaz allegedly wrote:
>>> On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
>>> <da.futt.news@laposte-dot-net.invalid>   wrote:
>>>
>>>> But the code that *calls*
>>>> getSortedMap() doesn't have to care about whether or not it's a
>>>> LinkedHashMap
>>>
>>> yes, it does.
>>>
>>> The code that calls getSortedMap() has to know whether the results
>>> will be sorted or not.
>>
>> Not unless the calling code inserts in that Map *and iterates* over it,
>> it doesn't.
>>
>> A LinkedHashMap is not sorted. At least not in the absolute sense. It is
>> sorted relatively to another sorting, viz. it (possibly) replicates the
>> iteration order of another Map. But as I have tried to explain before,
>> knowing that it's a LinkedHashMap *without knowing in what order the
>> insertion took place* doesn't tell you *anything* about the iteration order.
>
> I am using the word "sorted" in an incorrect way, it's true.
>
> This is from a real-world application, the results in the map are
> presented in a UI, and they do in fact have to be in a particular
> order in that UI. They are ordered by an algorithm based on a set of
> user-entered choices, and inserted in that order. So if that order
> isn't preserved in the map, the way the items appear in the UI would
> not be what the user had selected.

This whole discussion is about the declared type, not the runtime type.

Anyway, I've had enough of this.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3778

On 11-05-07 10:28 PM, Daniele Futtorovic wrote:
> On 08/05/2011 01:26, Zapanaz allegedly wrote:
>> On Fri, 06 May 2011 18:25:31 +0200, Daniele Futtorovic
>> <da.futt.news@laposte-dot-net.invalid>  wrote:
>>
>>> On 06/05/2011 08:25, Zapanaz allegedly wrote:
>>>> On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
>>>> <da.futt.news@laposte-dot-net.invalid>   wrote:
>>>>
>>>>> But the code that *calls*
>>>>> getSortedMap() doesn't have to care about whether or not it's a
>>>>> LinkedHashMap
>>>>
>>>> yes, it does.
>>>>
>>>> The code that calls getSortedMap() has to know whether the results
>>>> will be sorted or not.
>>>
>>> Not unless the calling code inserts in that Map *and iterates* over it,
>>> it doesn't.
>>>
>>> A LinkedHashMap is not sorted. At least not in the absolute sense. It is
>>> sorted relatively to another sorting, viz. it (possibly) replicates the
>>> iteration order of another Map. But as I have tried to explain before,
>>> knowing that it's a LinkedHashMap *without knowing in what order the
>>> insertion took place* doesn't tell you *anything* about the iteration
>>> order.
>>
>> I am using the word "sorted" in an incorrect way, it's true.
>>
>> This is from a real-world application, the results in the map are
>> presented in a UI, and they do in fact have to be in a particular
>> order in that UI. They are ordered by an algorithm based on a set of
>> user-entered choices, and inserted in that order. So if that order
>> isn't preserved in the map, the way the items appear in the UI would
>> not be what the user had selected.
> 
> This whole discussion is about the declared type, not the runtime type.

Sort of helps if the declared type has some reasonable relationship to
the possible runtime types, actually. If the contract of the declared
type deviates too much from the contract of the possible runtime types,
which is the case here, what's the point?

> Anyway, I've had enough of this.
> 
Probably just as well. You can't convince everyone to do something
ill-advised.

AHS

[toc] | [prev] | [next] | [standalone]

#3813

On 08/05/2011 05:05, Arved Sandstrom allegedly wrote:
> On 11-05-07 10:28 PM, Daniele Futtorovic wrote:
>> On 08/05/2011 01:26, Zapanaz allegedly wrote:
>>> On Fri, 06 May 2011 18:25:31 +0200, Daniele Futtorovic
>>> <da.futt.news@laposte-dot-net.invalid>   wrote:
>>>
>>>> On 06/05/2011 08:25, Zapanaz allegedly wrote:
>>>>> On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
>>>>> <da.futt.news@laposte-dot-net.invalid>    wrote:
>>>>>
>>>>>> But the code that *calls*
>>>>>> getSortedMap() doesn't have to care about whether or not it's a
>>>>>> LinkedHashMap
>>>>>
>>>>> yes, it does.
>>>>>
>>>>> The code that calls getSortedMap() has to know whether the results
>>>>> will be sorted or not.
>>>>
>>>> Not unless the calling code inserts in that Map *and iterates* over it,
>>>> it doesn't.
>>>>
>>>> A LinkedHashMap is not sorted. At least not in the absolute sense. It is
>>>> sorted relatively to another sorting, viz. it (possibly) replicates the
>>>> iteration order of another Map. But as I have tried to explain before,
>>>> knowing that it's a LinkedHashMap *without knowing in what order the
>>>> insertion took place* doesn't tell you *anything* about the iteration
>>>> order.
>>>
>>> I am using the word "sorted" in an incorrect way, it's true.
>>>
>>> This is from a real-world application, the results in the map are
>>> presented in a UI, and they do in fact have to be in a particular
>>> order in that UI. They are ordered by an algorithm based on a set of
>>> user-entered choices, and inserted in that order. So if that order
>>> isn't preserved in the map, the way the items appear in the UI would
>>> not be what the user had selected.
>>
>> This whole discussion is about the declared type, not the runtime type.
>
> Sort of helps if the declared type has some reasonable relationship to
> the possible runtime types, actually. If the contract of the declared
> type deviates too much from the contract of the possible runtime types,
> which is the case here, what's the point?
>
>> Anyway, I've had enough of this.
>>
> Probably just as well. You can't convince everyone to do something
> ill-advised.

Them's fighting words.

Show me a code example with a method, that is not a factory method; that 
returns a LinkedHashMap instance; for which it matters to the caller 
that the return type be declared as LinkedHashMap, rather than Map.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3819

On 11-05-08 11:15 AM, Daniele Futtorovic wrote:
> On 08/05/2011 05:05, Arved Sandstrom allegedly wrote:
>> On 11-05-07 10:28 PM, Daniele Futtorovic wrote:
>>> On 08/05/2011 01:26, Zapanaz allegedly wrote:
>>>> On Fri, 06 May 2011 18:25:31 +0200, Daniele Futtorovic
>>>> <da.futt.news@laposte-dot-net.invalid>   wrote:
>>>>
>>>>> On 06/05/2011 08:25, Zapanaz allegedly wrote:
>>>>>> On Thu, 05 May 2011 22:48:21 +0200, Daniele Futtorovic
>>>>>> <da.futt.news@laposte-dot-net.invalid>    wrote:
>>>>>>
>>>>>>> But the code that *calls*
>>>>>>> getSortedMap() doesn't have to care about whether or not it's a
>>>>>>> LinkedHashMap
>>>>>>
>>>>>> yes, it does.
>>>>>>
>>>>>> The code that calls getSortedMap() has to know whether the results
>>>>>> will be sorted or not.
>>>>>
>>>>> Not unless the calling code inserts in that Map *and iterates* over
>>>>> it,
>>>>> it doesn't.
>>>>>
>>>>> A LinkedHashMap is not sorted. At least not in the absolute sense.
>>>>> It is
>>>>> sorted relatively to another sorting, viz. it (possibly) replicates
>>>>> the
>>>>> iteration order of another Map. But as I have tried to explain before,
>>>>> knowing that it's a LinkedHashMap *without knowing in what order the
>>>>> insertion took place* doesn't tell you *anything* about the iteration
>>>>> order.
>>>>
>>>> I am using the word "sorted" in an incorrect way, it's true.
>>>>
>>>> This is from a real-world application, the results in the map are
>>>> presented in a UI, and they do in fact have to be in a particular
>>>> order in that UI. They are ordered by an algorithm based on a set of
>>>> user-entered choices, and inserted in that order. So if that order
>>>> isn't preserved in the map, the way the items appear in the UI would
>>>> not be what the user had selected.
>>>
>>> This whole discussion is about the declared type, not the runtime type.
>>
>> Sort of helps if the declared type has some reasonable relationship to
>> the possible runtime types, actually. If the contract of the declared
>> type deviates too much from the contract of the possible runtime types,
>> which is the case here, what's the point?
>>
>>> Anyway, I've had enough of this.
>>>
>> Probably just as well. You can't convince everyone to do something
>> ill-advised.
> 
> Them's fighting words.

No, merely argumentative words. Like I said, Daniele, I respect your
opinion - you produce good posts and I read them carefully - but I am
not impressed by dismissive statements like "Anyway, I've had enough of
this". That translates to "whatever, I can't make these idiots see the
light, I'm washing my hands of them" in vernacular English. If you
happened to say that in a professional environment, say a developers'
meeting, you'd have a lot of pissed-off people.

It's actually a lot better to say something like "I believe I'm correct,
but I'm clearly not making my case; I'll leave the discussion at this
point". Lot more diplomatic.

> Show me a code example with a method, that is not a factory method; that
> returns a LinkedHashMap instance; for which it matters to the caller
> that the return type be declared as LinkedHashMap, rather than Map.
> 
I don't know why you're excluding factory methods. In fact a factory
method would be amongst the most likely to declare the return as Map and
not as LinkedHashMap, so I wouldn't be likely to use one as an example
anyway.

I don't think I need to invent a new example: the OP has already
provided one. Let's say he's got client class A (maybe a JSF backing
bean) that absolutely requires that the DataModel be loaded by a map
obeying this contract. I'll go further and say that if your requirements
are so tenuous and erratic that this specific requirement is going to
change a fair bit, that you've got bigger problems than how you declare
your collections types. From the sounds of what the OP said this is a
definite, solid, stable and essential requirement.

Provider class B with the method in question is tasked to supply the map
that obeys this "predictable iteration order" contract...namely a
LinkedHashMap.

You can absolutely declare that return value from the B.getMap() method
as a Map. You'll need to comprehensively Javadoc that method as a
result, even if it's not a public/published API method, because now Map
tells you very little. You'll also do well to comment the location of
the call so as to increase the likelihood that future maintenance in
class A doesn't ignore the special required nature of _that_ Map.

Or you could in this situation just return LinkedHashMap. By doing so
you now locked that relationship in...which given the fact that Java
possesses no interface-level capability of enforcing this behavioural
contract, gives you language-level assurance of using the right map.

I'd very possibly think differently about this if I had an inkling that
this method was to be made publicly available in a library to any third
party client. But that's not the impression I'm getting from the OP's
description.

AHS

[toc] | [prev] | [next] | [standalone]

#3822

On 08/05/2011 19:20, Arved Sandstrom allegedly wrote:
> On 11-05-08 11:15 AM, Daniele Futtorovic wrote:
>>>> Anyway, I've had enough of this.
>>>>
>>> Probably just as well. You can't convince everyone to do something
>>> ill-advised.
>>
>> Them's fighting words.
>
> No, merely argumentative words. Like I said, Daniele, I respect your
> opinion - you produce good posts and I read them carefully - but I am
> not impressed by dismissive statements like "Anyway, I've had enough of
> this". That translates to "whatever, I can't make these idiots see the
> light, I'm washing my hands of them" in vernacular English. If you
> happened to say that in a professional environment, say a developers'
> meeting, you'd have a lot of pissed-off people.
>
> It's actually a lot better to say something like "I believe I'm correct,
> but I'm clearly not making my case; I'll leave the discussion at this
> point". Lot more diplomatic.

I have spent quite some time arguing on this topic. I have repeatedly 
made one point that I believe to be central, which you at some point 
even acknowledged, but which nobody cared to take into account. Yes, 
that vernacular is exactly how I meant it.


>> Show me a code example with a method, that is not a factory method; that
>> returns a LinkedHashMap instance; for which it matters to the caller
>> that the return type be declared as LinkedHashMap, rather than Map.
>>
> I don't know why you're excluding factory methods. In fact a factory
> method would be amongst the most likely to declare the return as Map and
> not as LinkedHashMap, so I wouldn't be likely to use one as an example
> anyway.

"Factory method" in the sense of a method whose sole purpose is to 
construct the instance.
E.g.
   <U, V> LinkedHashMap<U, V> createNewMap(){
     // Decide on initial cap. and load factor here
     return new LinkedHashMap<U, V>( 42, 0.42 );
   }


> I don't think I need to invent a new example: the OP has already
> provided one.

I'm asking you to. The following is the only thing resembling code the 
OP provided:
> LinkedHashMap<String, Integer> sortedMap = this.getSortedMap();
>
> public LinkedHashMap<String, Integer> getSortedMap() {
>   //do stuff
> }

This hardly qualifies.


> Let's say he's got client class A (maybe a JSF backing
> bean) that absolutely requires that the DataModel be loaded by a map
> obeying this contract. I'll go further and say that if your requirements
> are so tenuous and erratic that this specific requirement is going to
> change a fair bit, that you've got bigger problems than how you declare
> your collections types. From the sounds of what the OP said this is a
> definite, solid, stable and essential requirement.
>
> Provider class B with the method in question is tasked to supply the map
> that obeys this "predictable iteration order" contract...namely a
> LinkedHashMap.
>
> You can absolutely declare that return value from the B.getMap() method
> as a Map. You'll need to comprehensively Javadoc that method as a
> result, even if it's not a public/published API method, because now Map
> tells you very little. You'll also do well to comment the location of
> the call so as to increase the likelihood that future maintenance in
> class A doesn't ignore the special required nature of _that_ Map.

"Now Map tells you very little". This is the central point. As I have 
argued all along, it tells you /no less/ than it being LinkedHashMap, 
because, as you have acknowledged, the mere fact that the return type is 
LinkedHashMap does not give you any conclusive insight into its 
iteration order (predictability thereof).

In other words, there's no contractual element to this, therefore it 
does not add to the contract. So you would have to document 
comprehensively anyway.

Consequently, applying the more general rule that types ought to be as 
broad as possible and as narrow as necessary, make the return type 
java.util.Map and document comprehensively.

-.-

This is perhaps the sixth time I've written the same thing with a 
different wording. If it still doesn't get through to anyone, then yes, 
I'll declare pearls before swine. Sorry for not being 'diplomatic' more 
than the first half a dozen tries.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3914

On 5/8/2011 10:48 AM, Daniele Futtorovic wrote:

> This is perhaps the sixth time I've written the same thing with a
> different wording. If it still doesn't get through to anyone, then yes,
> I'll declare pearls before swine. Sorry for not being 'diplomatic' more
> than the first half a dozen tries.


No, I think you're right, if I've been following the discussion properly 
(it's gone a bit long winded).

As an example, here's a method in the Java API that returns an array -- 
something with NO constraints on data order -- and yet the docs for the 
method say the order is guaranteed.

<http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getEnumConstants%28%29>

It's even a relatively recently added method too, not some historical 
oddity.  So I agree it's legit to document, but not enforce by type, 
ordering or other invariants on the objects a method returns.

[toc] | [prev] | [next] | [standalone]

#3930

markspace <-@.> writes:

> On 5/8/2011 10:48 AM, Daniele Futtorovic wrote:
>
>> This is perhaps the sixth time I've written the same thing with a
>> different wording. If it still doesn't get through to anyone, then yes,
>> I'll declare pearls before swine. Sorry for not being 'diplomatic' more
>> than the first half a dozen tries.
>
>
> No, I think you're right, if I've been following the discussion
> properly (it's gone a bit long winded).
>
> As an example, here's a method in the Java API that returns an array -- 
> something with NO constraints on data order -- and yet the docs for
> the method say the order is guaranteed.
>
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getEnumConstants%28%29>
>
> It's even a relatively recently added method too, not some historical
> oddity.  So I agree it's legit to document, but not enforce by type,
> ordering or other invariants on the objects a method returns.

Not an analogous case.  When an array is ordered, the ordering is a
property only of that particular instance, one that may cease to hold if
the array is modified.  In contrast, every instance of LinkedHashMap
always preserves the order of insertion, since this is a property that
the class promises to maintain at all times.

Ms. Futtorovic's argument holds only if callers to getOrderedMap() never
add new entries to it.  That's not an assumption I'm willing to make,
without more information than the original poster has given us.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#3935

On 10/05/2011 21:04, Jim Janney allegedly wrote:
> markspace<-@.>  writes:
>> As an example, here's a method in the Java API that returns an array --
>> something with NO constraints on data order -- and yet the docs for
>> the method say the order is guaranteed.
>>
>> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getEnumConstants%28%29>
>>
>> It's even a relatively recently added method too, not some historical
>> oddity.  So I agree it's legit to document, but not enforce by type,
>> ordering or other invariants on the objects a method returns.
>
> Not an analogous case.  When an array is ordered, the ordering is a
> property only of that particular instance, one that may cease to hold if
> the array is modified.  In contrast, every instance of LinkedHashMap
> always preserves the order of insertion, since this is a property that
> the class promises to maintain at all times.


> M*r*. Futtorovic's argument holds only if callers to getOrderedMap() never
> add new entries to it.

... while having an interest in its iteration order. But otherwise 
entirely correct and agreed.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3940

On 11-05-10 11:36 AM, markspace wrote:
> On 5/8/2011 10:48 AM, Daniele Futtorovic wrote:
> 
>> This is perhaps the sixth time I've written the same thing with a
>> different wording. If it still doesn't get through to anyone, then yes,
>> I'll declare pearls before swine. Sorry for not being 'diplomatic' more
>> than the first half a dozen tries.
> 
> No, I think you're right, if I've been following the discussion properly
> (it's gone a bit long winded).
> 
> As an example, here's a method in the Java API that returns an array --
> something with NO constraints on data order -- and yet the docs for the
> method say the order is guaranteed.
> 
> <http://download.oracle.com/javase/6/docs/api/java/lang/Class.html#getEnumConstants%28%29>
> 
> It's even a relatively recently added method too, not some historical
> oddity.  So I agree it's legit to document, but not enforce by type,
> ordering or other invariants on the objects a method returns.
> 
Well, the usefulness of the debate for me is that I have been forced to
more accurately describe the situation where I believe that use of
LinkedHashMap, vice the Map, is, if not preferable, at least not to be
vilified and rejected. To wit, we'd be dealing with non-published
implementation code where the designer/implementer requires strong
guarantees, in code, that no other Map will be used. I think a few
people are getting that I'm being _that_ specific, but still think that
documentation is a better approach. That's fine - I am personally wary,
through experience, of relying on other people to read comments and
Javadocs, but YMMV.

With all due respect to Daniele, I find it difficult to characterize him
as being right when he says (in a previous post):

""Now Map tells you very little". [ed. quote from me] This is the
central point. As I have argued all along, it tells you /no less/ than
it being LinkedHashMap, because, as you have acknowledged, the mere fact
that the return type is LinkedHashMap does not give you any conclusive
insight into its iteration order (predictability thereof)."

I'm sorry, he and I are seriously at odds over what predictability means
here (and quite frankly, what the LinkedHashMap Javadoc means by using
the term). And I sure as hell didn't acknowledge what he says I
"acknowledged" about LinkedHashMap and its predictability. As the OP
pointed out, his *user* - the person who entered the data and is now
viewing it, knows exactly what the insertion order was, and expects to
see it kept. LinkedHashMap provides that guarantee of predictability to
the *user* here, as the OP explained - Map does not.

I agree that _declaring_ the return type as LinkedHashMap does not
achieve that; the ironclad knowledge that it _is_ LinkedHashMap does,
even if it's declared as Map. But in some cases (see above) there is no
harm, and arguably some utility, in making the explicit declaration.
That's the point I've been trying to make. Evidently I'm running into
the "program to an interface at all costs" principle.

AHS

[toc] | [prev] | [next] | [standalone]

#3979

On 11/05/2011 01:01, Arved Sandstrom allegedly wrote:
> Well, the usefulness of the debate for me is that I have been forced to
> more accurately describe the situation where I believe that use of
> LinkedHashMap, vice the Map, is, if not preferable, at least not to be
> vilified and rejected. To wit, we'd be dealing with non-published
> implementation code where the designer/implementer requires strong
> guarantees, in code, that no other Map will be used. I think a few
> people are getting that I'm being _that_ specific, but still think that
> documentation is a better approach. That's fine - I am personally wary,
> through experience, of relying on other people to read comments and
> Javadocs, but YMMV.
>
> With all due respect to Daniele,

Cut the fluff, or you'll force me to add it, too. ;)

> I find it difficult to characterize him
> as being right when he says (in a previous post):
>
> ""Now Map tells you very little". [ed. quote from me] This is the
> central point. As I have argued all along, it tells you /no less/ than
> it being LinkedHashMap, because, as you have acknowledged, the mere fact
> that the return type is LinkedHashMap does not give you any conclusive
> insight into its iteration order (predictability thereof)."
>
> I'm sorry, he and I are seriously at odds over what predictability means
> here (and quite frankly, what the LinkedHashMap Javadoc means by using
> the term). And I sure as hell didn't acknowledge what he says I
> "acknowledged" about LinkedHashMap and its predictability.

I took e.g. this bit of one of your posts as such:
> Do I know what the iteration order will be if I don't know the order of
> insertions, and haven't iterated at least once? No, obviously not.

I don't think we are at odds as to the meaning of "predictability". I 
can't think of any other than: you can make assertions as to X, before 
doing X, that will invariably turn out to be true.

Rather, I believe your disagreement with me (which, for the record, I 
deeply respect) runs along a similar vein as the one you're having with 
Michal Kleczek.


> As the OP
> pointed out, his *user* - the person who entered the data and is now
> viewing it, knows exactly what the insertion order was, and expects to
> see it kept.

The OP didn't specify that (or I must have missed something), but it's 
not an unreasonable assumption.
However, the fact that it comes from the user and goes back to the user, 
and that the user wants the order to remain the same, doesn't mean that 
every intermediary component it passes through should have to worry 
about it.


> LinkedHashMap provides that guarantee of predictability to
> the *user* here, as the OP explained - Map does not.
>
> I agree that _declaring_ the return type as LinkedHashMap does not
> achieve that; the ironclad knowledge that it _is_ LinkedHashMap does,
> even if it's declared as Map. But in some cases (see above) there is no
> harm, and arguably some utility, in making the explicit declaration.
> That's the point I've been trying to make.

> Evidently I'm running into
> the "program to an interface at all costs" principle.

One remark on that, because you have brought it up repeatedly:
  The fact that you have encountered people or situations where "program 
to an interface" was used as a dogma doesn't mean it's always wrong. 
Neither does it mean that it's wrong most of the time. It simply means 
it's not always correct.
  This is simple logic, but I think it's important. I for one certainly 
do not hold it as a dogma, and do have what I think are very good 
reasons in this particular case for the approach I advocate. But at any 
rate, I feel that strenuously ( ;) ) bringing up the misuses of the 
general principle, while factually correct, is more detrimental than 
helpful for this discussion.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3981

On 5/10/2011 4:01 PM, Arved Sandstrom wrote:
...
> I agree that _declaring_ the return type as LinkedHashMap does not
> achieve that; the ironclad knowledge that it _is_ LinkedHashMap does,
> even if it's declared as Map. But in some cases (see above) there is no
> harm, and arguably some utility, in making the explicit declaration.
> That's the point I've been trying to make. Evidently I'm running into
> the "program to an interface at all costs" principle.
...

I think some of the trouble might lie in the ambiguity, in a Java
context, of the sentence "Program to an interface.".

Meaning 1: Users of some module (in the widest sense) should depend only
on what is declared and specified about the module, not on direct
knowledge of how it is currently implemented.

Meaning 2: Java programs should depend only in Java interface types to
represent what is declared and specified about a module for the use of
its callers.

I am very strongly in favor of meaning 1 of "Program to an interface.".
Everything any user of a module needs to know about it should be
declared and/or specified as part of its interface (in the general
sense), and using code should depend only on what is declared and
specified.

Failure to follow this principle can lead to fragile code in which a
change to the implementation of one module that does not change any part
of its declaration or specification breaks something else. At the worst,
nobody dares change anything.

I like Java interface types as a way of abstracting out interfaces
between modules, where appropriate, but I do not think "Program to an
interface" should be considered anywhere near as absolute a principle in
meaning 2 as in meaning 1.

Patricia

[toc] | [prev] | [next] | [standalone]

#3983

On 11/05/2011 19:41, Patricia Shanahan allegedly wrote:
> I think some of the trouble might lie in the ambiguity, in a Java
> context, of the sentence "Program to an interface.".
>
> Meaning 1: Users of some module (in the widest sense) should depend only
> on what is declared and specified about the module, not on direct
> knowledge of how it is currently implemented.
>
> Meaning 2: Java programs should depend only in Java interface types to
> represent what is declared and specified about a module for the use of
> its callers.
>
> I am very strongly in favor of meaning 1 of "Program to an interface.".
> Everything any user of a module needs to know about it should be
> declared and/or specified as part of its interface (in the general
> sense), and using code should depend only on what is declared and
> specified.

Absolutely. Isn't the wording "program to a contract rather to an 
implementation" also in use? I find that a much better one, because it 
doesn't evoke Java interfaces.

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#3989

Daniele Futtorovic wrote:
> Patricia Shanahan allegedly wrote:
>> I think some of the trouble might lie in the ambiguity, in a Java
>> context, of the sentence "Program to an interface.".
>>
>> Meaning 1: Users of some module (in the widest sense) should depend only
>> on what is declared and specified about the module, not on direct
>> knowledge of how it is currently implemented.
>>
>> Meaning 2: Java programs should depend only in Java interface types to
>> represent what is declared and specified about a module for the use of
>> its callers.
>>
>> I am very strongly in favor of meaning 1 of "Program to an interface.".
>> Everything any user of a module needs to know about it should be
>> declared and/or specified as part of its interface (in the general
>> sense), and using code should depend only on what is declared and
>> specified.

> Absolutely. Isn't the wording "program to a contract rather to an
> implementation" also in use? I find that a much better one, because it doesn't
> evoke Java interfaces.

I like the notion "program to the type".  This subsumes Java interfaces and 
classes, allows intelligent use of generics (which augment Java interfaces 
just beautifully) to make type assertions, and incorporates the notion of 
programming to a contract.  It also allows the type to be 'LinkedHashMap' 
where that is the type whose contract you actually need.

I have run into serious pushback from people who have a religion about 
contract-based programming and a very different idea from me about who should 
enforce what parts of a given contract.  I don't remember which 
Received-From-On-High placebo, er, miracle language they were touting - it's 
famous but I don't care so I forget - that allowed them to be just as dogmatic 
about "contract" as some in Java are about "interface", but their flavor of 
fundamentalism was no improvement.  One One True Way's proselyte is just as 
crappy and obnoxious as every other One True Way's.

-- 
Lew
Never generalize.

[toc] | [prev] | [next] | [standalone]

#3992

On 11/05/2011 22:42, Lew allegedly wrote:
> Daniele Futtorovic wrote:
>> Patricia Shanahan allegedly wrote:
>>> I think some of the trouble might lie in the ambiguity, in a Java
>>> context, of the sentence "Program to an interface.".
>>>
>>> Meaning 1: Users of some module (in the widest sense) should depend only
>>> on what is declared and specified about the module, not on direct
>>> knowledge of how it is currently implemented.
>>>
>>> Meaning 2: Java programs should depend only in Java interface types to
>>> represent what is declared and specified about a module for the use of
>>> its callers.
>>>
>>> I am very strongly in favor of meaning 1 of "Program to an interface.".
>>> Everything any user of a module needs to know about it should be
>>> declared and/or specified as part of its interface (in the general
>>> sense), and using code should depend only on what is declared and
>>> specified.
>
>> Absolutely. Isn't the wording "program to a contract rather to an
>> implementation" also in use? I find that a much better one, because it
>> doesn't
>> evoke Java interfaces.
>
> I like the notion "program to the type". This subsumes Java interfaces
> and classes, allows intelligent use of generics (which augment Java
> interfaces just beautifully) to make type assertions, and incorporates
> the notion of programming to a contract. It also allows the type to be
> 'LinkedHashMap' where that is the type whose contract you actually need.

Not sure about "type". To me this "to the interface/contract" is a step 
on the path towards hypothetical minimalism and good definitions.
Good definitions are a Good Thing not only for types, but also for 
components, layers and applications as a whole. But they're different 
/sorts/ of definitions for each level.


> I have run into serious pushback from people who have a religion about
> contract-based programming and a very different idea from me about who
> should enforce what parts of a given contract. I don't remember which
> Received-From-On-High placebo, er, miracle language they were touting -
> it's famous but I don't care so I forget - that allowed them to be just
> as dogmatic about "contract" as some in Java are about "interface", but
> their flavor of fundamentalism was no improvement. One One True Way's
> proselyte is just as crappy and obnoxious as every other One True Way's.

ADA, mayhap?

-- 
DF.
An escaped convict once said to me:
"Alcatraz is the place to be"

[toc] | [prev] | [next] | [standalone]

#4000

In article <iqevca$fmg$1@dont-email.me>,
 Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> wrote:

> On 11/05/2011 22:42, Lew allegedly wrote:
> > Daniele Futtorovic wrote:
> >> Patricia Shanahan allegedly wrote:
> >>> I think some of the trouble might lie in the ambiguity, in a Java 
> >>> context, of the sentence "Program to an interface.".
> >>>
> >>> Meaning 1: Users of some module (in the widest sense) should 
> >>> depend only on what is declared and specified about the module, 
> >>> not on direct knowledge of how it is currently implemented.
> >>>
> >>> Meaning 2: Java programs should depend only in Java interface 
> >>> types to represent what is declared and specified about a module 
> >>> for the use of its callers.
> >>>
> >>> I am very strongly in favor of meaning 1 of "Program to an 
> >>> interface.". Everything any user of a module needs to know about 
> >>> it should be declared and/or specified as part of its interface 
> >>> (in the general sense), and using code should depend only on what 
> >>> is declared and specified.
> >
> >> Absolutely. Isn't the wording "program to a contract rather to an 
> >> implementation" also in use? I find that a much better one, 
> >> because it doesn't evoke Java interfaces.
> >
> > I like the notion "program to the type". This subsumes Java 
> > interfaces and classes, allows intelligent use of generics (which 
> > augment Java interfaces just beautifully) to make type assertions, 
> > and incorporates the notion of programming to a contract. It also 
> > allows the type to be 'LinkedHashMap' where that is the type whose 
> > contract you actually need.
> 
> Not sure about "type". To me this "to the interface/contract" is a 
> step on the path towards hypothetical minimalism and good 
> definitions. Good definitions are a Good Thing not only for types, 
> but also for components, layers and applications as a whole. But 
> they're different /sorts/ of definitions for each level.
> 
> > I have run into serious pushback from people who have a religion 
> > about contract-based programming and a very different idea from me 
> > about who should enforce what parts of a given contract. I don't 
> > remember which Received-From-On-High placebo, er, miracle language 
> > they were touting - it's famous but I don't care so I forget - that 
> > allowed them to be just as dogmatic about "contract" as some in 
> > Java are about "interface", but their flavor of fundamentalism was 
> > no improvement. One One True Way's proselyte is just as crappy and 
> > obnoxious as every other One True Way's.
> 
> _Ada_, mayhap?

Ada [1]? It's not impossible, but the zealotry reminds me more of 
Eiffel [2], which includes particular support for design by contract 
[3]. Lew's notion of "program to the type" reminds me of the concept of 
abstract data type [4], which is well supported by Ada's notion of 
specification (package interface) and consistent with Patricia's 
Meaning 1.

[1]<http://en.wikipedia.org/wiki/Ada_(programming_language)>
[2]<http://en.wikipedia.org/wiki/Eiffel_(programming_language)#Design_by_Contract>
[3]<http://en.wikipedia.org/wiki/Eiffel_(programming_language)#Design_by_Contract>
[4]<http://en.wikipedia.org/wiki/Abstract_data_type>

-- 
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web