abstract vs. final  
Author Message
Chris Dollin





PostPosted: 2007-12-12 16:41:00 Top

java-programmer, abstract vs. final Lew wrote:

> It is not the compiler's responsibility to find test code; it's the compiler's
> responsibility to check the compilability of the artifact itself.
>
> Your idea that there should be a tool, perhaps as part of JUnit or similar
> framework, to check for test coverage is a good one.

(Isn't "test coverage" a stronger notion that just "every entity has a test",
more like "every /code path/ has a test"?)

> You could use the presence of such a tool as an evaluative factor in choosing
> an IDE.
>
> But it is no part of what the compiler should do.

Clearly we have different opinions on what compilers "should", or
perhaps "should not" do. I think it's clearly /useful/ for a compiler
to [be able to] note that there's no use made of some declared entity [1]
in some codebase and I would not apply a "should not" to remove a
useful feature. (Usual tradeoff remarks apply.)

I think I'm done.

[1] I spelled `entity` "thingy" in earlier posts, for want of remembering
the word; I'm not trying to change what I meant.

--
Chris "and you've got to be ready" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 
Chris Dollin





PostPosted: 2007-12-12 16:41:00 Top

java-programmer >> abstract vs. final Lew wrote:

> It is not the compiler's responsibility to find test code; it's the compiler's
> responsibility to check the compilability of the artifact itself.
>
> Your idea that there should be a tool, perhaps as part of JUnit or similar
> framework, to check for test coverage is a good one.

(Isn't "test coverage" a stronger notion that just "every entity has a test",
more like "every /code path/ has a test"?)

> You could use the presence of such a tool as an evaluative factor in choosing
> an IDE.
>
> But it is no part of what the compiler should do.

Clearly we have different opinions on what compilers "should", or
perhaps "should not" do. I think it's clearly /useful/ for a compiler
to [be able to] note that there's no use made of some declared entity [1]
in some codebase and I would not apply a "should not" to remove a
useful feature. (Usual tradeoff remarks apply.)

I think I'm done.

[1] I spelled `entity` "thingy" in earlier posts, for want of remembering
the word; I'm not trying to change what I meant.

--
Chris "and you've got to be ready" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 
Lew





PostPosted: 2007-12-12 23:30:00 Top

java-programmer >> abstract vs. final Chris Dollin wrote:
> Lew wrote:
>
>> It is not the compiler's responsibility to find test code; it's the compiler's
>> responsibility to check the compilability of the artifact itself.
>>
>> Your idea that there should be a tool, perhaps as part of JUnit or similar
>> framework, to check for test coverage is a good one.
>
> (Isn't "test coverage" a stronger notion that just "every entity has a test",
> more like "every /code path/ has a test"?)

Doesn't affect the point I was making.

>> You could use the presence of such a tool as an evaluative factor in choosing
>> an IDE.
>>
>> But it is no part of what the compiler should do.
>
> Clearly we have different opinions on what compilers "should", or

The word is "compiler". Its job is to compile, not to test. Only things that
break the language rules should be flagged. Not using a constructor doesn't
break the language rules. Note that the test suite will not be in the
production environment, so even though you have test code in the IDE, it won't
be there in the release. So those constructors will still wind up "unused"
even if your fantasy compiler had vetted them.

> perhaps "should not" do. I think it's clearly /useful/ for a compiler
> to [be able to] note that there's no use made of some declared entity [1]

Useful to you, but a true annoyance to everyone else.

> in some codebase and I would not apply a "should not" to remove a
> useful feature. (Usual tradeoff remarks apply.)

I would apply a "should not" to a feature that is not actually useful, as
having a compiler perform the function of a test tool would not be.

--
Lew
 
 
Chris Dollin





PostPosted: 2007-12-12 23:51:00 Top

java-programmer >> abstract vs. final Lew wrote:

> Chris Dollin wrote:

>> Clearly we have different opinions on what compilers "should", or
>
> The word is "compiler". Its job is to compile, not to test. Only things that
> break the language rules should be flagged.

Which part of "Clearly we have different opinions" was opaque to you?

Your attitude to what the compiler (are we distinguishing "compiler" and "IDE"
here?) 'should' do sound /just like/ early attitudes to what C compilers should
or should not do -- the minimum required to generate code and report violations
of what the language said was OK. Other fancy checking was left to lint. As
far as I can tell, nowadays C compilers are /expected/ to spot likely
problems and -- configurably -- report them, because that's more effective
for developers, rather than being compatible with a purist attitude to the
names of things. (Not that lint is obsolete, of course.)

I don't see why Java should be different in this respect. (Note that I'm not
/demanding/ that compilers should report unused entities. Did you think I was?)

>> perhaps "should not" do. I think it's clearly /useful/ for a compiler
>> to [be able to] note that there's no use made of some declared entity [1]
>
> Useful to you, but a true annoyance to everyone else.

Oh, /please/. I refer you to Zig's earlier post, which started this
subdiscussion:

| A good IDE will probably issue an excessive/unused code warning for
| writing a constructor that never gets called. Of course, you can always
| add a @SupressWarnings, or just turn off that warning.

I read that as at least one other poster not counting it as a "true
annoyance". Your "everyone else" is presently just handwaving, and
your assumption that such a feature would be unswitchoffable surprising
given the previous discussion.

I thought I was done, but I was wrong. This time I /am/ done.

--
Chris "silence is transmission failure" Dollin

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

 
 
Lew





PostPosted: 2007-12-13 0:21:00 Top

java-programmer >> abstract vs. final Chris Dollin wrote:
> Lew wrote:
>
>> Chris Dollin wrote:
>
>>> Clearly we have different opinions on what compilers "should", or
>> The word is "compiler". Its job is to compile, not to test. Only things that
>> break the language rules should be flagged.
>
> Which part of "Clearly we have different opinions" was opaque to you?

No part.

> Your attitude to what the compiler (are we distinguishing "compiler" and "IDE"

Yes, we most certainly are.

> here?) 'should' do sound /just like/ early attitudes to what C compilers should
> or should not do -- the minimum required to generate code and report violations
> of what the language said was OK. Other fancy checking was left to lint. As
> far as I can tell, nowadays C compilers are /expected/ to spot likely
> problems and -- configurably -- report them, because that's more effective
> for developers, rather than being compatible with a purist attitude to the
> names of things. (Not that lint is obsolete, of course.)

Do C compilers these days report when library features are not used? I was
not aware of that.

> I don't see why Java should be different in this respect. (Note that I'm not
> /demanding/ that compilers should report unused entities. Did you think I was?)

Yes, I did.

>>> perhaps "should not" do. I think it's clearly /useful/ for a compiler
>>> to [be able to] note that there's no use made of some declared entity [1]
>> Useful to you, but a true annoyance to everyone else.
>
> Oh, /please/. I refer you to Zig's earlier post, which started this
> subdiscussion:
>
> | A good IDE will probably issue an excessive/unused code warning for
> | writing a constructor that never gets called. Of course, you can always
> | add a @SupressWarnings, or just turn off that warning.

Good IDE, yes, compiler, no. Compilers traditionally have not taken on the
role of test tools.

> I read that as at least one other poster not counting it as a "true
> annoyance". Your "everyone else" is presently just handwaving, and

Not applicable. The quoted remark was about an IDE, not a compiler.

> your assumption that such a feature would be unswitchoffable surprising
> given the previous discussion.

I favor having this in an IDE. It's the compiler that I aver should not.

> I thought I was done, but I was wrong. This time I /am/ done.

Thank you for the enlivening discussion.

--
Lew
 
 
Roedy Green





PostPosted: 2007-12-14 6:00:00 Top

java-programmer >> abstract vs. final On Mon, 10 Dec 2007 11:02:40 -0500, Lew <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>Philosophies? What does that have to do with it? The JLS *mandates* what
>final means; IntelliJ is not at liberty to change the language.

Fine. But they DID.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2007-12-14 6:05:00 Top

java-programmer >> abstract vs. final On Mon, 10 Dec 2007 11:18:20 -0500, Lew <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>Wait, I just got where you said "the code refactor encourages" - you mean to
>say, that later one *removes* the final decoration if one decides to make the
>class heritable, right?

If you have any classes without subclasses, the Inspector will report
as a "defect" that they are missing the "final". If you want the Lint
perfect stamp, you need to mark all unsubclassed classes final.

I think this is a perfectly valid thing to do for in-house use.
Subclassing a class for the first time is sort of like taking its
virginity. It should not be done lightly. You could be made aware, to
make you double check you are subclassing the correct class.

For public distribution, without source, you need to be more sparing
with final so you don't screw up your clients. If you distribute
source, they can fairly easily peel off the final.

I go along with the inspector mainly for documentation purposes. I
like the assurance of the "final" there are no subclasses I could muck
up by changing a class.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2007-12-14 6:11:00 Top

java-programmer >> abstract vs. final On Mon, 10 Dec 2007 09:26:33 -0800, Daniel Pitts
<email***@***.com> wrote, quoted or indirectly
quoted someone who said :

>Its unfortunate that the "best practice" case is the more verbose. Many
>people would prefer to have a keyword such as "modifiable" or
>"extendable" rather than the converse.

I agree. the keyword could be something like var, mutable, changes,
alter, fickle, unstable.

Perhaps in the successor to Java.

Or perhaps if someone ever writes a SCID, ordinary java could display
"missing final" as "var", or with a special twitching icon or colour.

To traditional users viewing your code, they would see it as it is
now.

see http://mindprod.com/jgloss/scid.html

Even an IDE might use colour to remind you of non-final status.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Lew





PostPosted: 2007-12-14 9:52:00 Top

java-programmer >> abstract vs. final Roedy Green wrote:
> On Mon, 10 Dec 2007 11:02:40 -0500, Lew <email***@***.com> wrote,
> quoted or indirectly quoted someone who said :
>
>> Philosophies? What does that have to do with it? The JLS *mandates* what
>> final means; IntelliJ is not at liberty to change the language.
>
> Fine. But they DID.

Eclipse has an inspector that hints at the lack of "final" in class
declarations, but it manages to do it without violating the language spec.

Are you certain IntelliJ actually changes the Java language? I was under the
impression from what you said that it encourages making a class final at
first, and /removing/ the 'final' later if you change your mind. Did I
misunderstand you?

--
Lew
 
 
Daniel Dyer





PostPosted: 2007-12-14 10:21:00 Top

java-programmer >> abstract vs. final On Fri, 14 Dec 2007 01:51:52 -0000, Lew <email***@***.com> wrote:

> Roedy Green wrote:
>> On Mon, 10 Dec 2007 11:02:40 -0500, Lew <email***@***.com> wrote,
>> quoted or indirectly quoted someone who said :
>>
>>> Philosophies? What does that have to do with it? The JLS *mandates*
>>> what final means; IntelliJ is not at liberty to change the language.
>> Fine. But they DID.
>
> Eclipse has an inspector that hints at the lack of "final" in class
> declarations, but it manages to do it without violating the language
> spec.
>
> Are you certain IntelliJ actually changes the Java language? I was
> under the impression from what you said that it encourages making a
> class final at first, and /removing/ the 'final' later if you change
> your mind. Did I misunderstand you?

I guess Roedy is referring to the "Declaration can have final modifier"
inspection.

"This inspection reports all fields, methods or classes, found in the
specified inspection scope, that may have a final modifier added to their
declarations. Use check boxes in the inspection options below, to define
which declarations are to be reported."

You can enable it for classes, methods and/or fields. Mine is only set to
report fields (I think this is the default, or maybe the inspection is
disabled by default). By default this inspection generates warnings but
all warnings can be upgraded to errors if you so choose.

There is also a "final class" inspection which does the exact opposite, so
you wouldn't want both inspections enabled at the same time:

"This inspection reports any instances of classes being declared final.
Some coding standards discourage final classes."

Dan.


--
Daniel Dyer
http://www.uncommons.org
 
 
Lew





PostPosted: 2007-12-14 11:11:00 Top

java-programmer >> abstract vs. final Daniel Dyer wrote:
> I guess Roedy is referring to the "Declaration can have final modifier"
> inspection.
>
> "This inspection reports all fields, methods or classes, found in the
> specified inspection scope, that may have a final modifier added to
> their declarations. Use check boxes in the inspection options below, to
> define which declarations are to be reported."
>
> You can enable it for classes, methods and/or fields. Mine is only set
> to report fields (I think this is the default, or maybe the inspection
> is disabled by default). By default this inspection generates warnings
> but all warnings can be upgraded to errors if you so choose.
>
> There is also a "final class" inspection which does the exact opposite,
> so you wouldn't want both inspections enabled at the same time:
>
> "This inspection reports any instances of classes being declared final.
> Some coding standards discourage final classes."

This seems similar to Eclipse's way. So they DIDN'T redefine the language.

--
Lew
 
 
Roedy Green





PostPosted: 2007-12-14 23:58:00 Top

java-programmer >> abstract vs. final On Thu, 13 Dec 2007 20:51:52 -0500, Lew <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

>
>Are you certain IntelliJ actually changes the Java language?

No. It simply suggests you insert final on every class without
subclasses every time you run the inspector. I am in the habit of
liking lints to say all is fine. It is like wanting to remove all
warning messages from your Java code.

If you ignore those requests, you have to study the list of
suggestions carefully to make sure there are no other flavours in
there.

I think somewhere way back you misinterpreted what I was saying and I
have not been able to shake you of that interpretation even through
several tries.

What I am saying is the philosophy of the authors of the Inspector is
that you should apply "final" to any classes without subclasses, and
if you later decide you need to subclass, you should manually remove
the final keyword. "final" block subclassing in the perfectly usual
way.

The difference is in Sun philosophy, "final" means not subclassable,
and WILL NEVER be subclassable. Intellij philosophy is, not
subclassed, not subclassable, but might be some day, if someone
removes the "final".

From the compiler's point of view, the two philosophies are not
distinguishable. They refer to future intent of humans, nothing to do
with how the code operates now.

As you quoted, Sun makes its philosophy explicit in the JLS, though of
course there in nothing to stop you from changing your mind and
removing the "final".
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Roedy Green





PostPosted: 2007-12-15 0:00:00 Top

java-programmer >> abstract vs. final On Thu, 13 Dec 2007 22:10:45 -0500, Lew <email***@***.com> wrote,
quoted or indirectly quoted someone who said :

> So they DIDN'T redefine the language.

Nope. They did not redefine the language, unless you consider that bit
of the JLS on the philosophy of using final part of the language. That
bit of philosophy is not relevant to how a given string of text
compiles. It is a suggestion as to how final should be used in good
coding practice.

--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
 
Lew





PostPosted: 2007-12-15 9:40:00 Top

java-programmer >> abstract vs. final Roedy Green wrote:
> On Thu, 13 Dec 2007 22:10:45 -0500, Lew <email***@***.com> wrote,
> quoted or indirectly quoted someone who said :
>
>> So they DIDN'T redefine the language.
>
> Nope. They did not redefine the language, unless you consider that bit
> of the JLS on the philosophy of using final part of the language. That
> bit of philosophy is not relevant to how a given string of text
> compiles. It is a suggestion as to how final should be used in good
> coding practice.

You're clearly not referring to the part of the JLS that says,
> A compile-time error occurs if the name of a final class
> appears in the extends clause (搂8.1.4) of another class declaration;
> this implies that a final class cannot have any subclasses.
<http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.1.2>

To what in the JLS are you referring?

--
Lew
 
 
Lew





PostPosted: 2007-12-15 9:42:00 Top

java-programmer >> abstract vs. final Roedy Green wrote:
> On Thu, 13 Dec 2007 20:51:52 -0500, Lew <email***@***.com> wrote,
> quoted or indirectly quoted someone who said :
>
>> Are you certain IntelliJ actually changes the Java language?
>
> No. It simply suggests you insert final on every class without
> subclasses every time you run the inspector. I am in the habit of
> liking lints to say all is fine. It is like wanting to remove all
> warning messages from your Java code.
>
> If you ignore those requests, you have to study the list of
> suggestions carefully to make sure there are no other flavours in
> there.
>
> I think somewhere way back you misinterpreted what I was saying and I
> have not been able to shake you of that interpretation even through
> several tries.

Surely you're not ignoring where I said,
> Wait, I just got where you said "the code refactor encourages" -
> you mean to say, that later one *removes* the final decoration
> if one decides to make the class heritable, right?
>
> With that I agree wholeheartedly. I don't need IntelliJ to tell me that.
> It does make sense, and is validated in /Effective Java/ by Joshua Bloch,
> that a class should be non-heritable by default in the programmer's mind.
?

--
Lew
 
 
Lew





PostPosted: 2007-12-15 9:48:00 Top

java-programmer >> abstract vs. final Lew wrote:
> Roedy Green wrote:
>> On Thu, 13 Dec 2007 20:51:52 -0500, Lew <email***@***.com> wrote,
>> quoted or indirectly quoted someone who said :
>>
>>> Are you certain IntelliJ actually changes the Java language?
>>
>> No. It simply suggests you insert final on every class without
>> subclasses every time you run the inspector. I am in the habit of
>> liking lints to say all is fine. It is like wanting to remove all
>> warning messages from your Java code.
>>
>> If you ignore those requests, you have to study the list of
>> suggestions carefully to make sure there are no other flavours in
>> there.
>>
>> I think somewhere way back you misinterpreted what I was saying and I
>> have not been able to shake you of that interpretation even through
>> several tries.
>
> Surely you're not ignoring where I said,
>> Wait, I just got where you said "the code refactor encourages" - you
>> mean to say, that later one *removes* the final decoration if one
>> decides to make the class heritable, right?
>>
>> With that I agree wholeheartedly. I don't need IntelliJ to tell me
>> that. It does make sense, and is validated in /Effective Java/ by
>> Joshua Bloch, that a class should be non-heritable by default in the
>> programmer's mind.
> ?

Or where I asked:
> I was under the impression from what you said that it encourages
> making a class final at first, and /removing/ the 'final' later
> if you change your mind. Did I misunderstand you?
?

--
Lew