We don't need another Y2K problem!

I don't know if you had airplanes falling out of the sky into your backyard,
but that was scary for me.

--
LTP

 To make this point, it was not necessary to quote the full
 text of my article. I suggest that you consider to quote only
 a relevant part of an article you respond to.

 The example was chosen to talk about the usage of algorithms
 bound to interfaces only. I agree that there usually is no
 need to find the leap year property for very large year numbers.

On Sat, 18 Mar 2006 13:29:35 -0500, "Rhino"
<no.offline.contact.please@nospam.com> wrote, quoted or indirectly
quoted someone who said :

there will likely not be any humans beyond the year 3000 and certainly
by then the calendar used on earth will have changed.

I would hope the average Java programmer would first notice that it
wasn't a multiple of four.

 I should have chosen a better example in order not to distract
 the attention of most readers to the special example of a
 determination of the leap year property.

 Your criticism addresses another issue regarding the language
 Java. One could imagine other languages where a more general
 notation in the source code would not exclude using the
 notation with the datatype »int«.

 For example, I believe, in C++, one can write:

template<typename T> bool is_leap_year( T const year_number )
{ const bool is_quad        = year_number % 4   == 0;
 const bool is_century     = year_number % 100 == 0;
 const bool is_quadcentury = year_number % 400 == 0;
 const bool is_canceled    = is_century & !is_quadcentury;
 const bool is_leap_year   = is_quad & !is_canceled;
 return is_leap_year; }

 This now is general insofar as it can be applied to
 every type implementing the operation »%« -- not
 only »int«. But it can be applied to »int« as is:

#include <iostream> // ::std::cout
#include <ostream>  // <<

int main(){ ::std::cout << is_leap_year( 2006 )<< '\n'; }

0

 In Java one most prematurely decide between coding for »int«
 or coding a more general formulation or write two or more
 similar methods by hand.

By the very same reasoning, int, and in fact, Java, is a poor choice.
The data type int falls somewhere before the (assumed) requirement of
the user. To paraphrase the requirement (since requirements cannot be
accurately expressed in English (or a programming language for the Mr.
TDD!)), a data type that extended between negative and positive infinity
is required to express the arrow of time. Of course, this cannot be
achieved - quantum mechanics not withstanding - since it comes down to
things like physical hardware limitations, etc.

The question now is, why is the user of the programming language
restricted to express his/her implementation of requirements using a
tool - the programming language - that falls short of the target? Why is
the restriction not put in place by other physical limitations? And more
importantly, why does the programming language even care about such a
restriction? More often than not, I see an exceeding of requirements,
and here we are observing a not-so-common case, so it makes things a
little more difficult to argue. That is, it is much more easy to argue
on the premise of excess requirements since it is much more common, and
subsequently digress to this case, so I'm going out on a limb.

Assuming Java provided a data type that permitted an extension to
infinity (this excludes BigInteger for other reasons that I have omitted
and hope are not picked up on - for brevity), then it would certainly
make int look like hitherto "overkill". Since int could be viewed as
"being exactly the same as the infinite data type with the addition of a
restriction of finite bounds". One could then go on to say that this
restriction is indeed "addition" and since this addition "exceeds
requirement", it is therefore, "overkill".

The moral of the story is, formally express your requirements, even if
it is in your own head (admittedly, this is extremely difficult to do in
the face of the prolific "propaganda"). Unfortunately, Java contradicts
this ability in more ways than one, so we end up with some contrived and
blurred understanding of "what the hell it is we are doing" - to state
it loosely but not to undermine its importance. Nevertheless, I concede
to the immense power that marketers/evangelists/proclaimed
"experts"/etc. have...

In the meantime, I continue to document (though not publicly for now -
my recent resignation from IBM (i.e. The Filth) now permits me to) what
I, and a select few others, believe is a sound refutation and logical
proof of the invalidity of many of the tools (including Java itself)
that so many assume to exist legitimately within our common axioms.

 I know.

 That's why, within my source tree, this is placed into the
 package »gregorian«. This was not visibly from my post.

[...]

Shouldn't that be <http://mindprod.com/jgloss/leapyear.html>?

 This is true. But this exposure possibly can not be avoided.

 Software engineers often take hardware as a role model.
 Hardware devices have interfaces (connectors).

 So a device having a power-supply connector and a loudspeaker
 connector exposes that it needs power and possibly a
 loudspeaker. But hiding this might be impossible.

 It could add additional connectors in order to hide
 the information that it only needs a power-supply and
 a loudspeaker. The client then would have to connect
 to all the connections but would not know which of them
 really are used and which not.

 But in the case of a hardware device one would see
 little use of this over-hiding.

 Within my paradigm, in this case, I will not /change/
 the existing algorithm, but /add/ another algorithm
 with the new interface.

 On one hand, C++ templates are great for such algorithms.  
 I still use Java, because I like the fact that Java has a GUI
 (Swing) as part of its standard edition and that there are
 JVM-implementations for several platforms. And C++ is really
 a mess with all thos legacies and complicated rules.

   On the topic of good OO design, the concept of a "year" and the concept
of an "integer" are not nescessarily interchangeable. Rather than passing in
some arbitrary integer into a method, and having that method answer the
query "If you take this integer, and interpret it as a Gregorian year
number, would this be a leap year in the Gregorian calendar?" it might be
better to have a type which defines a "point in time" (for simplicity, let's
assuming newtonian physics, and i.e. a globally agreed progression of time),
and then query that "point in time" object, does this point occur within a
leap year under the gregorian calendar?

   The "point in time" might implement its state using ints representing
seconds since the unix epoch (and thus could represent points prior to the
epoch via negative numbers), or it might use BigInteger to represent
nanoseconds since the the Big Bang, or something else. It doesn't matter,
and you shouldn't need to know how it internally keeps track of its time.

   Alternatively, you might have various Calendar objects, which take as
input a "point in time" object, and then could answer questions about that
point in time (e.g. there might exists calendars for which the concept of a
"leap year" is meaningless).

   - Oliver