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

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

multi-line Strings

Started bybob smith <bob@coolfone.comze.com>
First post2012-12-10 08:22 -0800
Last post2012-12-29 18:18 +0100
Articles 20 on this page of 146 — 22 participants

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

Contents

  multi-line Strings bob smith <bob@coolfone.comze.com> - 2012-12-10 08:22 -0800
    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 11:43 -0500
      Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:36 -0800
      Re: multi-line Strings markspace <-@.> - 2012-12-10 09:42 -0800
        Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-10 09:51 -0800
          Re: multi-line Strings markspace <-@.> - 2012-12-10 10:27 -0800
            Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 13:43 -0500
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 15:08 -0500
                Re: multi-line Strings markspace <-@.> - 2012-12-10 13:05 -0800
                Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 16:22 -0500
                  Re: multi-line Strings markspace <-@.> - 2012-12-10 13:36 -0800
                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 16:52 -0500
                    Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-10 18:04 -0500
                      Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 00:17 +0000
                        Re: multi-line Strings markspace <-@.> - 2012-12-10 17:35 -0800
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 01:56 +0000
                            Re: multi-line Strings markspace <-@.> - 2012-12-10 18:00 -0800
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:16 -0500
                                Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:21 +0000
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:12 -0600
                            Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-11 05:01 -0400
                              Re: multi-line Strings markspace <-@.> - 2012-12-11 09:46 -0800
                                Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:26 +0000
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 16:25 -0600
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:10 -0500
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:31 +0000
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:30 -0500
                              Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 03:35 -0600
                              Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 11:54 +0000
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-15 08:53 -0500
                                Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-16 12:19 -0700
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:24 +0000
                                Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:21 -0800
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 14:03 +0000
                                    Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:05 -0800
                                Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:13 -0400
                                  Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:38 +0000
                                    Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 19:48 -0400
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 21:07 -0500
                                  Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-19 08:26 -0600
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 16:36 -0500
                                      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 12:51 -0600
                                        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-21 14:05 -0600
                              Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-15 18:22 +0100
                                Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 00:34 +0100
                                  Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 02:56 -0600
                                    Re: multi-line Strings Robert Klemme <shortcutter@googlemail.com> - 2012-12-16 14:07 +0100
                                      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 13:44 -0600
                                  Re: multi-line Strings "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-12-16 17:43 +0100
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:37 -0500
                        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 22:03 -0600
                        Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-11 10:43 -0600
                          Re: multi-line Strings Martin Gregorie <martin@address-in-sig.invalid> - 2012-12-11 22:44 +0000
                      Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-10 21:09 -0500
        Re: multi-line Strings Sebastian <sebastian@undisclosed.invalid> - 2012-12-12 10:40 +0100
          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-12 20:28 -0500
      Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-10 13:42 -0600
    Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-11 07:58 +0100
      Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-11 10:08 -0500
        Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-11 09:41 -0600
        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 15:02 -0600
          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:27 -0500
          Re: multi-line Strings Joshua Cranmer <Pidgeot18@verizon.invalid> - 2012-12-14 23:23 -0600
            Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-15 02:56 -0600
      Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-11 16:31 -0500
        Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 17:07 -0600
          Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-11 15:31 -0800
            Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-11 19:41 -0600
        Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-13 07:43 +0100
          Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 23:09 -0800
          Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-13 06:34 -0400
            Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 07:35 +0100
              Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 02:44 -0600
                Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:48 +0100
                  Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:10 -0600
                  Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-14 15:18 -0800
                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:16 -0500
              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-14 05:55 -0400
                Re: multi-line Strings "William Bonawentura" <nie@ma.mnie.pl> - 2012-12-14 11:50 +0100
                  Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-14 05:12 -0600
                  Re: multi-line Strings Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-12-14 11:24 -0800
                    Re: multi-line Strings markspace <-@.> - 2012-12-14 11:47 -0800
                      Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:26 -0800
                        Re: multi-line Strings markspace <-@.> - 2012-12-14 12:53 -0800
                          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:36 -0500
                            Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-15 12:06 +0000
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:23 -0500
                            Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-15 08:16 -0600
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:24 -0500
                            Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:36 -0800
                          Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-16 17:36 -0800
                      Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-14 12:30 -0800
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:43 -0500
                      Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-14 17:36 -0500
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:46 -0500
                          Re: multi-line Strings BGB <cr88192@hotmail.com> - 2012-12-16 04:29 -0600
                      Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:45 -0400
                        Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 17:11 -0800
                          Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-17 20:25 -0500
                            Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 18:13 -0800
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 06:34 -0400
                                Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-18 10:54 -0800
                                  Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 18:57 -0400
                                    Re: multi-line Strings Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-18 20:02 -0500
                                      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-18 17:13 -0800
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:35 -0500
                                  Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 15:12 -0800
                                    Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-19 10:00 -0800
                                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:31 -0500
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:29 -0500
                                  Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 20:44 -0400
                                    Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 21:50 -0500
                                      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 23:15 -0800
                                      Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-20 06:00 -0400
                                  Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-20 08:56 -0800
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-19 19:33 -0500
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:43 -0500
                              Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-17 22:09 -0600
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:59 -0500
                              Re: multi-line Strings "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-12-18 13:22 +0000
                                Re: multi-line Strings Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-12-18 07:52 -0600
                                  Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:58 -0500
                                Re: multi-line Strings Gene Wirchenko <genew@telus.net> - 2012-12-18 09:10 -0800
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:56 -0500
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:05 -0400
                                Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:42 -0500
                            Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-17 22:18 -0700
                          Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:46 -0500
                            Re: multi-line Strings Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2012-12-17 21:01 -0800
                              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:46 -0500
                        Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-17 21:51 -0500
                          Re: multi-line Strings Patricia Shanahan <pats@acm.org> - 2012-12-17 19:41 -0800
                          Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-18 19:19 -0400
                            Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-18 20:50 -0500
                              Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-19 05:23 -0400
                                Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-19 13:25 -0800
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:14 -0500
            Re: multi-line Strings Jukka Lahtinen <jtfjdehf@hotmail.com.invalid> - 2012-12-14 23:43 +0200
              Re: multi-line Strings Arne Vajhøj <arne@vajhoej.dk> - 2012-12-14 22:20 -0500
                Re: multi-line Strings Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-17 20:47 -0400
    Re: multi-line Strings Jim Janney <jjanney@shell.xmission.com> - 2012-12-12 08:33 -0700
      Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-12 11:32 -0800
        Re: multi-line Strings markspace <-@.> - 2012-12-12 11:45 -0800
    Re: multi-line Strings Lew <lewbloch@gmail.com> - 2012-12-15 13:33 -0800
      Re: multi-line Strings Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-29 18:18 +0100

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#20257

FromBGB <cr88192@hotmail.com>
Date2012-12-11 15:02 -0600
Message-ID<ka876s$9ja$1@news.albasani.net>
In reply to#20250
On 12/11/2012 9:08 AM, Arne Vajhøj wrote:
> On 12/11/2012 1:58 AM, William Bonawentura wrote:
>> IMHO final code does not need to have any strings literals. Strings
>> should be allways created via out-of-code resources.
>
> In general yes.
>
> There are probably some exceptions. I would not want Java keywords to
> come from an external resource for a Java compiler.
>
> :-)
>

IMO, about the only things (strings-wise) which really make sense being 
moved into external resources are:
default configuration options (debatable, if the config file will 
override them anyways);
(potentially) messages intended for human readers or similar (say, to 
allow language-specific translations or similar).


if the bulk of the string literals are things internal to the program 
(rather than intended for an end user), then it makes little sense to 
move them to external resources (IME, most string literals tend to be 
program internal anyways, with human-readable messages few and far 
between, and most of these in-turn being internal debugging messages).

with user-readable strings, the program could still be developed under a 
policy like "if you need the messages in a language you can read, either 
learn English (or Japanese or Chinese or similar) or get a dictionary", 
so making them external may not make much sense in this case.


even with language-specific strings, unless using magic numbers, a 
string may still be needed to refer to them.

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

#20342

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-14 22:27 -0500
Message-ID<50cbee2f$0$291$14726298@news.sunsite.dk>
In reply to#20257
On 12/11/2012 4:02 PM, BGB wrote:
> On 12/11/2012 9:08 AM, Arne Vajhøj wrote:
>> On 12/11/2012 1:58 AM, William Bonawentura wrote:
>>> IMHO final code does not need to have any strings literals. Strings
>>> should be allways created via out-of-code resources.
>>
>> In general yes.
>>
>> There are probably some exceptions. I would not want Java keywords to
>> come from an external resource for a Java compiler.
>>
>> :-)
>
> IMO, about the only things (strings-wise) which really make sense being
> moved into external resources are:
> default configuration options (debatable, if the config file will
> override them anyways);
> (potentially) messages intended for human readers or similar (say, to
> allow language-specific translations or similar).

I18N and CMS and templates are some pretty big cases.

> if the bulk of the string literals are things internal to the program
> (rather than intended for an end user), then it makes little sense to
> move them to external resources (IME, most string literals tend to be
> program internal anyways, with human-readable messages few and far
> between, and most of these in-turn being internal debugging messages).

Even for internal usage, then reading text from external resources
due to the less testing required after a change.

And considering human-readable messages to be "few and far between"
seems pretty far from reality to me.

> with user-readable strings, the program could still be developed under a
> policy like "if you need the messages in a language you can read, either
> learn English (or Japanese or Chinese or similar) or get a dictionary",
> so making them external may not make much sense in this case.

That may not be good business.

> even with language-specific strings, unless using magic numbers, a
> string may still be needed to refer to them.

Of course.

Arne

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

#20348

FromJoshua Cranmer <Pidgeot18@verizon.invalid>
Date2012-12-14 23:23 -0600
Message-ID<kah1hp$678$1@dont-email.me>
In reply to#20257
On 12/11/2012 3:02 PM, BGB wrote:
> if the bulk of the string literals are things internal to the program
> (rather than intended for an end user), then it makes little sense to
> move them to external resources (IME, most string literals tend to be
> program internal anyways, with human-readable messages few and far
> between, and most of these in-turn being internal debugging messages).

You must not work with large user-facing applications then. :-) My 
practice is very nearly the opposite--most string literals are either 
involved with debugging to log files, keys to preferences/other 
configuration, or keys to human readable messages. The latter two 
classes are things that tend to be grouped outside of the program itself 
for simple reasons of reducing management complexity (Clang even uses an 
external file for its command line arguments, kind of [1], despite not 
doing any localization of strings).

> with user-readable strings, the program could still be developed under a
> policy like "if you need the messages in a language you can read, either
> learn English (or Japanese or Chinese or similar) or get a dictionary",
> so making them external may not make much sense in this case.

Even if you don't need to provide translated messages, there is benefit 
to centralizing program messages in external files. Ensuring consistency 
is one key benefit that I can think of.

> even with language-specific strings, unless using magic numbers, a
> string may still be needed to refer to them.

And a constant String is often used instead of copy-pasting the literal 
around.

[1] The "kind of" is that this is turned into compiled code by a build step.

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

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

#20350

FromBGB <cr88192@hotmail.com>
Date2012-12-15 02:56 -0600
Message-ID<kahe48$5vk$1@news.albasani.net>
In reply to#20348
On 12/14/2012 11:23 PM, Joshua Cranmer wrote:
> On 12/11/2012 3:02 PM, BGB wrote:
>> if the bulk of the string literals are things internal to the program
>> (rather than intended for an end user), then it makes little sense to
>> move them to external resources (IME, most string literals tend to be
>> program internal anyways, with human-readable messages few and far
>> between, and most of these in-turn being internal debugging messages).
>
> You must not work with large user-facing applications then. :-) My
> practice is very nearly the opposite--most string literals are either
> involved with debugging to log files, keys to preferences/other
> configuration, or keys to human readable messages. The latter two
> classes are things that tend to be grouped outside of the program itself
> for simple reasons of reducing management complexity (Clang even uses an
> external file for its command line arguments, kind of [1], despite not
> doing any localization of strings).
>

I am mostly working on 3D stuff... (mostly a game, but also some 3D 
tools, ...).

its "user facing" side is mostly the 3D renderer, sound mixing, and 
user-input handling (mouse, keyboard actions, keyboard shortcuts, ...).

text isn't really a big part of the normal experience, nor much 
information presented as natural-language text (there is a fair amount 
more in terms of variables and formatted numerical output, but this 
isn't really the same).


most of the code in the project, however, is internal infrastructural 
code, most not really having much direct user interaction.


basically, it is a project which is slightly over 1 Mloc (1 million 
lines of code). a few of the bigger chunks here are mostly stuff related 
to my scripting language, and also the 3D renderer. together, they make 
up a large percentage of the total codebase, followed roughly by the 
"server end" in 3rd place (the server-end is what holds most of the 
"gameplay logic", like physics code, weapons and items logic, enemy-AI 
logic / behaviors, and so on...).


currently, there is very little in terms of a GUI (traditional GUI 
elements are almost completely absent from the program).

there is an interactive console though, which mostly functions in a 
manner vaguely similar to the Linux shell interface though (type 
commands, see results). typically, commands are terse names, and don't 
usually generate much printed output. these commands are implemented 
in-program, and operate in terms of a program-local virtual-filesystem. 
where relevant, commands have similar names and behaviors to their Linux 
analogues (cd, ls, cat, pwd, ...). (there is little obvious reason 
though why anyone would want to change these though, like 'cd' or 'ls' 
should probably be fairly universal independent of language?...).

there is an in-program text-editor though, which provides an interface 
partway between MS-Edit and Vim (cosmetically, it looks a little more 
like MS-Edit, but handles user input in many ways a little more like 
Vim, with ALT-';' switching to the command-entry prompt, ...).

some parts of the engine are controlled by "cvars" though, which 
function in a manner vaguely similar to environment variables.


or, IOW, there is lots of stuff going on, and lots of stuff for the user 
to interact with, just relatively little where textual feedback is 
really called for (at least much beyond debug messages). (and, 
presumably, normal users/players shouldn't normally be messing around in 
the console anyways, apart from maybe to enter cheat-codes).


>> with user-readable strings, the program could still be developed under a
>> policy like "if you need the messages in a language you can read, either
>> learn English (or Japanese or Chinese or similar) or get a dictionary",
>> so making them external may not make much sense in this case.
>
> Even if you don't need to provide translated messages, there is benefit
> to centralizing program messages in external files. Ensuring consistency
> is one key benefit that I can think of.
>

could be, but it doesn't really tend to be a big use case.
most of what is printed, is usually an indication of where the message 
is being printed from (function/method names and similar), and a terse 
description of the event, and usually a few items giving the values of 
relevant arguments or variables.

given most of this isn't really intended for end users, it doesn't 
really make much sense for translation.

granted, a person could translate any voice-acted dialogue, which would 
probably be a bigger use-case for translation I think, but at the 
moment, there isn't a whole lot of this either (that is actually 
relevant to gameplay).


>> even with language-specific strings, unless using magic numbers, a
>> string may still be needed to refer to them.
>
> And a constant String is often used instead of copy-pasting the literal
> around.
>
> [1] The "kind of" is that this is turned into compiled code by a build
> step.
>

could be, depends on whether the literal is one-off, or used more than 
once...

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

#20258

FromEric Sosman <esosman@comcast-dot-net.invalid>
Date2012-12-11 16:31 -0500
Message-ID<ka88nr$128$1@dont-email.me>
In reply to#20247
On 12/11/2012 1:58 AM, William Bonawentura wrote:
> IMHO final code does not need to have any strings literals. Strings
> should be allways created via out-of-code resources.

	String message1 =
	    readFromURL(Thing.class.getResource("message1"));
	// Code reviewer vetoes the in-line literal, so ...

	String message1 =
	    readFromURL(Thing.class.getResource(
	        readFromURL(Thing.class.getResource(
	            "name_of_message1"))));
	// Code reviewer vetoes the in-line literal, so ...

	String message1 =
	    readFromURL(Thing.class.getResource(
	        readFromUrl(Thing.class.getResource(
	            readFromUrl(Thing.class.getResource(
	                "name_of_name_of_message1"))))));
	// Code reviewer vetoes the in-line literal, and
	// gets badly mauled by fed-up programmer.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

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

#20264

FromBGB <cr88192@hotmail.com>
Date2012-12-11 17:07 -0600
Message-ID<ka8ege$o85$1@news.albasani.net>
In reply to#20258
On 12/11/2012 3:31 PM, Eric Sosman wrote:
> On 12/11/2012 1:58 AM, William Bonawentura wrote:
>> IMHO final code does not need to have any strings literals. Strings
>> should be allways created via out-of-code resources.
>
>      String message1 =
>          readFromURL(Thing.class.getResource("message1"));
>      // Code reviewer vetoes the in-line literal, so ...
>
>      String message1 =
>          readFromURL(Thing.class.getResource(
>              readFromURL(Thing.class.getResource(
>                  "name_of_message1"))));
>      // Code reviewer vetoes the in-line literal, so ...
>
>      String message1 =
>          readFromURL(Thing.class.getResource(
>              readFromUrl(Thing.class.getResource(
>                  readFromUrl(Thing.class.getResource(
>                      "name_of_name_of_message1"))))));
>      // Code reviewer vetoes the in-line literal, and
>      // gets badly mauled by fed-up programmer.
>

       String message1 =
           readFromURL(Thing.class.getResource(
		new String(new char[]
			{ 'm', 'e', 's', 's', 'a', 'g', 'e', '1' } )));

but, yeah, banning string literals would be stupid...

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

#20265

FromPeter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>
Date2012-12-11 15:31 -0800
Message-ID<1pvw1ur9xgeke$.wdqso0m84fyy$.dlg@40tude.net>
In reply to#20264
On Tue, 11 Dec 2012 17:07:05 -0600, BGB wrote:

> [...]
> but, yeah, banning string literals would be stupid...

That said, I think there's a good argument for insisting that most if not
all string literals be declared as constants (e.g. final fields in the
class or a separate static class), rather than being found inline with the
code.

You don't get out of having string literals, but at least they are in a
centralized place or places, and when the same value is required in
multiple places, changes to the value or refactorings of the code are
simplified in this way.

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

#20266

FromBGB <cr88192@hotmail.com>
Date2012-12-11 19:41 -0600
Message-ID<ka8nih$5ha$1@news.albasani.net>
In reply to#20265
On 12/11/2012 5:31 PM, Peter Duniho wrote:
> On Tue, 11 Dec 2012 17:07:05 -0600, BGB wrote:
>
>> [...]
>> but, yeah, banning string literals would be stupid...
>
> That said, I think there's a good argument for insisting that most if not
> all string literals be declared as constants (e.g. final fields in the
> class or a separate static class), rather than being found inline with the
> code.
>
> You don't get out of having string literals, but at least they are in a
> centralized place or places, and when the same value is required in
> multiple places, changes to the value or refactorings of the code are
> simplified in this way.
>

yep, this makes sense...

it is along similar lines though to the avoidance of "magic values" 
being declared inline in code.

sometimes, a value makes more sense as a constant variable, and people 
will declare it as such. other times, it does not, and will typically be 
left inline.


IMO, all this isn't really an area tools should get involved with 
enforcing though, since tools can't really know whether or not something 
"makes sense", they will just uniformly enforce various rules whether or 
not they make sense in a given situation.

sort of like life in general I guess...

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

#20287

From"William Bonawentura" <nie@ma.mnie.pl>
Date2012-12-13 07:43 +0100
Message-ID<kabtes$76d$1@news2.ipartners.pl>
In reply to#20258
> String message1 = readFromURL(Thing.class.getResource("message1"));
> Eric Sosman

Uggly. Untestable in build-time. Consider something like this:


@Inject
@Resource( "message1" )
private String message1;

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

#20289

FromLew <lewbloch@gmail.com>
Date2012-12-12 23:09 -0800
Message-ID<bf2c9828-907b-407c-9a52-575adb97c3cd@googlegroups.com>
In reply to#20287
William Bonawentura wrote:
> Consider something like this:
> 
> @Inject
> @Resource( "message1" )
> private String message1;

Works a treat.

I recently had occasion to work up an annotation to cover some ugly, 
testable but twisted reflective code.

Writing the annotation gave multiple advantage, many quite unforeseen.

- Boilerplate code vanishes from annotated call sites.
- Leaving behind short, easy-to-comprehend routines.
- DRY - all the magic moves into one class that handles the annoation.
- Since you're in ReflectionLand anyway, you get a lot of data for logging calls.
- Orthogonal treatment - other code and tooling can use the same annotations
   in novel ways with zero influence on existing consumers.
- Annotations contribute to self-documentation at least as much as boilerplate 
   detracts, squaring the benefit to code literacy.
- Adding modules to the system using the same annotation is super easy.
- When another programmer returned from leave, they were able to jump right 
   in and add another module the same day, leveraging the annotation.

JPA annotations are a good example of some of those bullet points.

Even though in this particular case I was one of the main proponents of the 
annotation approach, I am still stunned at how well it worked. 

Oh, that brings up another benefit. Intra-team communication around implementations
using the annotation is accelerated. It's largely because with an annotation there's 
nothing to talk about once you've developed it. I had to explain the boilerplate a lot, 
which is part of what led to writing the annotation. No one yet has needed an explanation 
of the annotation beyond how its 'value' attribute connects it to the rest of our 
lattice, and that but once.

-- 
Lew

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

#20290

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-13 06:34 -0400
Message-ID<Uaiys.16310$sm1.15526@newsfe22.iad>
In reply to#20287
On 12/13/2012 02:43 AM, William Bonawentura wrote:
>> String message1 = readFromURL(Thing.class.getResource("message1"));
>> Eric Sosman
>
> Uggly. Untestable in build-time. Consider something like this:
>
>
> @Inject
> @Resource( "message1" )
> private String message1;
>
You missed Eric's point. You stipulated a rule - "final code does not 
need to have any strings literals. Strings should be always created via 
out-of-code resources". You just now broke your own rule with your 
annotation example; the absurdity of your rule is what Eric was trying 
to illustrate.

AHS

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

#20317

From"William Bonawentura" <nie@ma.mnie.pl>
Date2012-12-14 07:35 +0100
Message-ID<kaehb9$1fmn$1@news2.ipartners.pl>
In reply to#20290
> Strings should be always created via out-of-code resources".
> You just now broke your own rule with your annotation example;

String literal inside annotation is not equal to literal inside code. It is like static constans - you can read it on code-buld 
phase ex. by Annotation Processor.

> the absurdity of your rule is what Eric was trying to illustrate.

There is good a "rule of life" :). Never create literals in the code.

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

#20319

FromLeif Roar Moldskred <leifm@dimnakorr.com>
Date2012-12-14 02:44 -0600
Message-ID<ZN2dnTd3vpdre1fNnZ2dnUVZ8h-dnZ2d@giganews.com>
In reply to#20317
William Bonawentura <nie@ma.mnie.pl> wrote:
> 
> There is good a "rule of life" :). Never create literals in the code.

Then how would you do the following?

public boolean isGetMethodName( String methodName ) {
  return methodName.length() > 3 &&
         methodName.startsWith( "get" ) &&
         isUpperCaseLetter( methodName.charAt( 3 )
}

I mean, sure, you cold declare a constant GET_METHOD_PREFIX and use
that in place of "get", but that's just adding pointless indirection
for no good reason.

-- 
Leif Roar Moldskred

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

#20322

From"William Bonawentura" <nie@ma.mnie.pl>
Date2012-12-14 11:48 +0100
Message-ID<kaf06k$1mqh$1@news2.ipartners.pl>
In reply to#20319
> Then how would you do the following?
> public boolean isGetMethodName( String methodName ) {

It seems to me, that isGetMethodName is a internal part of reflecion-based library. Not a final / business / application code.

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

#20324

FromLeif Roar Moldskred <leifm@dimnakorr.com>
Date2012-12-14 05:10 -0600
Message-ID<946dneUU4IaulFbNnZ2dnUVZ7sadnZ2d@giganews.com>
In reply to#20322
William Bonawentura <nie@ma.mnie.pl> wrote:
>
> It seems to me, that isGetMethodName is a internal part of
>  reflecion-based library. Not a final / business / application code.

That's the first time _that_ distinction has been mentioned in
relation to the discussion. 

However, it's easy enough to imagine similar situations occuring in
business code:

public boolean isEduDomain( String emailAddress ) {
  return emailAddress.toLowerCase().endsWith( ".edu" );
}

-- 
Leif Roar Moldskred

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

#20335

FromLew <lewbloch@gmail.com>
Date2012-12-14 15:18 -0800
Message-ID<2991dbe6-9c56-4ecc-9f08-6c561933c1b2@googlegroups.com>
In reply to#20322
William Bonawentura forgot to attribute:
>> Then how would you do the following?
>> public boolean isGetMethodName( String methodName ) {

then wrote:
> It seems to me, that isGetMethodName is a internal part of reflecion-based library. Not a final / business / application code.

How blazingly irrelevant, and an example of the "No True Scotsman" fallacy.

-- 
Lew

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

#20340

FromArne Vajhøj <arne@vajhoej.dk>
Date2012-12-14 22:16 -0500
Message-ID<50cbeba7$0$291$14726298@news.sunsite.dk>
In reply to#20322
On 12/14/2012 5:48 AM, William Bonawentura wrote:
>> Then how would you do the following?
>> public boolean isGetMethodName( String methodName ) {
>
> It seems to me, that isGetMethodName is a internal part of
> reflecion-based library. Not a final / business / application code.

First. You just talked about "code" not this subset of code.

Second. Even with that subset of code it is not true.

Arne

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

#20320

FromArved Sandstrom <asandstrom2@eastlink.ca>
Date2012-12-14 05:55 -0400
Message-ID<lICys.64314$2v.59843@newsfe05.iad>
In reply to#20317
On 12/14/2012 02:35 AM, William Bonawentura wrote:
>
>> Strings should be always created via out-of-code resources".
>> You just now broke your own rule with your annotation example;
>
> String literal inside annotation is not equal to literal inside code. It
> is like static constans - you can read it on code-buld phase ex. by
> Annotation Processor.
>
>> the absurdity of your rule is what Eric was trying to illustrate.
>
> There is good a "rule of life" :). Never create literals in the code.

It's *all* code, William. As far as I am concerned, every single byte of 
a *.java source file is code. Annotations absolutely are code, they are 
also instructions to the computer.

AHS

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

#20323

From"William Bonawentura" <nie@ma.mnie.pl>
Date2012-12-14 11:50 +0100
Message-ID<kaf0ak$1mrb$1@news2.ipartners.pl>
In reply to#20320
> It's *all* code, William. As far as I am concerned, every single byte of a *.java source file is code. Annotations absolutely are 
> code, they are also instructions to the computer.

OK. Refine:

You should never create runtime computed literals inside your business code.

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

#20325

FromLeif Roar Moldskred <leifm@dimnakorr.com>
Date2012-12-14 05:12 -0600
Message-ID<946dneQU4IY1lFbNnZ2dnUVZ7sadnZ2d@giganews.com>
In reply to#20323
William Bonawentura <nie@ma.mnie.pl> wrote:
> 
> OK. Refine:
> 
> You should never create runtime computed literals inside your business code. 
> 

What do you mean with "computed literals" here? The term seems like a
contradiction in terms to me.

-- 
Leif Roar Moldskred

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

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

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

csiph-web