roncli.com blog
The blog of roncli
roncli.com blog
roncli.com
blog
Profile
roncli
Houston, Texas, United States
Labels
Coding
CTG Music
Editorials
Games
Miscellaneous
Music
Servers
Silliness
Software
Sports
Trax in Space Beta
Weather
Recent Posts
A Tale of Two Communities
The Final Stretch
A Two Tiered, Untiered OTL
Secretly, you wish you could've done what I did
What have I done since roncli.com v2?
It's Done. It's Finally Done.
The Big Picture is Starting to Wear on Me
A Low Bang to Buck Ratio
win-acme
Overload has truth; next it needs balance
Archives
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
June 2008
July 2008
September 2008
December 2008
February 2009
July 2009
August 2009
September 2009
October 2009
November 2009
February 2010
March 2010
April 2010
June 2010
July 2010
August 2010
September 2010
October 2010
November 2010
December 2010
March 2011
June 2011
July 2011
August 2011
September 2011
October 2011
December 2011
January 2012
February 2012
April 2012
July 2012
November 2012
July 2013
April 2014
July 2014
August 2014
November 2014
December 2014
March 2015
April 2015
May 2015
June 2015
July 2015
September 2015
January 2016
February 2016
May 2016
July 2016
November 2016
March 2017
January 2018
May 2018
June 2018
January 2019
January 2021
February 2021
March 2021
August 2021
October 2021
December 2021
August 2022
November 2022
October 2023
February 2024
Current Posts
Tuesday, July 08, 2014
Open Source Adventures
Posted: 5:53:00 PM 0 comments
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: , , , , , , ,

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: ,