Blog

Properties are Functions

We currently have two property-related problems to solve for version 2 of the D programming language. One problem is is that having functions callable both without and with empty parenthesis creates ambiguities when it returns a callable type (a delegate, a funciton pointer, or an object with an opCall member). A second problem is that we want properties to be nouns or adjectives, and actions to be verbs. In English a lot of words are both nouns, adjective and verbs, which makes it impractical to distinguish a property from a function by its name alone.

Solving the first problem involves having a way to distinguish functions that can and must be called without parenthesis. Unless we want to force all functions with no parameter to be called without “()”, we must have some kind of flag to tell us wich function expects and does not expect a “()”.

The second problem is more complex. It is about the meaning of a name. Say you have a transform function, you’ll have some expectations about what it does based on the name. So I ask you: is a “transform” function an action (a verb) in the sense that it applies some transformation to an object, or is it a property (a noun or adjective) in the sense that it returns something like an affine transform associated with an object? The semantics of the two are completely different, yet they share the same name.

The real ambiguity here is the English language, were many nouns and adjectives are also verbs. We could switch to a natural language that does not have this problem for function name — say French: “transform” becomes “transformer” (action, verb) or “transformation” (property, noun); “empty” becomes “vider” (action, verb) or “vide” (property, adjective) — but that doesn’t seem like a very practical option.

So, beside switching to a non-English language, we have two other options. First we could write a guideline saying properties (nouns and adjectives) should start with some prefix. I tried it. I couldn’t come with anything sane that works for non-boolean properties. In addition, most people don’t read guidelines, and educating people to write “is”, “has” or a modal verb in front of boolean properties would be a major effort. It works in Objective-C, but the function syntax is very different in Objective-C.

So the only option left, assuming we still want to solve the problem, is to introduce a formal syntax in D to distinguish properties (nouns and adjectives) from actions (verbs). A natural fit for that at the call site is to use the syntax without tailing empty parenthesis for properties, mimicking fields, and use the inherited function syntax from C-derived languages for actions. Choosing the right syntax for property definitions is a greater challenge since we want a simple syntax that helps people make the right choice depending on wether they want a property or an action, this without too much deviation from a regular function either.

As for whether properties should be cheap (not perform anything heavyweight) or not, that’s another debate that could result in a guideline.

This is an adaptation of a message posted on the D newsgroup.

Too Much Icons Is Like Not Enough

Microsoft started the ball a long time ago by making an icon for every possible action in Office so you can put them the overcrowded toolbars. Then, on Windows, they decided they’d do custom-style menus and put those icons in menus beside each command. On Linux, KDE and Gnome followed did the same thing in a much more consistent manner by doing it for all applications, but added icons to dialog buttons. Now, Gnome will get rid of them. Good riddance!

I’ve always found icons distracting in buttons and menus. Placing an icon next to a text caption saying what the icon means is pointless to my eye: I can read as fast if not faster as I can decipher an icons, but the text is more descriptive and thus more useful. Having both icon and text adds pointless noise to a button or a menu item.

That said, an icon is not useless if it adds some useful piece information: a file or folder icon next to its name is perfectly justified since it can give a better idea of what it is. Same for a checkbox icon.

Neither do I oppose to icon-only buttons: they save space when needed, and are generally perform sufficiently different actions for giving them distinguishable icons. The arrows in the toolbar of your web browser for instance are a good example of this.

Having to find an icon for each button and menu command makes creating quality application more difficult. With Gnome, if your button doesn’t have an icon it’ll look out of place. On the other side, creating or finding a relevant icon for each button in your application can be a difficult task. This difficulty often results in suboptimal icons being selected, or identical icons for different task. For instance, what’s the difference between a “save” icon and a “save as” icon?

Someone in the comment of a OSnews article on the subject liked above pointed out that such icons are optionals in KDE, and shows us what it looks like with and without them. Which screenshot do you like better?

MobileSafari-friendly

I wanted for some time to make my website iPhone/iPod Touch friendly. I tentatively did something a little more than a year ago by adding some media queries to my stylesheet so that the already existing @media handheld rules would apply to the iPhone too. Once tested however, the result wasn’t too great. Now, I just got a new iPod Touch, allowing me to experiment further.

The goal is that you don’t need to zoom to read the content, scrolling is all you should need. The technical constrains I settled upon:

1. There should be no separate page for MobileSafari. Although it’d certainly have been possible, my pages are already lightweight enough so that it makes things pretty unnecessary.

2. This is entirely a presentation issue, there should be no special markup in the webpage. All should be done through CSS.

This last constrain was a little problematic given that Apple decided for some reason that the viewport for the page should be put in a meta tag in the head of the HTML file, this way:

<meta name="viewport" content="width=808" />

So I’m left with no possibility of setting the content width in virtual pixel, and MobileSafari isn’t clever enough to figure out that when I’m not using the whole width 980 virtual pixels and size things accordingly.

I finally settled using the -webkit-text-size-adjust CSS directive (specific to MobileSafari) to increase the text size until the page covers the whole screen width. The downside of this approach is that images are a little too small, but since this website is mostly about text, and since you can easily zoom on images on an iPhone, there’s not much harm.

Now, there is a lot more in my handheld/MobileSafari stylesheet, notably using Helvetica instead of Palatino and reflowing a little the layout of the main page to avoid having two columns. And I like the result, since you almost never need to zoom on anything anymore.

And I’m just now realizing that with the iPhone SDK available for free from Apple, you don’t have to have the actual device in hand to test your website with MobileSafari. The SDK contains an iPhone Simulator that includes MobileSafari which is perfectly fine for testing. The only thing you’ll miss is how it looks on the high-resolution screen of the iPhone/iPod Touch… and perhaps how hard it is to hit things with your fingers.

Reference

• A list Apart: Put Your Content in My Pocket

Problems with Multi-Safari and Anti-Spam Measures

As many of you have reported, the Multi-Safari downloads have stopped working in the last two days. This is now fixed. And while I couldn’t reply to everyone, I also had some difficulty answering some emails because my provider’s outgoing mail server appears to have been put on a temporary blacklist for having sent spam. This should resolve itself, at least I hope.

So to everyone who relied on Multi-Safari being available, and all of you that wrote to me without getting a reply, sorry for the inconvenience.