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

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

Re: "implements" does not mean "implements"

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "implements" does not mean "implements" Arne Vajhøj <arne@vajhoej.dk> - 2016-11-10 21:05 -0500
    Re: "implements" does not mean "implements" Sebastian <nowhere@nirvana.org> - 2016-11-12 11:22 +0100
      Re: "implements" does not mean "implements" Arne Vajhøj <arne@vajhoej.dk> - 2016-11-12 08:50 -0500
        Re: "implements" does not mean "implements" Sebastian <nowhere@nirvana.org> - 2016-11-13 22:30 +0100
          Re: "implements" does not mean "implements" Arne Vajhøj <arne@vajhoej.dk> - 2016-11-14 19:48 -0500

#35891 — Re: "implements" does not mean "implements"

On 11/9/2016 7:45 PM, Stefan Ram wrote:
>   Just a small thought I had on the train today:
>
>   "implements" does not always mean "implements".
>
>   For example, this compiles:
>
> interface A { void m(); }
>
> abstract class C implements A { public abstract void m(); }

This is more terminology than Java.

It is correct that C does not have an implementation for
the method m.

But I think that you can say that C implements A anyway.

Reason:
* with no m in C you would get a compile error
* non-abstract methods in C can use m

So m is in some sense present in C even though the
actual implementation have to be supplied by a
sub class.

Arne

[toc] | [next] | [standalone]

#35893

Am 11.11.2016 um 03:05 schrieb Arne Vajhøj:
> On 11/9/2016 7:45 PM, Stefan Ram wrote:
>>   Just a small thought I had on the train today:
>>
>>   "implements" does not always mean "implements".
>>
>>   For example, this compiles:
>>
>> interface A { void m(); }
>>
>> abstract class C implements A { public abstract void m(); }
>
> This is more terminology than Java.
[snip]
> So m is in some sense present in C even though the
> actual implementation have to be supplied by a
> sub class.
>
> Arne

I like to say that interfaces specify behaviors of objects, not 
properties of classes. Saying that C implements A amounts to saying that 
any o that is an instance of C behaves like an A. It has nothing to do 
with what methods get implemented in C.

I would agree that this is terminological hairsplitting without 
relevance to Java.

-- Sebastian

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

#35894

On 11/12/2016 5:22 AM, Sebastian wrote:
> Am 11.11.2016 um 03:05 schrieb Arne Vajhøj:
>> On 11/9/2016 7:45 PM, Stefan Ram wrote:
>>>   Just a small thought I had on the train today:
>>>
>>>   "implements" does not always mean "implements".
>>>
>>>   For example, this compiles:
>>>
>>> interface A { void m(); }
>>>
>>> abstract class C implements A { public abstract void m(); }

>> So m is in some sense present in C even though the
>> actual implementation have to be supplied by a
>> sub class.
>
> I like to say that interfaces specify behaviors of objects, not
> properties of classes. Saying that C implements A amounts to saying that
> any o that is an instance of C behaves like an A. It has nothing to do
> with what methods get implemented in C.

Behavior of objects and properties of classes should have some
relationship.

But just realized something that I think matches well
with you way of thinking.

interface A { void m(); }

abstract class C implements A { }

class Foobar extends C { public void m() { } }

actually compiles - it is not necessary to have an abstract m in C.

Arne

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

#35895

Am 12.11.2016 um 14:50 schrieb Arne Vajhøj:
> On 11/12/2016 5:22 AM, Sebastian wrote:
>> I like to say that interfaces specify behaviors of objects, not
>> properties of classes. Saying that C implements A amounts to saying that
>> any o that is an instance of C behaves like an A. It has nothing to do
>> with what methods get implemented in C.
>
> Behavior of objects and properties of classes should have some
> relationship.
>
> But just realized something that I think matches well
> with you way of thinking.
>
> interface A { void m(); }
>
> abstract class C implements A { }
>
> class Foobar extends C { public void m() { } }
>
> actually compiles - it is not necessary to have an abstract m in C.
>
> Arne

yes, indeed, the methods are already abstract in C by virtue of the 
interface.

By the way, a typical use of such an idiom may be where C is some 
abstract class that offers some help in implementing A, or adds related 
behavior, so that C wouldn't really be an abstraction in its own right, 
but would exist only for purposes of code-reuse. In Java 8, such usage 
could be replaced with default methods in interfaces.

-- Sebastian

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

#35898

On 11/13/2016 4:30 PM, Sebastian wrote:
> Am 12.11.2016 um 14:50 schrieb Arne Vajhøj:
>> On 11/12/2016 5:22 AM, Sebastian wrote:
>>> I like to say that interfaces specify behaviors of objects, not
>>> properties of classes. Saying that C implements A amounts to saying that
>>> any o that is an instance of C behaves like an A. It has nothing to do
>>> with what methods get implemented in C.
>>
>> Behavior of objects and properties of classes should have some
>> relationship.
>>
>> But just realized something that I think matches well
>> with you way of thinking.
>>
>> interface A { void m(); }
>>
>> abstract class C implements A { }
>>
>> class Foobar extends C { public void m() { } }
>>
>> actually compiles - it is not necessary to have an abstract m in C.

> yes, indeed, the methods are already abstract in C by virtue of the
> interface.
>
> By the way, a typical use of such an idiom may be where C is some
> abstract class that offers some help in implementing A, or adds related
> behavior, so that C wouldn't really be an abstraction in its own right,
> but would exist only for purposes of code-reuse. In Java 8, such usage
> could be replaced with default methods in interfaces.

Only if fields and constructors are not needed.

Arne

[toc] | [prev] | [standalone]

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

csiph-web