Comment On Dimensioning the Dimension

OMG, this makes me want to cry.  The shear and udder stupidity of this is horrendous.  Sure, you've got the array of month names, who cares.  They're in order and indexable.  The "coder" isn't even using standard month numbers, e.g. Jan == 1.  He's already using 0 as the base.  My god, why store it as a string, then iterate over the array and perform an expensive parse?  FOR THE LOVE OF ALL THAT IS RIGHT AND SANE IN THE WORLD, WHY?

Having an array with month names is IMO exceusable, since it saves you
from any surprises; but there is absolutely no excuse for the way the
lookup is done.

To play devils advocate, if he wanted the month name in different foreign languages, it would be pretty easy to add his way.

Or if he wanted to encode the indices as Roman numerals.

Anonymous:

To play devils advocate, if he wanted the month name in different foreign languages, it would be pretty easy to add his way.

Ignoring that Java already has a Calendar class that supports different locales, how does storing the month number as a String version of the array index help with foreign languages?  Are you saying the "0" might be something else in another language?

Let's say that this was generated or you wanted to use abbreviations instead of numbers.  It's still wrong.  There is a Map interface with provided implementations for mapping things.

My guess as to why it's indexed on 0 is that the Calendar class uses the same system.  12 is the 13th month: Undecember.

Well, at least this programmer has potential...  He recognizes
that the solution is a simple lookup.  But he chooses the wrong
the structure, and doesn't see his mistake when he creates the lookup
method.



(I must say that I have a soft spot for the "private static final
Object[][] whatever= {{a,b},{c,d},...};" structure...  I have a
class that builds a Map from that, and I use it ALL THE TIME.)

How much you wanna bet that this programmer makes more per year than I
do...  Oh wait, since this is paving the way for higher-paid
consultancy the answer would be yes.  Just think... what if the
impossible happens and somebody decides to use 1-12 as the month
indices!  The horror!

Charles Nadolski:

Just think... what if the
impossible happens and somebody decides to use 1-12 as the month
indices!  The horror!

It'll be fine until December ;-)

Beek:

(I must say that I have a soft spot for the "private static final Object[][] whatever= {{a,b},{c,d},...};" structure...  I have a class that builds a Map from that, and I use it ALL THE TIME.)

It's a common desire to have an overloaded syntax for maps that works that way.  I just use a static block and a series of puts.  To me it's just as readable if not more so.

Maybe it's like those old DOS games that had to waste CPU time to slow
down game play to a sane level. Constant-time lookup is just too quick,
let's iterate over the whole array and throw in a parse while we're at
it!

He's trying to avoid an "array index out of bounds" error
What if the int passed to his function is outside the range 0-11?
In that case his function returns null.

It's just a more complicated way to write

if (i < 0 || i > 11) { return null; }

return new DateFormatSymbols().getMonths()[i];

I personally would rather see the array-out-of-bounds exception, but to each his own.

The WTF here is that he doesn't have a try...catch around the parseInt.

Unfortunately the Romans had no 'zero'.  He'd have to change the indices.



One small change and he could use base-12, though!  Think of the memory saving!

Oh god, I don't see how one could come up with something like this even if you were deprived of coffee whilst going 36 hours non-stop.

I can't believe that sometime during the process of typing in "for (int i = 0; i < months.length; i++)" it just simply did not occur to the person (I'm not calling him/her a developer) that "hey, wait-a-second... Can't I use this incrementing integer thingy I'm declaring instead of my own make-shift index...."

[:'(] Guess not...

The beauty of this is that it can be optimized by placing the most frequently used months at the beginning of the array.

Anonymous:

The beauty of this is that it can be optimized by placing the most frequently used months at the beginning of the array.

Yes, it's beautiful because it's possible to optimize away some of the inefficiencies inherent in the stupidity of the solution.  You might even get close to it being as performant as a proper solution.

When the world switches to a lunar calendar, this guy is going to add
one line of code while the rest of the Java community weeps.

Anonymous:

When the world switches to a lunar calendar, this guy is going to add
one line of code while the rest of the Java community weeps.

I can see it now: "Profits were down in the third new moon after the winter solstice..."

Anonymous:

When the world switches to a lunar calendar, this guy is going to add one line of code while the rest of the Java community weeps.

That would be true if Calendar didn't already have built in support for lunar calendars.  So when the world switches to the lunar calendar, this guy (or actaully probably someone else who is cursing his name) will be updating this code while the rest of the Java world changes a system property.

dubwai:

My guess as to why it's indexed on 0 is that the Calendar class uses the same system.  12 is the 13th month: Undecember.

Would Hendecember be better?

Time is not a spacial dimension, and thus requires additional application of string theory.

There are "11" kinds of people in the world, those who understand string theory and those who don't.

 

If you really must accept an index [+o(] instead of a month number then
public static String getMonthDescription(int month)
should at least be
public static String getMonthDescription(int monthOfYearIndex)

There is no month zero, it should barf on zero and die on 13.

Stuff like that is n times worse when multilingual, where n is the number of cultures.

I've never seen a date expressed as 0/13/2005, no beer for you!

He's probably starting with 0 because java.util.Calendar does. The Calendar class escaped from Taligent somehow. I am not making this up.

There's a strong tradition in the C-like world of using 0-11 for months
and 0-6 for days-of-week, precisely because those are the things you
always use as array subscripts.  See <time.h>

http://www.opengroup.org/onlinepubs/007908799/xsh/time.h.html

To make something start at 1 would be blasphemy! For computer people
things allways start as 0. It is only seems natural to us, because 0 is
the smallest number you can represent in a byte (or whatever) - unless
you start abusing a bit for sign, ofcause. Also us fine computer guys
absolutely HATE verbose variable-names, so to see something like "monthOfYearIndex" would make us puke all over eachother in disguist. Hope that answered your question. : )



Btw, that structure and lookup-method really is a great joke! Made my day!

Ah, for fuck sake - i didn't read your post properly. WTF!!

Anonymous:

To make something start at 1 would be blasphemy! For computer people things allways start as 0.

 

Excet for VB6 programmers who have difficulty understanding that arrays in VB.Net start at index 0, that the Substring method starts at index 0, that IndexOf starts at index 0 etc. etc. etc. ...

Drak

I think he didn't understand arrays all that well.

I have to say though, Robert Cooper's colleague

Was it a highly payed consultant? [:-D]

omfg not Java dates... I'm not going to get started. I honestly never
forgave Xalan/Exslt and never will for choosing 0-based MONTHS and
1-based EVERYTHING ELSE just to FUCK WITH US. Fuck adding and
subtracting one to EVERYTHING just because it's EASIER TO MAKE THE JAVA
BACKEND. I was firmly against it and so pissed off that good sense lost
to expediency.



Oops, I got started.



I love this guy's attempt at extending bubble-sort into the rest of
programming theory. =D At least he didn't use a hashmap to look up the
string index in the main array. But I guess he'd have to know what
hashmaps were. Unless he made his own! =D

Drak:

Excet for VB6 programmers who have difficulty understanding that arrays in VB.Net start at index 0, that the Substring method starts at index 0, that IndexOf starts at index 0 etc. etc. etc. ...

You don't even need to go to VB.Net to have problems. Even in VB6, some things start at 1 and some at 0 ... It requires more concentration. Of course, this is more so a problem in ASP/VBScript when there's also Javascript code in the browser ...

Anonymous:

When the world switches to a lunar calendar, this guy is going to add one line of code while the rest of the Java community weeps.

I wrote a calendar class once (in VBScript, moreover! ) that fully supported several languages, display styles, holiday calculations and several related things (like zodiac).

That class was then expanded to handle Mayan Tzolkin, Haab and Longcount calendars. Then I added lunar-based calendars (like Hijri - the islamic calendar). Not too many people are active in these fields, but if you need different calendar systems, you can better make all of them yourself.

Why?

 

Surely, as the rest of the community is using the standard supplied functionality, when this change happens, they update the java libs and all is well (thats the theory anyhoo)

Free:

Time is not a spacial dimension, and thus requires additional application of string theory.

There are "11" kinds of people in the world, those who understand string theory and those who don't.

Wouldn't that be M-theory?  [:P]

Anonymous:

I wrote a calendar class once (in VBScript, moreover! ) that fully supported several languages, display styles, holiday calculations and several related things (like zodiac).

That class was then expanded to handle Mayan Tzolkin, Haab and Longcount calendars. Then I added lunar-based calendars (like Hijri - the islamic calendar). Not too many people are active in these fields, but if you need different calendar systems, you can better make all of them yourself.

My understanding is that the Java Calendar class can support all of this.

For all you zeros ;)

I'm not suggesting that you should have an extra empty array element, I'm suggesting that the name of the parameter should make it very clear that the expected value is an index [0 -11] and not a month number [1-12].

Mort is not going to read the documentation, he is going to code the date in a string, split it, parse the month part into an int, pass it to the function, then blame you because April became May with no showers and no flowers

Free:

For all you zeros ;)

I'm not suggesting that you should have an extra empty array element, I'm suggesting that the name of the parameter should make it very clear that the expected value is an index [0 -11] and not a month number [1-12].

Mort is not going to read the documentation, he is going to code the date in a string, split it, parse the month part into an int, pass it to the function, then blame you because April became May with no showers and no flowers

The advantage to using 0 based months here is that:

getMonthDescription(java.util.Calendar.MAY) will return "May" whereas if it was implemented they way you suggest, it would return "April" when MAY is provided as the input.  Likewise if you created a Calendar instance and called:

getMonthDecription(caledar.get(Calendar.MONTH) it would return "March" with your implementation.

Free:

For all you zeros ;)

I'm not suggesting that you should have an extra empty array element, I'm suggesting that the name of the parameter should make it very clear that the expected value is an index [0 -11] and not a month number [1-12].

Sorry, misunderstood.  Ignore that I directed my response as a reply to you.

No. Localization in Java is handled with .properties files, not with hard-coded strings.

At least we can be sure it's not production code since this class won't compile. Integer.parseInt() needs to be in a try block, or getMonthDescription() needs to be declared to throw NumberFormatException for this to compile.

erm the only exception that can be thrown by Integer.parseInt  is
NumberFormatException
(http://java.sun.com/j2se/1.3/docs/api/java/lang/NumberFormatException.html)
that exception is a descendent of runtimeexception so does NOT need to
be caught or declared in throws.

That's uh, Undecimber. I don't know why. Probably has something to do with moon howling satan worshipers.

Ah, right, no declaration of the exceptions is necessary. That's... umm... even more worrying then, eep.

Looks to me like an ex PHP freak who can't process data unless it's in an associative array...

Out of runes of magic gold? Need it in urgent? Yes, I can understand you. As the most important currency, without rom gold, you ever can’t do anything. So you need to buy rom gold from those most professional and loyal game online shops with years’ experience and have a good reputation among players. Is there any difficult? No, when you need the rom gold, please feel free to contact us, we are promising to offer you the cheap runes of magic gold with fastest delivery. Moreover, we are online 24/7, you can contact us any time with any question about. So why are you still irresolute? Come here to grab your cheap runes of magic gold now. Crazy about running warhammer gold? Yup, it is so crucial indeed for us in Warhammer Online. Without it, we can even do nothing, without money to buy items, weapons and so on. So enough warhammer gold is substantial.

Bustaz Kool:

dubwai:

My guess as to why it's indexed on 0 is that the Calendar class uses the same system.&nbsp; 12 is the 13th month: Undecember.

Would Hendecember be better?

I thought it was called Prejanuary

find for all kinds of watches and handbags

http://replica038.com