Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > multi-line Strings

Reply
Thread Tools

multi-line Strings

 
 
BGB
Guest
Posts: n/a
 
      12-12-2012
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...


 
Reply With Quote
 
 
 
 
Sebastian
Guest
Posts: n/a
 
      12-12-2012
On 12/10/2012 8:43 AM, Arne Vajh°j wrote:
>
> It could be added....
>
> But I would not consider it a high priority.
>
> It is most useful for demo code.
>
> For real code then large chunks of texts would usually
> be stored externally (file, DB etc.) not embedded into
> the code.


I think nobody has mentioned this funny little hack, which just
might be suitable for demo code and unit tests. It requires that the
source code using the multi-line string be accessible in the file
system at run time.

http://blog.efftinge.de/2008/10/mult...s-in-java.html

I do believe the blog was posted in a humorous spirit.

-- Sebastian

 
Reply With Quote
 
 
 
 
Jim Janney
Guest
Posts: n/a
 
      12-12-2012
bob smith <(E-Mail Removed)> writes:

> Should something be added to the Java language to make multi-line Strings more clear?
>
> Maybe like what PHP has?
>
> Right now, I have a mess like this:
>


You could always write something like

private final String mLomoishShader = multiline(
"precision mediump float;",
"uniform sampler2D tex_sampler_0;",
"uniform vec2 seed;",
....
" float dist = length(coord * scale);",
" float lumen = 0.85 / (1.0 + exp((dist * inv_max_dist - 0.73) * 20.0)) + 0.15;",
" gl_FragColor = vec4(bw_color * lumen, color.a);",
"}");


private static String multiline(String... lines) {
// left as an exercise for the reader
}

--
Jim Janney
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-12-2012
Jim Janney wrote:
> bob smith writes:
>> Should something be added to the Java language to make multi-line Strings more clear?
>> Maybe like what PHP has?
>> Right now, I have a mess like this:

>
> You could always write something like
>
> private final String mLomoishShader = multiline(
> "precision mediump float;",
> "uniform sampler2D tex_sampler_0;",
> "uniform vec2 seed;",
> ...
> " float dist = length(coord * scale);",
> " float lumen = 0.85 / (1.0 + exp((dist * inv_max_dist - 0.73) * 20.0)) + 0.15;",
> " gl_FragColor = vec4(bw_color * lumen, color.a);",
> "}");
>
> private static String multiline(String... lines) {
> // left as an exercise for the reader
> }


Interesting idea, modeling a multi-element thing as a multi-element thing.

Hardly seems less advantageous than the proposed new syntax, and evitates the
Gorgon Language Change.

--
Lew

 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      12-12-2012
On 12/12/2012 11:32 AM, Lew wrote:
>
> Interesting idea, modeling a multi-element thing as a multi-element thing.
>
> Hardly seems less advantageous than the proposed new syntax, and evitates the
> Gorgon Language Change.


The disadvantage to this method is his method, multiline(), has to
assemble the string at runtime, and also has to make some assumptions
about what style of newline to use.

Whereas static strings are just that: static, don't need assembly, and
the programmer specifies the newline character(s) directly.


 
Reply With Quote
 
Arne Vajh°j
Guest
Posts: n/a
 
      12-13-2012
On 12/12/2012 4:40 AM, Sebastian wrote:
> On 12/10/2012 8:43 AM, Arne Vajh°j wrote:
>>
>> It could be added....
>>
>> But I would not consider it a high priority.
>>
>> It is most useful for demo code.
>>
>> For real code then large chunks of texts would usually
>> be stored externally (file, DB etc.) not embedded into
>> the code.

>
> I think nobody has mentioned this funny little hack, which just
> might be suitable for demo code and unit tests. It requires that the
> source code using the multi-line string be accessible in the file
> system at run time.
>
> http://blog.efftinge.de/2008/10/mult...s-in-java.html
>
> I do believe the blog was posted in a humorous spirit.


Well - it is funny and not very practical (think more
than one such string), so that seems very plausible.

Arne


 
Reply With Quote
 
William Bonawentura
Guest
Posts: n/a
 
      12-13-2012
> String message1 = readFromURL(Thing.class.getResource("message1"));
> Eric Sosman


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


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



 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      12-13-2012
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
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      12-13-2012
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

 
Reply With Quote
 
William Bonawentura
Guest
Posts: n/a
 
      12-14-2012

> 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.



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Strings, Strings and Damned Strings Ben C Programming 14 06-24-2006 05:09 AM
How to generate k+1 length strings from a list of k length strings? Girish Sahani Python 17 06-09-2006 11:01 AM
Catching std::strings and c-style strings at once Kurt Krueckeberg C++ 2 11-17-2004 03:53 AM
convert list of strings to set of regexes; convert list of strings to trie Klaus Neuner Python 7 07-26-2004 07:25 AM
Comparing strings from within strings Rick C Programming 3 10-21-2003 09:10 AM



Advertisments