Comment On My List Is Emptier Than Your List

Well, duh, how else would you do this?  Isn't this the whole point of OOP - you can take advantage of class hierarchies and subclassing polymorphism to more easily represent complex concepts, like empty lists, that would be simply impossible to create in non-OO languages?

The only WTF here is that they appear to be writing their empty list classes by hand, instead of generating them automatically from the UML.

Let's start the flame wars!!!

The only WTF that I see is that they are using JAVA!!!!

[um]Come, rain of fire!!!

Thanks, Leo

Throws:

IndexOutOfBoundsException - if the index is out of range (index
< 0 || index >= size()).

Yet it's kind enough to not throw an exception if you try to access an element that is out of bounds.  Genius!

I can't think of any reason you'd need an object that was completely empty. Couldn't you just do this:

String EmptyList;
EmptyList = "";

And there you have it, a simple no-nonsense way of having an object that is devoid of information. My Java experience is one college class with a Middle Eastern professor that I took a year ago and haven't used since, so sorry if the syntax isn't right.

Anonymous:

package initech.foundation.util;


Anybody else notice the name "Initech" (of Office Space fame).

"I too am not a ..."

- Jon

Anonymous:

Well, duh, how else would you do this? 
Isn't this the whole point of OOP - you can take advantage of class
hierarchies and subclassing polymorphism to more easily represent
complex concepts, like empty lists, that would be simply impossible to
create in non-OO languages?

The only WTF here is that they appear to be writing their empty list
classes by hand, instead of generating them automatically from the UML.

package initech.foundation.util;

public class NotSoEmptyList extends EmptyList
{
  public NotSoEmptyList()
  {
          
  }

  public Object get(int index) 
  {
    return new String("TA DA");
  }

  public int size()
  {
    return 1;
  }

}

Jon:

package initech.foundation.util;


Anybody else notice the name "Initech" (of Office Space fame).

"I too am not a ..."

- Jon

Jon, quick tip for posting to messageboards: Read through a few of the topics before you conjure up your first post. That way you'll catch up on inside jokes and the posting habits of the regulars. I think most people here are understanding enough to explain what's going on to the new folks, but other boards I've been on are not so kind.

GalacticCowboy:

One of my coworkers pointed out that, as
they have not overridden the "Add" functions, you can merrily add
items to the list all day - you can just never retrieve them or know
how many there are...

Anonymous:

Let's start the flame wars!!!

The only WTF that I see is that they are using JAVA!!!!

[um]Come, rain of fire!!!

Thanks, Leo

Anonymous:

Let's start the flame wars!!!

The only WTF that I see is that they are using JAVA!!!!

[um]Come, rain of fire!!!

Thanks, Leo

dmitriy:

This is not too bad, except for two problems. One, pointed out already,
si that you can add elements to this list. The other is the get()
method. If the caller tries to call any methods on the "Object"
returned, their application will crash because of dereferencing a null.

I'm just glad they didn't sprinkle a few calls to IsTrue() in there.

Rick:

You cannot add any items to an AbstractList without overriding at least one of the add methods. So EmptyList is not a NULL SINK, which actually might be useful. /dev/null in Unix certainly is useful.

Ahh...  see, I'm not a Java programmer, unlike the guy who told me that...  [A]

Anonymous:

As the poster of this code I'm happy to say that this code was actually used to represent a special brand of no data.



It made me say WTF when I saw it.  Then I searched for where it
was used and got even more mystified.... they kept creating new
instances of EmptyList all over the place, storing it and then
converting them back to null before exiting the method it was used in!

Rick:

Trivia question:

What does Java 1.5 do with the new extended for loop if the size() method doesn't return the correct size of the collection?

1. Takes three times the code necessary to perform simple tasks.


2. Mimics functionality that is readily available in the development framework, but with a fraction of the features.
   
   

GalacticCowboy:

One of my coworkers pointed out that, as
they have not overridden the "Add" functions, you can merrily add
items to the list all day - you can just never retrieve them or know
how many there are...

Sean:

GalacticCowboy:

One of my coworkers pointed out that, as
they have not overridden the "Add" functions, you can merrily add
items to the list all day - you can just never retrieve them or know
how many there are...

Write-Only Memory.



Awesome.

Anonymous:

Rick:

Trivia question:

What does Java 1.5 do with the new extended for loop if the size() method doesn't return the correct size of the collection?

The extended for loop uses a java.util.Iterator, not size info.

mjonhanson:

If you want to start a flame war, you need to do it properly by giving
an example of why Perl or VB or Lisp or Smalltalk or Brainf**k, etc. is
better than Java, preferrably with completely unreadable code on a
single line.

trollable:

mjonhanson:

If you want to start a flame war, you need to do it properly by giving
an example of why Perl or VB or Lisp or Smalltalk or Brainf**k, etc. is
better than Java, preferrably with completely unreadable code on a
single line.

Empty list in Lisp:    ( ) 

Sorry, I can not make it unreadable. Lots of advantage: constant, small, shareable, not exceptions, ...

Empty list in python: list() (alternate syntax: []).

Ditto for the thoughness of making that unreadable.

I'd like to say that I've done similar things, but frankly I can't stretch my oddities this far.  I am not sure why you would want to create a list that is ALWAYS empty but can always return data.  Perhaps so that you always at least have a valid list object (and there is where the overlap occurs with my past projects, but in my case it was a list that always had a zero'th 'empty' element and it was returned when the internal searchs failed to find a match, so I didn't have to handle null pointers - still when I get the chance, I'll end up rewriting that code cause it causes nothing but grief as the project evolves).

For all it does, it might as well be a null pointer.  I am somewhat suprised to find that java has a system object that clones this one.  Why exactly would you want to create a list object that basically acts like a huge black hole???  For just keeping a pointer active, an actual list with no elements would seem to make about as much sense, except that you could actually add data to it instead of getting an abstraction exception popup.

A real head scratcher to be sure.

masklinn:

trollable:

mjonhanson:

If you want to start a flame war, you need to do it properly by giving
an example of why Perl or VB or Lisp or Smalltalk or Brainf**k, etc. is
better than Java, preferrably with completely unreadable code on a
single line.

Empty list in Lisp:    ( ) 

Sorry, I can not make it unreadable. Lots of advantage: constant, small, shareable, not exceptions, ...

Empty list in python: list() (alternate syntax: []).

Ditto for the thoughness of making that unreadable.