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


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

Re: JLS 3/e -- Lots Of Errors

Started byLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
First post2011-02-05 14:37 +1300
Last post2011-02-05 12:52 -0500
Articles 8 — 4 participants

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: JLS 3/e -- Lots Of Errors Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-05 14:37 +1300
    Re: JLS 3/e -- Lots Of Errors Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-02-05 00:15 -0500
      Re: JLS 3/e -- Lots Of Errors Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-02-05 10:10 -0500
      Re: JLS 3/e -- Lots Of Errors Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-05 19:41 +1300
    Re: JLS 3/e -- Lots Of Errors Lew <noone@lewscanon.com> - 2011-02-04 23:59 -0500
      Re: JLS 3/e -- Lots Of Errors Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-05 19:42 +1300
        Re: JLS 3/e -- Lots Of Errors Lew <noone@lewscanon.com> - 2011-02-05 09:34 -0500
          Re: JLS 3/e -- Lots Of Errors "javax.swing.JSnarker" <gharriman@boojum.mit.edu> - 2011-02-05 12:52 -0500

#25555 — Re: JLS 3/e -- Lots Of Errors

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-02-05 14:37 +1300
SubjectRe: JLS 3/e -- Lots Of Errors
Message-ID<iii9ku$58c$1@lust.ihug.co.nz>
Here’s another fun one.

In section 4.8, on page 58, it says:

    The use of raw types is allowed only as a concession to compatibility of
    legacy code. The use of raw types in code written after the introduction
    of genericity into the Java programming language is strongly
    discouraged. It is possible that future versions of the Java programming
    language will disallow the use of raw types.

(That last sentence is in bold.) However, in the discussion on page 136:

    Note that expression names may be qualified by type names, but not by
    types in general. A consequence is that it is not possible to access a
    class variable through a parameterized type
        class Foo<T> {
        public static int classVar = 42;
        }
        Foo<String>.classVar = 91; // illegal
    Instead, one writes
        Foo.classVar = 91;
    This does not restrict the language in any meaningful way. Type
    parameters may not be used in the types of static variables, and so the
    actual parameters of a parameterized type can never influence the type
    of a static variable. Therefore, no expressive power is lost.
    Technically, the type name Foo above is a raw type, but this use of raw
    types is harmless, and does not give rise to warnings.

So one the one hand raw types are deprecated, but on the other hand they are 
the only permitted way to access static fields of a parameterized type.

[toc] | [next] | [standalone]


#25648

FromJoshua Cranmer <Pidgeot18@verizon.invalid>
Date2011-02-05 00:15 -0500
Message-ID<iiimec$dh1$1@news.eternal-september.org>
In reply to#25555
On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
> Here’s another fun one.
>
> In section 4.8, on page 58, it says:
>
>      The use of raw types is allowed only as a concession to compatibility of
>      legacy code. The use of raw types in code written after the introduction
>      of genericity into the Java programming language is strongly
>      discouraged. It is possible that future versions of the Java programming
>      language will disallow the use of raw types.
>
> (That last sentence is in bold.) However, in the discussion on page 136:
>
>      Note that expression names may be qualified by type names, but not by
>      types in general.

I trimmed this down to the key sentence. The discussion notes that it's 
a type name *and not a type* that defines the expression name. Raw types 
are generic types that are not used in a generic manner, e.g., in class 
instance creation expressions. I suspect this may have been done, in 
part, to emphasize that Java's generics are not C++'s templates.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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


#25904

FromJoshua Cranmer <Pidgeot18@verizon.invalid>
Date2011-02-05 10:10 -0500
Message-ID<iijp9j$ljk$1@news.eternal-september.org>
In reply to#25648
On 02/05/2011 01:41 AM, Lawrence D'Oliveiro wrote:
> In message<iiimec$dh1$1@news.eternal-september.org>, Joshua Cranmer wrote:
>
>> On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
>>
>>> Here’s another fun one.
>>>
>>> In section 4.8, on page 58, it says:
>>>
>>>       The use of raw types is allowed only as a concession to
>>>       compatibility of legacy code. The use of raw types in code written
>>>       after the introduction of genericity into the Java programming
>>>       language is strongly discouraged. It is possible that future
>>>       versions of the Java programming language will disallow the use of
>>>       raw types.
>>>
>>> (That last sentence is in bold.) However, in the discussion on page 136:
>>>
>>>       Technically, the type name Foo above is a raw type ...
>>
>> I trimmed this down to the key sentence.
>
> So did I. Try again.

A type *name* is not a *type*.

-- 
Beware of bugs in the above code; I have only proved it correct, not 
tried it. -- Donald E. Knuth

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


#26041

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-02-05 19:41 +1300
Message-ID<iiirdt$fh3$1@lust.ihug.co.nz>
In reply to#25648
In message <iiimec$dh1$1@news.eternal-september.org>, Joshua Cranmer wrote:

> On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
>
>> Here’s another fun one.
>>
>> In section 4.8, on page 58, it says:
>>
>>      The use of raw types is allowed only as a concession to
>>      compatibility of legacy code. The use of raw types in code written
>>      after the introduction of genericity into the Java programming
>>      language is strongly discouraged. It is possible that future
>>      versions of the Java programming language will disallow the use of
>>      raw types.
>>
>> (That last sentence is in bold.) However, in the discussion on page 136:
>>
>>      Technically, the type name Foo above is a raw type ...
> 
> I trimmed this down to the key sentence.

So did I. Try again.

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


#25712

FromLew <noone@lewscanon.com>
Date2011-02-04 23:59 -0500
Message-ID<iiilep$spb$2@news.albasani.net>
In reply to#25555
On 02/04/2011 08:37 PM, Lawrence D'Oliveiro wrote:
> Here’s another fun one.
>
> In section 4.8, on page 58, it says:
>
>      The use of raw types is allowed only as a concession to compatibility of
>      legacy code. The use of raw types in code written after the introduction
>      of genericity into the Java programming language is strongly
>      discouraged. It is possible that future versions of the Java programming
>      language will disallow the use of raw types.
>
> (That last sentence is in bold.) However, in the discussion on page 136:
>
>      Note that expression names may be qualified by type names, but not by
>      types in general. A consequence is that it is not possible to access a
>      class variable through a parameterized type
>          class Foo<T>  {
>          public static int classVar = 42;
>          }
>          Foo<String>.classVar = 91; // illegal
>      Instead, one writes
>          Foo.classVar = 91;
>      This does not restrict the language in any meaningful way. Type
>      parameters may not be used in the types of static variables, and so the
>      actual parameters of a parameterized type can never influence the type
>      of a static variable. Therefore, no expressive power is lost.
>      Technically, the type name Foo above is a raw type, but this use of raw
>      types is harmless, and does not give rise to warnings.
>
> So one the one hand raw types are deprecated, but on the other hand they are
> the only permitted way to access static fields of a parameterized type.

That is neither an error nor a typo, nor sloppy, but a precise description of 
the actual rules.

You may think the rules are screwy, but the JLS itself is not sloppy nor 
erroneous there.

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

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


#25823

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-02-05 19:42 +1300
Message-ID<iiirg0$fh3$2@lust.ihug.co.nz>
In reply to#25712
In message <iiilep$spb$2@news.albasani.net>, Lew wrote:

> You may think the rules are screwy, but the JLS itself is not sloppy nor
> erroneous there.

You don’t think it “sloppy” to have a technique recommended in one place and 
deprecated in another part of the same spec?

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


#25947

FromLew <noone@lewscanon.com>
Date2011-02-05 09:34 -0500
Message-ID<iijn58$ccs$1@news.albasani.net>
In reply to#25823
On 02/05/2011 01:42 AM, Lawrence D'Oliveiro wrote:
> In message<iiilep$spb$2@news.albasani.net>, Lew wrote:
>
>> You may think the rules are screwy, but the JLS itself is not sloppy nor
>> erroneous there.
>
> You don’t think it “sloppy” to have a technique recommended in one place and
> deprecated in another part of the same spec?

Where does that happen?  You haven't cited any such thing and I don't know of 
such a thing.  In the particular case here, Joshua Cranmer has already shown 
you where you went wrong.  Don't you assimilate these responses, or are you 
simply a troll?

The JLS is obfuscatory in parts, and a bit light in other parts. but I don't 
agree that it's "sloppy".  That is not to claim it cannot be improved, but 
overall I find it precise and reliable.

Anyway, you started this thread with the claim that the JLS is riddled with 
errors and typos.  Now you're saying merely that it is "sloppy" (whatever that 
means) in parts.  Some of what you offer as evidence is not sloppy, but 
difficult to understand and clearly you have not yet understood those parts. 
While I see why they're difficult to understand, as they are for me and for 
just about anyone, our lack of understanding is not equivalent to error or 
typo in the JLS.

Try fixing your understanding instead of what isn't broken.

If your goal is rather to troll, and refuse to accept anything that folks are 
telling you, I'm sorry to say you aren't being very notable.  Trolls here set 
a much higher standard.  You'll have to step it up.  Start attacking us 
personally!  Shift the ground of your discourse more.  You're already on the 
way with erroneous statements of fact ("Virtual methods started with C++") and 
simple restatement of claims already refuted in the discussion.  But that's 
kid stuff.  Bring it, dude!

-- 
Lew
Ceci n'est pas une fenêtre.
.___________.
|###] | [###|
|##/  | *\##|
|#/ * |   \#|
|#----|----#|
||    |  * ||
|o *  |    o|
|_____|_____|
|===========|

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


#26107

From"javax.swing.JSnarker" <gharriman@boojum.mit.edu>
Date2011-02-05 12:52 -0500
Message-ID<iik2o9$dv4$1@speranza.aioe.org>
In reply to#25947
On 05/02/2011 9:34 AM, Lew wrote:
> If your goal is rather to troll, and refuse to accept anything that
> folks are telling you, I'm sorry to say you aren't being very notable.
> Trolls here set a much higher standard. You'll have to step it up. Start
> attacking us personally! Shift the ground of your discourse more. You're
> already on the way with erroneous statements of fact ("Virtual methods
> started with C++") and simple restatement of claims already refuted in
> the discussion. But that's kid stuff. Bring it, dude!

Are you crazy? Do you really want another Twisted on your hands? The 
traffic numbers in this group still haven't recovered from the last one!

-- 
In <iijn58$ccs$1@news.albasani.net>, Lew admitted:
 > The JLS is obfuscatory in parts

[toc] | [prev] | [standalone]


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


csiph-web