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


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

Re: JLS 3/e -- Lots Of Errors

Started byPatricia Shanahan <pats@acm.org>
First post2011-02-06 17:14 -0800
Last post2011-02-06 20:56 -0500
Articles 3 — 3 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 Patricia Shanahan <pats@acm.org> - 2011-02-06 17:14 -0800
    Re: JLS 3/e -- Lots Of Errors Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-02-07 14:17 +1300
      Re: JLS 3/e -- Lots Of Errors Arne Vajhøj <arne@vajhoej.dk> - 2011-02-06 20:56 -0500

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

FromPatricia Shanahan <pats@acm.org>
Date2011-02-06 17:14 -0800
SubjectRe: JLS 3/e -- Lots Of Errors
Message-ID<I8idncO4-e3h2tLQnZ2dnUVZ_oidnZ2d@earthlink.com>
On 2/6/2011 4:02 PM, Lawrence D'Oliveiro wrote:
> There are several constructs and terms that are used before they are
> defined, without any reference to where the definition may be found.
>
> For example, “strictfp” is first used in section 5.1.2, page 81, with no
> reference to where it is defined.
>
> The “<:” operator first occurs in section 4.5, page 51. There is no hint as
> to what it means until you get to page 55.
>
> Section 4, page 34:
>
>      Type arguments and type variables (§4.4) are not reified at run-time.
>
> But reification is not explained until section 4.7, page 56.
>
> Section 4.3.2, page 48:
>
>      The type of a method invocation e.getClass(), where the expression e has
>      the static type T, is Class<? extends |T|>.
>
> The |T| notation is not explained until section 4.6, page 56, where it turns
> out it denotes erasure.
>
> Section 6.3.1, page 119: “type-import-on-demand” and “static-import-on-
> demand” are not defined yet. No hint is given until page 127 that “static-
> import-on-demand” is defined in §7.5.4. Similarly no reference for “type-
> import-on-demand” is given until page 130, where it seems it comes from
> §7.5.2.
>
> It should be the job of an editor to catch this sort of thing.

This raises an interesting issue. If one assumes sequential reading,
each term absolutely must be defined no later than its first use,
because it will not be possible to jump to a later definition.

In practice, I don't think I have ever read a language specification the
way one reads a novel, beginning at the first page and continuing
sequentially to the end. Instead, I tend to jump in to a section that
seems relevant to some issue, and look for definitions of terms I don't
understand without assuming the definition will be earlier rather than
later.

I'm reasonably familiar with the JLS, but had simply not noticed that
sometimes the definition is after the first use. I've always been able
to find definitions when I've needed them.

Have other people been inconvenienced by definitions after the first use?

Patricia

[toc] | [next] | [standalone]


#25808

FromLawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
Date2011-02-07 14:17 +1300
Message-ID<iinh7v$6h2$1@lust.ihug.co.nz>
In reply to#25627
In message <I8idncO4-e3h2tLQnZ2dnUVZ_oidnZ2d@earthlink.com>, Patricia 
Shanahan wrote:

> This raises an interesting issue. If one assumes sequential reading,
> each term absolutely must be defined no later than its first use,
> because it will not be possible to jump to a later definition.

You don’t have to assume sequential reading. It’s usual in language specs to 
provide a reference for terms like that everywhere they occur outside their 
defining section, whether before or after.

> In practice, I don't think I have ever read a language specification the
> way one reads a novel, beginning at the first page and continuing
> sequentially to the end.

It’s how I do it the first time. Then later I come back to refer to things 
as I need them.

(Though I have to admit the Annotated Ada Reference Manual left me feeling 
like my brain had turned to mush. Maybe I’ll try the un-annotated version 
next time...)

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


#26058

FromArne Vajhøj <arne@vajhoej.dk>
Date2011-02-06 20:56 -0500
Message-ID<4d4f5131$0$23761$14726298@news.sunsite.dk>
In reply to#25808
On 06-02-2011 20:17, Lawrence D'Oliveiro wrote:
> In message<I8idncO4-e3h2tLQnZ2dnUVZ_oidnZ2d@earthlink.com>, Patricia
> Shanahan wrote:
>> This raises an interesting issue. If one assumes sequential reading,
>> each term absolutely must be defined no later than its first use,
>> because it will not be possible to jump to a later definition.
>
> You don’t have to assume sequential reading. It’s usual in language specs to
> provide a reference for terms like that everywhere they occur outside their
> defining section, whether before or after.

That is a good thing for paper versions.

But Java was born in the hypertext age.

Arne

[toc] | [prev] | [standalone]


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


csiph-web