Oftentimes, older databases will keep a date in one column and a time in one column despite both columns being of type DateTime. So, before, I was combining two DateTime objects this way.
DateTime c = new DateTime(a.Year, a.Month, a.Day, b.Hour, b.Minute, b.Second);
Yesterday, I realized there is a much better way.
DateTime c = a.Date + b.TimeOfDay;
Shorter. Easier to read. More accurate. Runs faster.
First off, I have a Chromebook now. It is fantastic.
Anyway, private member variables represent encapsulation at its finest. Hidden components allow a class to determine its own implementation to satisfy the public interface’s demands. By now, I am firm believer that absolutely no member variables should be marked public.
Protected member variables, on the other hand, have always left me indecisive. Are they good? Are they bad? I admit that there have been times that I have extended a class, decided I wanted access to its data, and changed several variables from private to protected. This always felt wrong somehow. Basically, even though that data is sheltered from the outside world, it felt leaky. Should some other class really be able to simply extend that class and gain access to its darkest secrets?
After reading some commentary around the web and messing with a few designs myself, I have come to this conclusion: member variables should always be marked private. Even if I anticipate extending that class, private member variables should be insulated through getters and setters. This does two things for me. First, I empower the base class to later add rules to how it accesses the private data (and even change the data being accessed to other things). Second, it forces me to consciously and carefully expose private data rather than lazily change the specifiers.
I know my opinion will not satisfy everyone. I know any absolute declaration will instantly be met with anecdotes of how having an exposed protected member variable was vital to a specific design situation. However, I have enough experience designing large systems that I feel comfortable making this declaration. I have enough confidence in this restriction to where, if I ever get around to building my own language, it will likely enforce a compiler rule that all class member variables are private always and forever.
So, the short version is this: only functions should ever consider being protected; variables should always be private.
I have had plenty of discussions with supporters of scripting languages. I am not a fan of dynamic languages, but I understand the appeal. I have been working on designing my own scripting language, and I want to take a common concept to a new level.
PHP, Lua, and other languages let you read as many function parameters as the caller provided. In other words, despite my function being defined as calculate(a, b, c), I can still call calculate(1, 12, 99, 52, 0, 2, -13, 'hello', nil, 7). Inside the function, I use special functions to request parameters beyond the ones requested by calculate. If that is the case, why bother with parameters at all? The definition should contain function calculate and proceed right into the body of the function.
function calculate
total = 0
for value in parameters
if value is number do total = total + value end
end
return total
end
As it is right now, I have to refer to documentation to know what types the parameters are anyway. So, I say, unify the parameter mechanisms and force documentation on every function!
So, here’s a question: why are female video game protagonists so rare? Their absence is palpable, and we talk often of how we want to see more of them, but the why of it is typically addressed with generalizations about target audiences and a lack of women in game development. Penny Arcade Report senior editor Ben Kuchera wanted better answers than that, so he did what any red-blooded gamer would do — he found some numbers to crunch.
This sooo very much, this:
Where do I even start? What is there to say? I could talk about how I want to smash my head against the wall when I think of how Portal managed to surprise us with a female protagonist twenty years after Metroid came out. I could talk about how this article made me think of Assassin’s Creed III: Liberation, a game with an intriguing, awesome-sounding woman of color at the helm, whose exclusive release on a poorly-selling handheld console I completely forgot about thanks to a lack of marketing fanfare. I could talk about circular logic and player statistics and gender portrayals and all the other arguments that have been made a million times before. But while I find the things described in that article frustrating for a plethora of reasons, if I step back, I know that this problem wasn’t born in a vacuum. This isn’t something I can argue from a standpoint of gender equity or good storytelling, because at its core, it’s not about that. It’s about money, and it’s about everything that’s wrong with how the gaming industry works.
Wait… women are upset that male protagonists are a dime a dozen? Shouldn’t they be GLAD they are placed upon a pedestal and used to surprise the audience? Do you REALLY want a ratio closer to 1:1 of male to female protagonists? I really don’t think you know what you’re asking. The industry is fine as it is.
[EDIT] Woooow… OK, I read the whole article. It’s worse than I thought. People are reading numbers and producing absurd conspiracy theories from them. How about this? Most gamers are male. Most engineers are male. Therefore, it is easier for most developers to write games about males as they better understand the male psyche. I have to call bullcrap on this idea that game studios choose male protagonists because they sell better. Like really? A writer brings the transcript to the boss, and the boss says, “Nope. No female heroes. Go rewrite it with a male hero.”
This article was written by someone with too much time on their hands.
Oh spoken language.
It’d be confusing to be an alien landing and having to learn these things. (I’m sure this sort of thing happens with culture shock, too).
(1) I never said she stole my money, but someone else might have.
(2) I never even remotely implied she stole my money.
(3) I never said she stole my money; I wrote it down.
(4) Someone stole my money, but it was not her.
(5) She did something with my money, but it wasn’t exactly stealing.
(6) You have the wrong victim. She took someone else’s money.
(7) I have all my money. She took my laptop.
I’m coding up a lexer at the moment. The parser, compiler, and run-time come next. It is extremely entertaining so far. I’ve always derived sick pleasure from string manipulation and string processing in C (areas that most developers avoid like the plague).
I’m working on a new scripting language. It is primarily for research. I just want to see if I can do it. I do not have some maniacal plan to replace Lua in my projects or anything. It just brings me great satisfaction to author a language spec and be able to tweak the syntax however I see fit. Also, that is part of the research: learning how flexible the syntax/language is after it’s implemented. I want to be able to add/remove language keywords and operators at will.
Comment, ALWAYS COMMENT!!!
Unless you end up with what I will now call “comment cement”, where there’s so much commented code you can’t see what you’re doing anymore.
Source Control!!
Don’t comment that stuff out- remove it! This is what source control is for!
Secondeded’d. Delete it. Commenting it out implies it will return at some point, and it just confuses future devs. Git will preserve your history for you. ;)
