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


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

Re: Type conversions with the empty string

Started byKnute Johnson <nospam@rabbitbrush.frazmtn.com>
First post2017-01-30 11:34 -0600
Last post2017-02-13 12:50 -0500
Articles 6 — 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: Type conversions with the empty string Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-01-30 11:34 -0600
    Re: Type conversions with the empty string Knute Johnson <nospam@rabbitbrush.frazmtn.com> - 2017-01-30 12:25 -0600
    Re: Type conversions with the empty string Eric Douglas <e.d.programmer@gmail.com> - 2017-01-30 10:58 -0800
    Re: Type conversions with the empty string Arne Vajhøj <arne@vajhoej.dk> - 2017-01-30 21:29 -0500
      Re: Type conversions with the empty string Robert Klemme <shortcutter@googlemail.com> - 2017-02-01 00:01 +0100
        Re: Type conversions with the empty string Arne Vajhøj <arne@vajhoej.dk> - 2017-02-13 12:50 -0500

#36225 — Re: Type conversions with the empty string

FromKnute Johnson <nospam@rabbitbrush.frazmtn.com>
Date2017-01-30 11:34 -0600
SubjectRe: Type conversions with the empty string
Message-ID<o6ntbt$qko$1@dont-email.me>
On 1/28/2017 07:43, Stefan Ram wrote:
>   There are actually two ways to convert »123« to a string
>   that both involve the empty string:
>
> ""+123
>
>   and
>
> "".valueOf( 123 )
>
>   , and both are frowned upon! But real problems in software
>   enginnering involve architecture or "logical" errors, seldom
>   small-scale wordings. What is the worst thing that could
>   happen when someone uses one of those? (That a beginner reading
>   the source might become confused?)
>
>   I'd say that
>
> "".valueOf( 123 )
>
>   is even more robust than
>
> String.valueOf( 123 )
>
>   because the former is still working when a file »String.class«
>   is found early enough in the class path.
>

You would prefer any of those over Integer.toString(123)?

-- 

Knute Johnson

[toc] | [next] | [standalone]


#36227

FromKnute Johnson <nospam@rabbitbrush.frazmtn.com>
Date2017-01-30 12:25 -0600
Message-ID<o6o0c5$8f7$1@dont-email.me>
In reply to#36225
On 1/30/2017 12:08, Stefan Ram wrote:
> Knute Johnson <nospam@rabbitbrush.frazmtn.com> writes:
>> On 1/28/2017 07:43, Stefan Ram wrote:
>>> String.valueOf( 123 )
>> You would prefer any of those over Integer.toString(123)?
>
>   »java.lang.String.valueOf« is the universal one-stop
>   solution to convert anything into a string, including
>   primitive values, class instances and even null! So it
>   does not make me think. Whenever I want to convert anthing
>   into a »java.lang.String« instance, I use this.

I can see that.  I see it as I have an int and I want to convert it to a 
String but your way makes sense too.

>   »java.lang.Integer.toString« makes me thing about the type
>   of »123« and what the wrapper class of that type is, and
>   whether it really has such a method (for example, the static
>   »java.lang.Boolean.toString« method is only @since 1.4,
>   while »java.lang.Integer.toString« is @since 1.0.)
>

I don't know, 1.4 started end of life over 10 years ago.  I'm not too 
concerned about that.

-- 

Knute Johnson

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


#36228

FromEric Douglas <e.d.programmer@gmail.com>
Date2017-01-30 10:58 -0800
Message-ID<8cc8f86d-8fe9-45bd-8b94-5af5874c2c49@googlegroups.com>
In reply to#36225
On Monday, January 30, 2017 at 12:34:36 PM UTC-5, Knute Johnson wrote:
> 
> You would prefer any of those over Integer.toString(123)?
> 
> -- 
> 
> Knute Johnson

I would most likely choose String.valueOf() to convert a number, and I'd call anyone an idiot who named their own custom class the same as an Oracle class.
I gave all the classes in my custom API custom names, all starting with BB followed by a letter. The letter is a for abstracts, g for GUI objects, i for interfaces, s for statics, etc.

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


#36232

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-01-30 21:29 -0500
Message-ID<o6ospr$1vpf$2@gioia.aioe.org>
In reply to#36225
On 1/30/2017 1:08 PM, Stefan Ram wrote:
> Knute Johnson <nospam@rabbitbrush.frazmtn.com> writes:
>> On 1/28/2017 07:43, Stefan Ram wrote:
>>> String.valueOf( 123 )
>> You would prefer any of those over Integer.toString(123)?
>
>   »java.lang.String.valueOf« is the universal one-stop
>   solution to convert anything into a string, including
>   primitive values, class instances and even null! So it
>   does not make me think. Whenever I want to convert anthing
>   into a »java.lang.String« instance, I use this.
>
>   »java.lang.Integer.toString« makes me thing about the type
>   of »123« and what the wrapper class of that type is, and
>   whether it really has such a method (for example, the static
>   »java.lang.Boolean.toString« method is only @since 1.4,
>   while »java.lang.Integer.toString« is @since 1.0.)

Well - some actually like that type strictness. Including me.

If something should be an int, then I prefer a compile time
error if it suddenly is not an int any longer.

Arne

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


#36237

FromRobert Klemme <shortcutter@googlemail.com>
Date2017-02-01 00:01 +0100
Message-ID<efcjatFc5t5U1@mid.individual.net>
In reply to#36232
On 31.01.2017 03:29, Arne Vajhøj wrote:
> On 1/30/2017 1:08 PM, Stefan Ram wrote:
>> Knute Johnson <nospam@rabbitbrush.frazmtn.com> writes:
>>> On 1/28/2017 07:43, Stefan Ram wrote:
>>>> String.valueOf( 123 )
>>> You would prefer any of those over Integer.toString(123)?
>>
>>   »java.lang.String.valueOf« is the universal one-stop
>>   solution to convert anything into a string, including
>>   primitive values, class instances and even null! So it
>>   does not make me think. Whenever I want to convert anthing
>>   into a »java.lang.String« instance, I use this.
>>
>>   »java.lang.Integer.toString« makes me thing about the type
>>   of »123« and what the wrapper class of that type is, and
>>   whether it really has such a method (for example, the static
>>   »java.lang.Boolean.toString« method is only @since 1.4,
>>   while »java.lang.Integer.toString« is @since 1.0.)
>
> Well - some actually like that type strictness. Including me.
>
> If something should be an int, then I prefer a compile time
> error if it suddenly is not an int any longer.

Yes, but that would likely already be triggered by something more int 
specific, e.g. an assignment or another method calls that needs to do 
calculations with the value.  For me, in this case also the Stefan's 
argument wins - especially since this is an "uncontrolled" (as opposed 
to using a format) conversion to String.

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

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


#36253

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-02-13 12:50 -0500
Message-ID<o7srka$164a$1@gioia.aioe.org>
In reply to#36237
On 1/31/2017 6:01 PM, Robert Klemme wrote:
> On 31.01.2017 03:29, Arne Vajhøj wrote:
>> On 1/30/2017 1:08 PM, Stefan Ram wrote:
>>> Knute Johnson <nospam@rabbitbrush.frazmtn.com> writes:
>>>> On 1/28/2017 07:43, Stefan Ram wrote:
>>>>> String.valueOf( 123 )
>>>> You would prefer any of those over Integer.toString(123)?
>>>
>>>   »java.lang.String.valueOf« is the universal one-stop
>>>   solution to convert anything into a string, including
>>>   primitive values, class instances and even null! So it
>>>   does not make me think. Whenever I want to convert anthing
>>>   into a »java.lang.String« instance, I use this.
>>>
>>>   »java.lang.Integer.toString« makes me thing about the type
>>>   of »123« and what the wrapper class of that type is, and
>>>   whether it really has such a method (for example, the static
>>>   »java.lang.Boolean.toString« method is only @since 1.4,
>>>   while »java.lang.Integer.toString« is @since 1.0.)
>>
>> Well - some actually like that type strictness. Including me.
>>
>> If something should be an int, then I prefer a compile time
>> error if it suddenly is not an int any longer.
>
> Yes, but that would likely already be triggered by something more int
> specific, e.g. an assignment or another method calls that needs to do
> calculations with the value.

Maybe. Maybe not.

I don't mind double checking.

Arne

[toc] | [prev] | [standalone]


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


csiph-web