Clear cutting

I’m terrible at enjoying a success, because as soon as I get something to work, I lift my gaze to the next horizon. Previously I got close to finding all possible concrete types for:

privatePrevAccessible->SetParent(this);

However, I had cheated by only building the parts of the tree that I knew contained what I wanted. I also got back the type itself, so B+. My trouble was that I needed a way to get at multiple levels of inheritance for a type, in order to find the right method. To recap, privatePrevAccessible is really nsPIAccessible, and I need to know all of the concrete types that this could be. Working backwards, there are two: nsAccessible and nsHTMLListBulletAccessible.

nsAccessible is pretty easy, since nsPIAccessible is a direct base class. However, nsHTMLListBulletAccessible is an nsPIAccessible only by marriage:

nsHTMLListBulletAccessible : nsHyperTextAccessibleWrap : nsHyperTextAccessible : nsAccessibleWrap : nsAccessible : nsPIAccessible

My trouble was that I was doing things the proper way, and carefully recreating the entire inheritance tree recursively in the database. This made it difficult (I won’t say impossible, but I want to) to get from nsHTMLListBulletAccessible to nsPIAccessible without working way too hard in SQL.

Being a fan of the “worse is better” philosophy of programming, I decided that I wasn’t smart enough to solve the problem as given. Instead, I decided to flatten the inheritance tree for each type, and simply record relation from concrete class to base classes, but not retain the structure–I don’t actually need the authentic view of the class hierarchy [ed. I'm sure this will come back to haunt me, but I'm happy right now]. And it worked! My db still needs some pruning, and the SQL needs to be optimized, but I can quickly and easily go from nsPIAccessible->SetParent(nsIAccessible*) to nsAccessible->SetParent(nsIAccessible*) and nsHTMLListBulletAccessible->SetParent(nsIAcessible*) in one step. Lesson: when you can’t find something in a forest, cut down the trees [ed. this advice should not be applied outside the computing space without more study].

So as I said at the beginning, I don’t know when to stop and smell the roses. As soon as I got this working, I took a look at the source lines where deyhdra was pointing me for both methods:

  • NS_DECL_NSPIACCESSIBLE
  • NS_IMETHOD SetParent(nsIAccessible *aParentAccessible);

Not exactly what I was hoping for. After chatting with Dave a bit last night on irc, I’m going to see if I can exploit process_function() and .methodOf to separate decls and defs. Can you spell F-U-N?

If I stop for a minute to think about everything I still need to do I get totally discouraged, so I’m trying to follow my own advice and make baby steps every day. Pretty soon I’m thinking I’d better do a prototype web front-end so you can play along at home.

This entry was posted in CDOT, Seneca. Bookmark the permalink. Both comments and trackbacks are currently closed.

One Trackback

  1. [...] properly, but it’s satisfying enough to do before I quit. If you’ve been following my progress, you’ll know that I’ve been trying to solve Dave’s mxr-dehydra challenge, looking [...]