Blog #6

Your blog entry must explicitly answer the following questions about the class (mark the questions in bold in your post):

• What are you most proud of doing last week?

I answered all quiz questions correctly.

• What ability or skill did you use to make that moment the most proud of?

I know C++ pretty well and I’ve always been good at multiple-choice tests.

• What impact did what you do have on other people?

Based on Ed posts, I think my Voting.ctd.txt continues to be popular. I also helped a fellow student in CS 354R get lldb working on his MacBook.

• What did you think of Paper #6. The Open-Closed Principle.

When you publish code for others to use, you want to guarantee API stability. That means you want to design your API so that it affords you the ability to extend it in the future without breaking your clients. In that context, the open-closed principle is a useful guideline.

The paper is pretty bad. Just as one example, here’s how it defines “closed for modification”:

The source code of such a module is inviolate. No one is allowed to make source code changes to it.

Really? You’re never allowed to change it? What if there’s a bug? What if it uses an inefficient algorithm and needs to be made faster?

I think there is a sensible interpretation of the Bertrand Meyer quotation in the intro of the paper, but I don’t think the paper uses a sensible interpretation.

• What did you think of reverse(), iterator_tags, const methods and friend functions?

It’s nice that C++ supports defining function overloads so a better algorithm can be used when the arguments satisfy the requirements. However, iterator tags are a hack to make up for a historical deficiency in the C++ type system and could have been designed much better. Const methods are a great idea. Friend functions are a thing that exists; sometimes there’s no particularly good alternative.

• What made you happy this week?

I learned how to use root motion in Godot, which will let me make my next CS 354R project look ever so pretty.

• What’s your pick-of-the-week or tip-of-the-week?

Visual Studio Code has a feature called “multi-root workspaces”. A multi-root workspace lets your store your workspace settings in a file you name (with the extension .code-workspace), anywhere you want, instead of inside a .vscode folder under your workspace root. On a team project, you and each of your teammates can use a separate .code-workspace file to store your personal settings in files that are tracked by Git. You get the benefit of tracking changes to your settings, while not interfering with your teammates’ settings.

See you next week!