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

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

Overloading methods question

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

Contents

  Overloading methods question Rhino <no_offline_contact@example.com> - 2018-10-24 17:04 -0400
    Re: Overloading methods question Arne Vajhøj <arne@vajhoej.dk> - 2018-10-24 18:56 -0400
    Re: Overloading methods question Joerg Meier <joergmmeier@arcor.de> - 2018-10-25 10:13 +0200
      Re: Overloading methods question Rhino <no_offline_contact@example.com> - 2018-10-25 15:53 -0400
        Re: Overloading methods question Eric Douglas <e.d.programmer@gmail.com> - 2018-10-25 13:58 -0700
          Re: Overloading methods question Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-10-25 17:49 -0400
            Re: Overloading methods question Martin Gregorie <martin@mydomain.invalid> - 2018-10-25 22:29 +0000
              Re: Overloading methods question Arne Vajhøj <arne@vajhoej.dk> - 2018-10-25 20:08 -0400
                Re: Overloading methods question Martin Gregorie <martin@mydomain.invalid> - 2018-10-26 00:37 +0000
                  Re: Overloading methods question Arne Vajhøj <arne@vajhoej.dk> - 2018-10-25 21:42 -0400
                  Re: Overloading methods question Joerg Meier <joergmmeier@arcor.de> - 2018-10-26 12:46 +0200
                  Re: Overloading methods question Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-10-26 07:50 -0400
                    Re: Overloading methods question Martin Gregorie <martin@mydomain.invalid> - 2018-10-26 19:33 +0000
                      Re: Overloading methods question Eric Douglas <e.d.programmer@gmail.com> - 2018-10-26 13:13 -0700
                      Re: Overloading methods question Arne Vajhøj <arne@vajhoej.dk> - 2018-10-26 20:58 -0400
                        Re: Overloading methods question Martin Gregorie <martin@mydomain.invalid> - 2018-10-27 22:36 +0000
                          Re: Overloading methods question Arne Vajhøj <arne@vajhoej.dk> - 2018-10-27 19:38 -0400
                            Re: Overloading methods question Martin Gregorie <martin@mydomain.invalid> - 2018-10-28 10:39 +0000
                              Re: Overloading methods question Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-10-28 07:54 -0400
            Re: Overloading methods question Eric Douglas <e.d.programmer@gmail.com> - 2018-10-26 06:26 -0700
        Re: Overloading methods question Joerg Meier <joergmmeier@arcor.de> - 2018-10-26 12:52 +0200
          Re: Overloading methods question Rhino <no_offline_contact@example.com> - 2018-10-26 22:10 -0400
            Re: Overloading methods question Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-10-27 07:43 -0400
              Re: Overloading methods question Rhino <no_offline_contact@example.com> - 2018-10-29 14:40 -0400
                Re: Overloading methods question Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-10-29 16:39 -0400
            Re: Overloading methods question Eric Douglas <e.d.programmer@gmail.com> - 2018-10-29 05:07 -0700
              Re: Overloading methods question Rhino <no_offline_contact@example.com> - 2018-10-29 14:41 -0400
    Re: Overloading methods question Eric Sosman <esosman@comcast-dot-net.invalid> - 2018-10-25 07:49 -0400
      Re: Overloading methods question Rhino <no_offline_contact@example.com> - 2018-10-25 16:07 -0400

Page 2 of 2 — ← Prev page 1 [2]

#38659

On Thu, 25 Oct 2018 15:53:04 -0400, Rhino wrote:

> Or did you have something different in mind?

Basically, that is what I had in mind, although two improvements:

> LocalDateTime ldt = LocalDateTime.now();
> ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.systemDefault());

LocalDateTime.now() is already returned in the system default time zone. So
you could rephrase this:

> String fullMonthName = 
> CurrentDateTimeUtils.getCurrentMonth().getDisplayName(

as:

> LocalDateTime.now().getMonth().getDisplayName(

which aside of saving you from having a method is actually even shorter
than calling the method ;)

Liebe Gruesse,
		Joerg

-- 
"Immer wieder erstaunlich, wie lächerlich man sich doch machen kann und
sich dabei noch toll finden." 
                        - Hartmut Kraus, 19.3.2017 in de.soc.recht.misc

Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.

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

#38665

On 2018-10-26 6:52 AM, Joerg Meier wrote:
> On Thu, 25 Oct 2018 15:53:04 -0400, Rhino wrote:
> 
>> Or did you have something different in mind?
> 
> Basically, that is what I had in mind, although two improvements:
> 
>> LocalDateTime ldt = LocalDateTime.now();
>> ZonedDateTime zdt = ZonedDateTime.of(ldt, ZoneId.systemDefault());
> 
> LocalDateTime.now() is already returned in the system default time zone. So
> you could rephrase this:
> 
>> String fullMonthName =
>> CurrentDateTimeUtils.getCurrentMonth().getDisplayName(
> 
> as:
> 
>> LocalDateTime.now().getMonth().getDisplayName(
> 


> which aside of saving you from having a method is actually even shorter
> than calling the method ;)
> 

Very good!

Now that I've learned more about the classes and methods available in 
the java.time.* classes, I've realized that I can do practically 
anything I need to do directly in my programs in a single line. That 
means it's pointless to have the vast majority of my convenience methods 
at all! My class of date/time methods is shrinking like an ice cube in a 
fry pan :-) I previously had a method to determine if a date string like 
"2018-10-26" met all the criteria to be a valid ISO date; it was well 
over 100 lines long. This is probably going to be a one liner now plus 
the try/catch block needed to handle any exception that I get.

I *really* like the java.time.* classes! They seem very well designed, 
very powerful, and even concise. I'm glad Java finally developed them.

Thank you - and all the others who replied - for your responses!

-- 
Rhino

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

#38666

On 10/26/2018 10:10 PM, Rhino wrote:
> [...]
> Now that I've learned more about the classes and methods available in 
> the java.time.* classes, I've realized that I can do practically 
> anything I need to do directly in my programs in a single line. [...]
> I previously had a method to determine if a date string like 
> "2018-10-26" met all the criteria to be a valid ISO date; it was well 
> over 100 lines long. [...]

     The java.time package arrived with Java 1.8 in 2011.

     The java.text.DateFormat and java.text.SimpleDateFormat classes
have been around since -- well, since "I dunno, but they're described
in my Java 1.1 O'Reilly book from 1997."

     Maybe you could benefit by spending a little more time reading
before starting to code.  "Those who will not learn from Javadoc
are condemned to re-implement."

-- 
esosman@comcast-dot-net.invalid
Eight hundred sixteen days to go.

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

#38673

On 2018-10-27 7:43 AM, Eric Sosman wrote:
> On 10/26/2018 10:10 PM, Rhino wrote:
>> [...]
>> Now that I've learned more about the classes and methods available in 
>> the java.time.* classes, I've realized that I can do practically 
>> anything I need to do directly in my programs in a single line. [...]
>> I previously had a method to determine if a date string like 
>> "2018-10-26" met all the criteria to be a valid ISO date; it was well 
>> over 100 lines long. [...]
> 
>      The java.time package arrived with Java 1.8 in 2011.
> 
I knew they came out in Java 1.8 but I didn't realize it had been around 
for so long. I basically didn't touch Java - aside with some dabbling 
with F/X - from around 2012 until recently. I hadn't gotten around to 
converting to java.time by the point at which I stopped using Java in 2012.

>      The java.text.DateFormat and java.text.SimpleDateFormat classes
> have been around since -- well, since "I dunno, but they're described
> in my Java 1.1 O'Reilly book from 1997."
> 
Yes, I was using those too, not just Calendar :-)

>      Maybe you could benefit by spending a little more time reading
> before starting to code.  "Those who will not learn from Javadoc
> are condemned to re-implement."
> 
Indeed, no question about that.

But it's been fun rewriting those old date routines in favour of the 
java.time approach :-)

-- 
Rhino

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

#38676

On 10/29/2018 2:40 PM, Rhino wrote:
> On 2018-10-27 7:43 AM, Eric Sosman wrote:
>> On 10/26/2018 10:10 PM, Rhino wrote:
>>> [...]
>>> Now that I've learned more about the classes and methods available in 
>>> the java.time.* classes, I've realized that I can do practically 
>>> anything I need to do directly in my programs in a single line. [...]
>>> I previously had a method to determine if a date string like 
>>> "2018-10-26" met all the criteria to be a valid ISO date; it was well 
>>> over 100 lines long. [...]
>>
>>      The java.time package arrived with Java 1.8 in 2011.
>>
> I knew they came out in Java 1.8 but I didn't realize it had been around 
> for so long. I basically didn't touch Java - aside with some dabbling 
> with F/X - from around 2012 until recently. I hadn't gotten around to 
> converting to java.time by the point at which I stopped using Java in 2012.
> 
>>      The java.text.DateFormat and java.text.SimpleDateFormat classes
>> have been around since -- well, since "I dunno, but they're described
>> in my Java 1.1 O'Reilly book from 1997."
>>
> Yes, I was using those too, not just Calendar :-)
> 
>>      Maybe you could benefit by spending a little more time reading
>> before starting to code.  "Those who will not learn from Javadoc
>> are condemned to re-implement."
>>
> Indeed, no question about that.
> 
> But it's been fun rewriting those old date routines in favour of the 
> java.time approach :-)

     Maybe I should have been more direct.  Here's another try:

     java.text.SimpleDateFormat::parse can determine whether a String
meets "all the criteria to be a valid ISO date," and has been able to
do so since long before java.time appeared on the scene.  Had you been
aware of this you would not have needed to write your 100+ lines at all.

     You can save yourself lots of time and effort by becoming familiar
with the time and effort others have already spent to smooth your way.
Or you can re-invent yet another wheel ("fewer corners, fewer bumps!").

-- 
esosman@comcast-dot-net.invalid
Eight hundred fourteen days to go.

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

#38671

On Friday, October 26, 2018 at 10:10:34 PM UTC-4, Rhino wrote:
> Now that I've learned more about the classes and methods available in 
> the java.time.* classes, I've realized that I can do practically 
> anything I need to do directly in my programs in a single line. That 
> means it's pointless to have the vast majority of my convenience methods 
> at all! My class of date/time methods is shrinking like an ice cube in a 
> fry pan :-) I previously had a method to determine if a date string like 
> "2018-10-26" met all the criteria to be a valid ISO date; it was well 
> over 100 lines long. This is probably going to be a one liner now plus 
> the try/catch block needed to handle any exception that I get.
> 
> I *really* like the java.time.* classes! They seem very well designed, 
> very powerful, and even concise. I'm glad Java finally developed them.
> 
> Thank you - and all the others who replied - for your responses!
> 
> -- 
> Rhino

The only datetime methods I have in my custom API are for gregorian julian conversion.

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

#38674

On 2018-10-29 8:07 AM, Eric Douglas wrote:
> On Friday, October 26, 2018 at 10:10:34 PM UTC-4, Rhino wrote:
>> Now that I've learned more about the classes and methods available in
>> the java.time.* classes, I've realized that I can do practically
>> anything I need to do directly in my programs in a single line. That
>> means it's pointless to have the vast majority of my convenience methods
>> at all! My class of date/time methods is shrinking like an ice cube in a
>> fry pan :-) I previously had a method to determine if a date string like
>> "2018-10-26" met all the criteria to be a valid ISO date; it was well
>> over 100 lines long. This is probably going to be a one liner now plus
>> the try/catch block needed to handle any exception that I get.
>>
>> I *really* like the java.time.* classes! They seem very well designed,
>> very powerful, and even concise. I'm glad Java finally developed them.
>>
>> Thank you - and all the others who replied - for your responses!
>>
>> -- 
>> Rhino
> 
> The only datetime methods I have in my custom API are for gregorian julian conversion.
> 
I can see why. Almost anything you can want from a date can be 
determined in a single line so why write convenience methods any more?

-- 
Rhino

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

#38649

On 10/24/2018 5:04 PM, Rhino wrote:
> Is it better to overload a single method name several times or to create 
> uniquely-named methods to accomplish similar work?
> [...]
> APPROACH 1:
> I could have several overloaded versions of a single method. For instance:
> - getCurrentMonthName(boolean fullMonthName) and assume local time zone
> [...]

     In addition to what Arne and Joerg have said, I'd suggest that
the association `true' -> "full name" and `false' -> "short name"
is not very self-documenting.  Perhaps you should use an `enum'
instead, either TextStyle or something of your own, since

	String name = getCurrentMonthName(TextStyle.SHORT);

is more easily read and understood than

	String name = getCurrentMonthName(false);

     Also, if you someday need to support extraterrestrial locales
and find out that Klingon has *three* common forms for month names,
an `enum' can always grow a third instance while a boolean can't ...

-- 
esosman@comcast-dot-net.invalid
Eight hundred nineteen days to go.

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

#38651

On 2018-10-25 7:49 AM, Eric Sosman wrote:
> On 10/24/2018 5:04 PM, Rhino wrote:
>> Is it better to overload a single method name several times or to 
>> create uniquely-named methods to accomplish similar work?
>> [...]
>> APPROACH 1:
>> I could have several overloaded versions of a single method. For 
>> instance:
>> - getCurrentMonthName(boolean fullMonthName) and assume local time zone
>> [...]
> 
>      In addition to what Arne and Joerg have said, I'd suggest that
> the association `true' -> "full name" and `false' -> "short name"
> is not very self-documenting.  Perhaps you should use an `enum'
> instead, either TextStyle or something of your own, since
> 
>      String name = getCurrentMonthName(TextStyle.SHORT);
> 
> is more easily read and understood than
> 
>      String name = getCurrentMonthName(false);
> 
>      Also, if you someday need to support extraterrestrial locales
> and find out that Klingon has *three* common forms for month names,
> an `enum' can always grow a third instance while a boolean can't ...
> 
Yes, I'd already thought about the lack of flexibility in the boolean 
approach before I saw your and Joerg's replies. I created an Enum called 
MonthNamePattern and gave it all 8 values possible for a Month, 
acccording to the documentation in DateTimeFormatter: MMMM, MMM, MM, M, 
LLLL, LLL, LL, and L.

I could just pass that Enum to the method to have it return the exact 
format the calling program wants or, better yet (if I understood Joerg 
correctly) just let the convenience method return the month value in a 
java.time.Month and then let the *calling* program decide if it wants 
the TextStyle.FULL or TextStyle.SHORT or the numeric equivalent of the 
month. I could even use my Enum with a DateTimeFormatter to make the 
calling program display the month using the single M formatting code if 
that became necessary.

If I return the java.time.Month, then I really only need two variations 
of getCurrentMonth:
- getCurrentMonth() which defaults to the system default zone ID
- getCurrentMonth(zoneId) which uses the specified zone ID

I *like* this approach! No unwieldy names like 
getCurrentMonthFullRemote() and only two simple methods to write. In 
fact, the convenience methods are so simple they are very close to 
trivial and may not even be worth writing....

(Thanks to Joerg's remarks, I just now discovered the existence of the 
separate classes for Month, Day, etc. and the various techniques they 
offer to present the information however you want them. I had really 
just started looking at java.time.* this week after a few years away 
from Java and hadn't explored all the classes yet.)


-- 
Rhino

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web