roncli.com blog: July 2014

One thing I've always appreciated is open source software initiatives. Of course, in the beginning it was more an appreciation of "thank you for letting me use your stuff for free" without giving back. Over time, though, I've embraced the promise of open source. With LibWowAPI, I put out a .NET library that some found useful enough to contribute back to the project. It's awesome when you get other people interested in what you do.

Another thing I've grown to love is bleeding edge technology. While it took me forever to adapt .NET, I'm now always keeping on top of the latest and greatest technologies.

With these shifts in mentality, I've managed to learn things like Node.js and rendr simply by diving in and trying them. But lately, just trying hasn't been enough.

I've moved the source code of roncli.com to GitHub, and with it is a new Node.js code base that uses rendr. I just recently finished the login, registration, and forgot password work flows, which was a big step. But now I've sidetracked myself into upgrading the tools that rendr uses.

Specifically, I came up on an issue with Browserify and Grunt. I upgraded Browserify and some of its dependencies to the latest version, but this completely broke rendr, even when I fixed my configuration files to work with the latest version of everything.

It took me a couple of days, but ultimately I found the problem was mainly lack of Windows compatibility with some of the dependent projects these bigger projects use. Since ultimately I plan to have my website on a Windows server but want to have the flexibility to move to another server if I need to, I debugged the issue and found that there were three separate projects that had bugs.

Within two days, I have created three pull requests to fix the issues I am seeing, all with the goal of getting rendr to work with the latest and greatest of all the modules rendr is using. It's kind of cool, because contributing back to these projects means I'm not only helping myself, but hopefully I'll be helping a lot of other people out in the future as well.

Labels: Browserify, Coding, Grunt, LibWowAPI, Node, Open Source, Rendr, roncli.com

Wednesday, July 02, 2014

The Diamond Problem
Posted: 4:25:00 PM 0 comments

When I was learning .NET, one of the things I learned early was that .NET does not support multiple inheritance. Multiple inheritance is having one class be inherited by more than one class. I never had a need to do anything like this for the longest time, so I never really thought twice about this.

Recently, however, I came across a potential use for multiple inheritance. I came across an open source library used in a project I was working on. The library was heavily modified, with multiple fields and methods, both private and public, being added, removed, and changed. It was pretty serious. Of course, the open source project was updated over the years, but since our copy of it was so heavily modified, we could not upgrade.

At first, I thought a good resolution would be splitting out the customized logic from the main project into a derived class, which would allow us to upgrade the project without breaking the custom logic. And this sounded great.

That is, until I realized that there were a number of classes in the open source project that ALREADY inherited from classes within the same project.

I now have a problem. Let's say I have 3 classes:
* Class A, which is the base class from the open source project.
* Class B, which is the class from the open source project that inherits the base class.
* Class C, which is the base class with our customizations that inherits the open source project's base class.

I now need to implement the custmoizations that were made to Class B into a new class, which I'll call Class D. The customizations that were made to Class B depend on the customizations that exist in Class C, but I also need some of the base methods and fields in Class B. Ideally, I want to create Class D to inherit from BOTH Class B AND Class C. But I can't: .NET doesn't allow it. Why?

Because of something known as The Diamond Problem. If I create Class D which inherits from Class B and Class C, and each of those classes inherit from Class A, I could theoretically create methods in Class B and Class C that are based on methods in Class A. When I call those methods from Class D, how do I know whether I need to call the method from Class B or from Class C?

It's called The Diamond Problem because of how the class diagram would look if you mapped out the classes: Class A would be the top point, Class B and Class C would be the left and right points with a line coming to each of them from Class A, and Class D at the bottom with a line coming to it from each of Class B and Class C.

The problem is clear. However, the solution is not. There is no clear cut way for me to construct a Class D that has the functionality I need. There are some very ungraceful workarounds, including copy and pasting code, using multiple interface inheritance, or instantiating the classes you want to inherit as properties of the derived class. None of these solutions are perfect for varying reasons.

In this case, we want to be able to update the open source project as needed, but we want to maintain the customizations that were made to it. Other than multiple inheritance, how would you resolve this?

Labels: Coding, Diamond Problem