I had one of the very first computer webcams, the Connectix QuickCam, back in 1995. I took it with me to college and actually video chatted with my parents a few times from my college dorm room. At the time, the webcam software and propaganda was very excited about the idea of “video email”, and that, in the very near future, we’d all be sending short video recordings to each other like on Star Trek. But then again, everyone thought we’d be surfing the web in 3D with VRML by the end of the millennium, too.

The iPhone 4, and other front-facing camera phones, have finally lowered the hassle level of sending a video email, a requisite for any technology taking off. Bandwidth speeds and video compression algorithms are now good enough that a 30 second video clip can be downloaded in less than 20 seconds.

Even with all this level of ease, I still don’t think video emails will become standard any time soon. Google’s increasingly popular Google Voice service is handy specifically because it is moving in the opposite direction, translating spoken voice messages into text. Text is the most efficient way we receive communication, since most people can read faster than they can talk. It’s also much easier to edit and perfect just what you want to say in text than with video (e.g. “Darn, that’s not what I meant. Let’s record another take!”)

One might think that if the literacy rate continues to drop, voice and video emails might become more popular, but one look at social networking sites like MySpace and Facebook confirms that a lack of literacy doesn’t seem to be stopping anyone.

A Case Study

For a couple weeks now, I’ve been working on getting Nora to say “Good morning”. She doesn’t yet say it perfectly and requires some prodding in the morning to say it, but she’s made some progress. Earlier in the week, I thought that if I could pair “good morning” with “grandma”, a word she knows well (she says “meh-mah”), it might be nice to record a little video to send to my mother for her to see when she woke up. It only took about four takes, and then another thirty minutes for her to stop saying “Good morning, Grandma!” Not surprisingly, we had a video response in our inbox the next morning. This time in our response, we tried saying “Good morning, grandpa!” as well, but to limited success. It was a fun experiment this week, but our vocabulary has run out, I think.

Perhaps one day we will be recording messages back and forth all day long, but I suspect that people will still be typing with their fingers and scrolling through text on screens at the end of the twenty-first century.

Related Photos

I think that the internet and the optional anonymity it provides are having an excellent effect on social taboos. I applaud the hundreds of people valiantly blogging their way through emotionally difficult times of their life, whether it be divorce, miscarriage, closeted sexuality, cancer, or losing a spouse. By being publicly honest about these things, even anonymously, they are helping thousands of other people feel less alone in their problems. Parenting is less severe than those problems, but it still brings with it insecurities that, unless other people are sharing about them too, can easily make you feel alone. And if you can find a way to pay the rent by designing a website to help people share, then good for you, Griscom and Volkman.

Related Photos

1. I get some requirements for a program from my boss or a client.
2. I write the program as perfectly as I can.
3. I test the program with all the cases that I think it will need to handle.
4. The program is done and people start using it.
5. For whatever reason the requirements change (or a bug is found), and I have to go back and modify the code. Inevitably less testing is done on these changes than the original writing.
6. Go to #4.

It’s pretty rare for the original writing of a program to have a significant bug in it after testing, although I’m not perfect. Almost all bugs are introduced in step #5. When you first write the program, the entire program and its relationship with other programs is in your mind. But when you go back to look at old code, it’s just not fresh in your memory, and it’s very easy to make a change without taking into consideration all the consequences that change will have.

Sometimes when I’m doing testing on change to a piece of code, I’ll find a problem in an unrelated common part of the system, like a line of code that is run several dozen times every time anyone goes to any page on any of my company’s websites. Looking at the code reveals that there is no way this could possibly be working, and yet millions of dollars of revenue have been earned specifically because that line worked.

The name in the industry for this type of phenomenon is Schroedinbug, because, like Schrödinger’s cat, everything is fine until you observe what’s inside the box.

What is really mind-blowing about Schroedinbugs is just how often they occur. I find bugs like this several times a year. Today was one of those days.

I have to wonder if other branches of engineering have similar phenomena. Do engineers sometimes find a rusted bolt and say, “Man, I can’t believe the bridge is still standing!” Do doctors often tell patients, “According to medical science, that really should have killed you.” I certainly hope not, but my intuition tells me it happens all the time.

Related Photos

Clojure comes with a built-in library for parsing XML files into Clojure data structures, but, for the life of me, I could absolutely not find any implementations that went the other way, to render XML from the Clojure structure that the default parser creates. So I wrote one…in 25 lines of code.

Update: I did find a function in the clojure contrib lazy-xml.clj that will emit XML nodes to a stream, but it’s (gasp!) not remotely functional.

(def *always-open* #{:div :script :textarea})

(defn render-attributes [attributes]
  (when attributes
    (apply str
      (for [[key value] attributes]
        (str \space (name key) "=\"" value \")))))

(defn render [node]
    (if (string? node)
      (.trim node)
      (let [tag (:tag node)
            children (:content node)
            has-children? (not-empty children)
            open? (or has-children? (contains? *always-open* tag))
            open-tag (str \< (name tag)
                        (render-attributes (:attrs node))
                        (if open? \> "/>"))
            close-tag (when open? (str "</" (name tag) \>))]
        (str
          open-tag
          (apply str (when has-children?
                       (for [child children]
                         (render child))))
          close-tag))))
There is a little extra HTML-specific logic in there to not close <script> or <div> or <textarea> tags, as some web browsers can’t handle those cases.

So if you have an HTML file that looks like this…
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
 <head>
  <title>Testing Title</title>
  <style type="text/css">
   .some-class { font-weight: bold; }
  </style>
  <script type="text/javascript" src="myjs.js"></script>
 </head>
 <body>
  <p id="message" class="some-class">
   This is a totally awesome test!
  </p>
 </body>
</html>
And you run the following command at the REPL…
(println (render (clojure.xml/parse "index.html")))
…you should get this back:
<html><head><title>Testing Title</title><style type="text/css">.some-class { font-weight: bold; }</style><script type="text/javascript" src="myjs.js"></script></head><body><p id="message" class="some-class">This is a totally awesome test!</p></body></html>
While valid XML, it’d be nice to have it prettily formatted. To do this, we must add a little complexity to keep track of depth and indentation.

(def *always-open* #{:div :script})

(defn render-attributes [attributes]
  (when attributes
    (apply str
      (for [[key value] attributes]
        (str \space (name key) "=\"" value \")))))

(defn render
  ([node] (render node 0 false))
  ([node pretty?] (render node 0 pretty?))
  ([node depth pretty?]
   (let [indent (when pretty? (apply str (repeat depth "  ")))]
     (if (string? node)
       (str indent (.trim node) (when pretty? "\n"))
       (let [tag (:tag node)
         children (:content node)
         has-children? (not-empty children)
         always-open? (contains? *always-open* tag)
         open? (or has-children? (contains? *always-open* tag))
         open-tag (str indent \< (name tag)
                    (render-attributes (:attrs node))
                    (if open? \> "/>"))
         close-tag (when open?
                     (str (when (not always-open?) indent)
                       "</" (name tag) \>))]
       (str
         open-tag
         (when (and pretty? (not always-open?)) "\n")
         (apply str (when has-children?
                 (for [child children]
                   (render child (inc depth) pretty?))))
         close-tag
         (when (and pretty? (> depth 0)) "\n")))))))
This has bumped us up to 34 lines of code with proper formatting. Now if we call:
(println (render (clojure.xml/parse "index.html")))
We still get the same unformatted html back because it defaults to non-pretty formatting. But if we request pretty formatting…
(println (render (clojure.xml/parse "index.html") true))
We get back this:
<html>
  <head>
    <title>
      Testing Title
    </title>
    <style type="text/css">
      .some-class { font-weight: bold; text-align:inherit; }
    </style>
    <script type="text/javascript" src="myjs.js"></script>
  </head>
  <body>
    <p id="message" class="some-class">
      This is a totally awesome test!
    </p>
  </body>
</html>
Perfect!

What’s amazing is that, after a few days of working with Clojure, and a very small background in Lisp, this code is perfectly readable. I could not figure out a way to go through the tree with Clojure’s tail recursion idiom, so I had to use stack recursion. For most XML files, stack recursion is going to be just fine.

I am still not convinced that Clojure deserves a place in any of my business applications, but it definitely has the best shot of any Lisp dialect I’ve seen, mainly because of its trivial interoperation with Java.

If any Clojure ninjas out there would like to suggest improvements to my algorithm, I’m all ears.

Related Photos

The Code


public class EnumMapBug
{
  private static enum E { A,B,C }

  public static void main(final String[] args)
  {
    final EnumMap<E ,String> map =
        new EnumMap<E, String>(E.class);
    map.put(E.A, "apple");
    map.put(E.B, "ball");
    map.put(E.C, "cat");

    // call entrySet() to generate internal entrySet
    map.entrySet();

    // print original values
    System.out.println("\nOriginal values:");
    System.out.println("\nA is for " + map.get(E.A));
    System.out.println("Entries: " + map.entrySet());

    // clone the map.
    System.out.println("\nCloning...now using clone.");
    final EnumMap<E, String> clone = map.clone();

    // from now on, any time we access the clone's entry set,
    // it will WRONGLY give us the original map's entry set.
    System.out.println("\nA is for " + clone.get(E.A));
    System.out.println("Entries: " + clone.entrySet());

    // no matter what we do to the clone's values,
    // the clone's entry set never changes.
    System.out.println("\nSetting new A value...");
    clone.put(E.A, "aardvark");

    // but get() still works
    System.out.println("\nA is for " + clone.get(E.A));
    System.out.println("Entries: " + clone.entrySet());

    // clear the clone
    System.out.println("\nClearing...");
    clone.clear();

    // get() properly returns null
    System.out.println("\nA is for " + clone.get(E.A));
    // but the entry set still contains our original entries
    System.out.println("Entries: " + clone.entrySet());

    // rather amazingly, when we modify the original
    // map's contents, the entry set for the clone changes
    System.out.println("\nSetting new A value...");
    map.put(E.A, "algorithm");

    System.out.println("\nA is for " + clone.get(E.A));
    System.out.println("Entries: " + clone.entrySet());
  }
}
There is a more easily copied and pasted version of this code here.

The Output

The code above results in the following output:

Original values:

A is for apple
Entries: [A=apple, B=ball, C=cat]

Cloning...now using clone.

A is for apple
Entries: [A=apple, B=ball, C=cat]

Setting new A value...

A is for aardvark
Entries: [A=apple, B=ball, C=cat]

Clearing...

A is for null
Entries: [A=apple, B=ball, C=cat]

Updating original map...

A is for null
Entries: [A=algorithm, B=ball, C=cat]

Explanation

When I said “rather amazingly” in the comment, it’s only really amazing when you don’t understand what is going on. When you clone an EnumMap, because of the entry set caching and the bug in clone(), the cloned instance’s entrySet() method will always give you a reference to the original map’s entry set, never to its own. The version of EnumMap that I’m using contains the javadoc info “@version 1.22, 05/05/07″. It’s clear enough to see the bug in clone(). The EnumMap clone() method is:

public EnumMap<K, V> clone() {
  EnumMap<K, V> result = null;
  try {
    result = (EnumMap<K, V>) super.clone();
  } catch(CloneNotSupportedException e) {
    throw new AssertionError();
  }
  result.vals = (Object[]) result.vals.clone();
  return result;
}
But it needs one more line:

public EnumMap<K, V> clone() {
  EnumMap<K, V> result = null;
  try {
    result = (EnumMap<K, V>) super.clone();
  } catch(CloneNotSupportedException e) {
    throw new AssertionError();
  }
  result.vals = (Object[]) result.vals.clone();
  result.entrySet = null;
  return result;
}
This will force regeneration and caching of the entry set in the clone.

I’m rather surprised that I cannot find any reference to this bug on the internet. It’s such an easy fix! The workaround is to never use EnumMap.clone(), but to construct a new one with its copy constructor. Like so, with the key and value in my example code:

final EnumMap<E, String> clone = new EnumMap<E, String>(map);

Related Photos

Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot.

In my investigation, I’ve found that this moment of enlightenment is mentioned by many other Lisp users (aka. Lispers). As a non-Lisper, I was reminded of the feeling I had when those Magic Eye stereograms became popular. I felt like everyone around me was staring at something that appeared uninteresting and saying, “Whoa! Cooooool!!!” I just didn’t get it.

Then, a few weeks ago, I found an article called The Nature of Lisp, by Slava Akhmechet. His stated goal of the article was to look back at his own path to Lisp enlightenment, and then reach out to the unenlightened and describe why Lisp is so cool in terms that non-Lispers understand, namely XML and Ant. Compressing the article into one sentence, the main point that non-Lispers don’t get is that Lisp blurs the line between data and code much like Ant is code written in XML, a format used mostly for data, and this lets you manipulate your Lisp code with Lisp itself. See how hard that is to understand? There’s a reason Slava’s article is so long.

I was just beginning to see the light. I had seen through the keyhole to a beautiful world out there, if I could just pry the door open a bit more… The next step was reading Practical Common Lisp, a book by Peter Seibel, that he has released free on the web. I am the exact audience that the book was written for, a pretty good programmer, well versed in one language, and interested in understanding why Lisp is so great. In his introduction, he states,

If you’re a hard-nosed pragmatist who wants to know what advantages Common Lisp has over languages such as Perl, Python, Java, C, or C#, this book should give you some ideas. Or maybe you don’t even care about using Lisp–maybe you’re already sure Lisp isn’t really any better than other languages you know but are annoyed by some Lisper telling you that’s because you just don’t “get it.” If so, this book will give you a straight-to-the-point introduction to Common Lisp. If, after reading this book, you still think Common Lisp is no better than your current favorite languages, you’ll be in an excellent position to explain exactly why.

In the past few weeks, I’ve more or less read Practical Common Lisp from cover to cover. I skipped over some of the stuff at the end about parsing MP3 files. And the final conclusion is that: Lisp is far better than any programming language I’ve ever learned, including Java, which is more or less my “mother tongue” these days. Even if you tie macros (Lisp’s true source of power) behind its back, its object inheritance, error handling, and variable scoping are far more robust and flexible than Java’s.

My programming language path went from BASIC to C++ to Java, with slight dabbling in C and Pascal along the way. As such, I thought that concepts like “everything is an object“, “every variable is really pointer to an object”, garbage collection, and running on a virtual machine were all brand new concepts in Java. And just recently I’ve been amazed at the power of concepts like closures and first-class functions in Javascript. And now I learn that Lisp was doing all this and more a decade before I was born?? Mind. Blown.

So here I am. I’ve seen the light, and it’s absolutely beautiful. I’ve pried open the door and am gazing, slack-jawed, at the blissful sunny meadows of efficient, elegant Lisp programming. As I’m preparing to leave behind my dank dark prison cell of Java, vowing never to return, a little voice in the back of my head says what I was trying all along not to think about.

If it’s so nice and perfect out there, why is there no one out there? You think you’re so smart that, in only two months, you’ve figured something out that none of the other poor schmucks in the neighboring cells haven’t?

“Shut up,” I murmured, and sprinted for the open door. And that was when I slammed, face first, into the invisible pane of glass called Emacs.

At work, I spend almost all of my time using an application called IntelliJ IDEA, an integrated development environment (IDE) for Java. IntelliJ makes Java programming as easy as it can possibly be. It more or less compiles your code as you type it, points out most bugs as they occur, intelligently suggests code completion to finish your words for you. I generates all the annoying repetitive code, like getters and setters and equals() methods for you. Without it, Java would be much more laborious to program in (but still not as bad as other languages in the C family tree). Java has many other IDE alternatives, but none truly stack up to IntelliJ.

A couple years ago, I began using a plugin for IntelliJ, called IdeaVIM, that allows me to use Vim key mappings in IntelliJ. Vim is a successor to Vi, which is an ancient UNIX text editor. The main value that it provides is allowing you to move your cursor around a text file without moving your fingers from the home row, thus greatly reducing RSI.

Lisp, on the other hand, has only one IDE. That IDE consists of Emacs, another ancient, extensible text editor, and SLIME. There are some commercial IDEs, but they all use Emacs key mappings and don’t improve the interface that much, so what’s the point? This 55 minute video (mov) (torrent) demonstration of Emacs and SLIME, by Marco Baringer (one of Lisp’s leading developers, it seems), is pretty impressive and demonstrates an efficiency of development comparable to that of IntelliJ. You can even do some things that IntelliJ (and Java) can’t do, such as compile code directly into a running remote server.

Vi and Emacs are long time rivals, and the internet is full of bitter arguments about which is superior. The fact is that they both provide ways of moving quickly around a text file and modifying entire blocks of text. And, most importantly, both of them have incredibly steep learning curves.

I just spent all this brain energy comprehending the infinite power of Lisp, and now I’m stuck at the bottom of a learning cliff that prevents me from going any further before learning an awkward set of key combinations to edit a text file. Coming from a Vim background, what I can’t stand about Emacs is that you have to hold down the Ctrl or Alt key practically the entire time you’re using it. This is enough to make a Vim user scream! Emacs seems like a sure way to RSI. This is a huge stumbling block for me at the moment, and it’s particularly frustrating because of my desire to flex my newly formed Lisp muscles.

It seems 100% crystal clear that if you want to be a Lisp developer, you have to use Emacs. This is just a fact that I’m going to have to accept and either give up or learn Emacs. I suspect that this is the major reason that Lisp isn’t more popular. There are other problems like how the lack of rigid structure makes managing large teams of programmers difficult, but I bet the main glass wall keeping people in their cells is the difficulty of learning a new and different language and a new and different text editor.

Hopefully it’s just a matter of time. I clearly recall a time when I thought, “Vi is so hard to use! Why would anyone want to learn such a difficult editor?” And now I can’t imagine life without it. I’ve mainly written this post as a diary entry, both to organize my thoughts on the matter, and hopefully to have something to look back down on after scaling the Emacs learning cliff.

Related Photos

No related photos.

What’s happening?

Each gunner moves around the perimeter of the web page and fires bullets towards your mouse pointer. That’s it. There’s no game to it. It’s just a demonstration. But that doesn’t mean you can’t have a little fun with it! If you leave your mouse cursor perfectly still, every bullet will hit it.

So let’s play!

Be careful. It’s very easy to overload your browser with too many gunners.

The Code

You are more than welcome to take a look at gunner.js (12 KiB), download it, and use it on your own website.

Related Photos

Some Examples

Other drop shadow libraries that eschew images, provide their shadow by adding an absolutely positioned div just behind the object. Like so…

I think you’ll agree that that looks pretty bad. But it’s a lot better with a little opacity tweak…

But it still just looks like a gray box under there, doesn’t it? That’s where the magic of The Shadower comes in. Rather than just one gray box, it uses several successively smaller boxes stacked on top of each other to create a realistic drop shadow that really fades into the background.

Now, doesn’t that look better? Drag it up next to the others if you aren’t convinced.

So how do I use it?

There are five parameters to play with in getting your drop shadow just right.

distance [default: 8]

The distance away from the shadowed element to draw the shadow. This can also be thought of as the height “above the page” of the shadowed object

angle [default: 130]

The direction away from the shadowed element to draw the shadow. It is measured in degrees from the vertical. If you think of it like the numbers on a clock, 12 is at 0°, 3 is at 90°, 6 is at 180°, 9 is at 270°, etc. The default angle of 130 would be between 3 and 4 on the clock face.

opacity [default: 0.7]

The opacity of the shadow, measured between 0.0 and 1.0.

nestedShadows [default: 4]

This is the number of gradually darker shadows to draw under the shadowed element.

color [default: #000000]

This is the color of the shadow. The default black color is good enough for most uses, but you can change it if you want.

Go ahead! Play with it!

Recommended Usage

Ideally, you should set a CSS class on any elements that you want shadowed, and then call Shadower.shadowWithClass() on page load. Like so…

<html>
  <head>
   <script type="text/javascript" src="prototype.js"></script>
   <script type="text/javascript" src="shadower.js"></script>
  </head>
  <body onload="Shadower.shadowWithClass('shadowed');">
   <div class="shadowed">This div is shadowed</div>
  </body>
</html>

Download

So what are you waiting for? Download it and start using it!

prototype.js

shadower.js

Feedback

I have not yet tested this on all browsers. If you have any problems, please either leave a comment on this blog entry or email me at erikwordpressplugins -at- gmail.

Enjoy!

Related Photos

No related photos.

public interface SelfParenting
{
  SelfParenting getParent(Database db) throws DbException;
}

Note that to fetch the actual instance, not just the foreign key reference, of our parent, we require the database.

So we have our two classes:

public class Folder extends ProjectADbObject
  implements SelfParenting
{
  private ForeignKey<Folder> parent;
  ...
  public Folder getParent(final Database db)
    throws DbException
  {
    return db.fetch(parent);
  }
  ...
}

and

public class Category extends ProjectBDbObject
  implements SelfParenting
{
  private ForeignKey<Category> parent;
  ...
  public Category getParent(final Database db)
    throws DbException
  {
    return db.fetch(parent);
  }
  ...
}

Obviously, we’re going to want more functionality than just getParent() if our interface is going to be useful. What about methods for getting the children or the depth in the tree? So we add these to our interface:

public interface SelfParenting
{
  SelfParenting getParent(Database db) throws DbException;
  SelfParenting[] getChildren(Database db) throws DbException;
  int getDepth(Database db) throws DbException;
}

And this is where we run into the multiple inheritance wall. The implementation of getChildren() and getDepth() require more than one line, and the code will be exactly the same in both Folder and Category. First, let’s look at what the code might look like for the Folder class:

public class Folder extends ProjectADbObject
  implements SelfParenting
{
  private ForeignKey<Folder> parent;
  ...
  public Folder getParent(final Database db)
    throws DbException
  {
    return db.fetch(parent);
  }

  public Folder[] getChildren(final Database db)
    throws DbException
  {
    final Collection<Folder> children =
      new ArrayList<Folder>();
    for(final Folder folder : db.fetchAll(Folder.class))
    {
      if(folder.getParent(db).equals(this))
        children.add(folder);
    }
    return children.toArray(new Folder[0]);
  }

  public int getDepth(final Database db)
    throws DbException
  {
    int depth = 0;
    Folder folder = this;
    while(folder.getParent() != null)
    {
      depth++;
      folder = folder.getParent(db);
    }
    return depth;
  }
  ...
}

Obviously, the code will be identical in the Directory class. Is there any way to avoid this code duplication? What if we put the code into static methods of a static inner class of the interface? Like so:

public interface SelfParenting
{
  SelfParenting getParent(Database db) throws DbException;
  SelfParenting[] getChildren(Database db) throws DbException;
  int getDepth(Database db) throws DbException;

  public static class Impl
  {
    public static <T extends SelfParenting>
    T[] getChildren(final Database db, final T parent)
      throws DbException
    {
      final Collection<T> children = new ArrayList<T>();
      final T[] all = db.fetchAll(parent.getClass());
      for(final T possibleChild : all)
      {
        if(possibleChild.getParent(db).equals(parent))
          children.add(possibleChild);
      }
      return children.toArray(new T[0]);
    }

    public static int getDepth(final Database db,
                               SelfParenting node)
      throws DbException
    {
      int depth = 0;
      while(node.getParent() != null)
      {
        depth++;
        node = node.getParent(db);
      }
      return depth;
    }
  }
}

Then, the implementation of the new methods shrink down to one line:

public class Folder extends ProjectADbObject
  implements SelfParenting
{
  private ForeignKey<Folder> parent;
  ...
  public Folder getParent(final Database db)
    throws DbException
  {
    return db.fetch(parent);
  }

  public Folder[] getChildren(final Database db)
    throws DbException
  {
    return Impl.getChildren(db, this);
  }

  public int getDepth(final Database db)
    throws DbException
  {
    return Impl.getDepth(db, this);
  }
  ...
}

And so the proper implementation of Category will be the same:

public class Category extends ProjectBDbObject
  implements SelfParenting
{
  private ForeignKey<Category> parent;
  ...
  public Category getParent(final Database db)
    throws DbException
  {
    return db.fetch(parent);
  }

  public Category[] getChildren(final Database db)
    throws DbException
  {
    return Impl.getChildren(db, this);
  }

  public int getDepth(final Database db)
    throws DbException
  {
    return Impl.getDepth(db, this);
  }
  ...
}

By moving the common implementation of the getChildren() and getDepth() methods into the interface (via a static inner class), we have eliminated the duplication of code, thereby enhancing the maintainability and enabling future implementations of SelfParenting to be trivial one-line methods.

The code above is obviously very inefficient², but it was provided to demonstrate a point: that the advantages of multiple inheritance can be achieved in java via this “static methods in a static inner class in the interface” coding pattern.

Class Diagram

¹Note that this accomplishes the code reuse feature of multiple inheritance only. In theory, you could get the effects of polymorphism by doing more than, or something other than, just call the static implementation in the interface.

²A proper implementation of getChildren() would involve SQL where clauses. There are also generics issues that would cause the code, as shown, to not compile. The concept remains sound.

Related Photos

No related photos.