I'm a big fan of certain aspects of Object-Oriented software development, one being information hiding. Not in a way that makes it hard to extend classes, but in order to keep the public API as small and neat as possible. That means favouring protected over private, but often I want a read-only or write-only property in the public API, while still supporting binding (or any other processing on set). This can be a problem at compile time when you'd like to be able to use both internally, however. Take the following code snippet of real code:

//----------------------------------
// selectedUser
//----------------------------------

private var _selectedUser : User;

[Bindable("selectedUserChanged")]
public function get selectedUser() : User
{
    return _selectedUser;
}

protected function set selectedUser(value : User) : void
{
    if (_selectedUser == value)
        return;

    _selectedUser = value;
    dispatchEvent(new Event("selectedUserChanged"));
}

//----------------------------------
// Selection callback
//----------------------------------

public function selected(item : Object) : void
{
    if (item == null || displayUsers.contains(item))
        selectedUser = User(item);
}

MXMLC will give us "Error 1000: Ambiguous reference to selectedUser" when we try to compile this code. Namespaces to the rescue! Did you know you can use public, package, protected and private just as you would a normal namespace in most cases? The solution to this particular problem then becomes:

public function selected(item : Object) : void
{
    if (item == null || displayUsers.contains(item))
        protected::selectedUser = User(item);
}

You may note that instead of a protected accessor, I could have cooked up a protected setSelectedUser() function. Which is true, but using the namespace prefix allows me to retain the assignment operator, which I find clearer.