During a recent project of mine, I had to do a lot of enum manipulation using the .NET Enum class and I have to say I wasn't impressed. Besides the shortcoming of it not being a generic class (and thus not being especially type-safe), Enum also has some strange inconsistencies in terms of how it handles matched integral types.
As I was working on the PHP classes that Fep was to map to, I realized that it was rather silly for me to re-invent an API for lists since there were already many well-designed ones in existence. In particular, I've found that the .NET 3.5 collections API to be particularly nice to use. Moreover, since everyone and their dog and using .NET now, it would also be familiar to most programmers. Thus, I've decided to use a subset of the .NET collections API for Fep collections.
In this article, I'll write a bit about how I think Fep arrays will look. Keep in mind this a work in progress and is by no means comprehensive. Without further ado...
In PHP, you define an array using the array() construct. Fep will follow the lead of languages like JavaScript, Python, Ruby and Groovy and use the square bracket [] notation.
Initialization
For example, a simple array in PHP is creating like this:
PHP bugs me. It's a language with so many inconsistencies, it's just screaming to be cleaned up. I'm surprised it hasn't happened yet. That's why I'm starting a series of articles on Fep, a cleaned up version of PHP.
I recently spent a couple hours yesterday to fix a problem I was having with my custom EnumStringType (see this post).
Basically, what was happening was when my repository was making a call to ICriteria.List(), which in turn called the Set method of EnumStringType, it was always passing in a lowercase string instead of an enum instance.
NHibernate lets you map C# enums to database columns. This can be quite convenient in cases where you have a database column for something like gender. To map them, you follow the procedure outlined here.
That works all fine and dandy, as long as the strings you want to store in the database are valid C# identifiers.
As someone who has had to write a lot of IE-only code (against my will, I swear!), I was pleased to hear that Firefox 3.0 added support for the IE JavaScript function window.showModalDialog. Being in the middle of re-writing an IE-only web application, I thought this would simplify rewriting the modal dialogs to be compatible with both browsers.
Unfortunately, I don't think the folks at Mozilla put their best effort into this one.
Recently, I've started a fairly large project in C# 3.0. As it happens, there came a point where I wanted to use a pattern similar to Bloch's Builder. However, as anyone who tries to use this pattern in C# will quickly find out, Bloch's Builder doesn't translate perfectly to C#.
It would've been a helluva lot faster to have had some sort of conversation table. After a little searching on Google, I found nothing so I decided to make one myself. Behold, the fruits of my labour!