Archive for February, 2019

Bad things: Extension Access Control

Swift extends the courtesy of an access control annotated extension to its top level members. I’m going to call this “inheritance”, but I know there’s a better name for this but I just don’t know what it is.

Consider the following:

// Base type is public
public struct MyStruct {}

// Here, the extension is declared public, so each top level member
// "inherits" that access level.
public extension MyStruct {
  // This is public even if it is not annotated
  static var firstValue: String { return "public" }

  // This is also public but the compiler will warn.
  public static var secondValue: String { return "public but warned" }

  // This class is also public via "inheritance" 
  class PublicSubclass {
    // However, its members must be annotated. This is public
    public static let publicValue = "public"
    // This defaults to internal
    static let internalValue = "internal"
  }
}

In this example, firstValue inherits the public access level from the MyStruct extension. The explicit annotation for secondValue is warned by the compiler as unnecessary.  If you treat warnings as errors, that’s a problem.

Each of the static properties are accessible outside the module except for internalValue, as even in a public class declaration, its members do not inherit its control level:

Before I start putting some preliminary style guidance out there, I’d like to point out a few more things about this. Here’s a second example:

internal class InternalType {}

extension InternalType {
  public static var value: String { return "value" }
}

Swift compiles this code without error. It is clearly a developer-sourced issue. The intent to make the member public is fundamentally flawed. as it exceeds the type’s access control level. This issue also exists outside of extensions, where the compiler will not warn on too-high levels for direct type members:

internal class AnotherInternalType {
  public var value = "value" // no warning
}

You’d imagine this is a place where the compiler should up its game, no? This is a point of code that is technically functional and compilable but whose specification undercuts the documenting nature of using access control. Shouldn’t the annotation be limited and warned here?

The compiler will find mismatches between the extension ACL and the type ACL:

And that’s where the problem comes in because the guidance I’m working on says: “Do not annotate extensions with access control levels except when working with trivial utilities”. Skipping extension ACL ensures that you can meaningfully and intentionally add access control to each member declared within that extension. Each access level is co-located with the declaration it decorates. This makes your code more easily audited and its access levels will be immediately apparent as to intent and implementation.

What are your thoughts? Can you think of any reasons why extensions should ever be ACL’ed in production code? And is this just a bug/language enhancement thing or is there something I’m missing. Thanks in advance for your feedback.

Same blog, different channel

Migration done! Welcome to the new host.

After couple of days of pure hell getting things transferred and set-up, here we are. I don’t want to even think of the billable hour cost for most people making this happen. Change is traumatic.

Ended up going with siteground.com: it has cpanel, email, and WordPress. I was about theeeesclose to going with WordPress.com’s paid plan (huge huge thanks to the wonderful Jeremy Massel). In the end, there were just too many compromises. Even with siteground there were compromises, but at least it’s not Bluehost.

Thank you to everyone for your advice and recs and patience. The only thing I regret is that I forgot to get someone a referral from all this. I apologize.

If you wrote to me in the last day and it was important please try writing again just in case… There was a period of outage where the old mail hadn’t finished updating and the new mail wasn’t fully configured.

I still have to set up my mail on a bunch of different devices, so off to do that…

Fleeing Bluehost: It’s crunch time

I have under 30 days to move from Bluehost or I’ll be locked into another year. If you don’t recall, Bluehost is infuriating. It shuts down whenever I have a traffic spike. Its SSL certificates are not automatically renewed, so every 90 days or so things fail.

My email is associated with unifiedlayer, one of the worst spam providers, which means that a lot of my outgoing email never arrives. Every time I need tech support, they try to upsell me to yet another paid service. The fees have increased and increased over time.

While I’d really love to have a statically generated site, I’m not willing to give up comments. I’m sticking with WordPress as the least turbulent solution unless someone has a better idea.

I need email. I need a wordpress site. I’d like to keep a listserv going but I can probably transfer that to slack if needed. I can’t really think of any other features that I need at this time.

  • Diogene recommended SiteGround. It offers well reviewed WordPress hosting. This sounds scary though: “For migration just use IMAP for your email and synchronize all mail locally then when you move you host sync back again with IMAP”
  • Dave DeLong says FastMail is a great solution for the mail-only axis. Hank Gay, Christopher Frederick, and Dewey concur. Christopher mentions that I can set up “SPF and DKIM records” to provide more secure ownership, whatever these things are.
  • Despite the general love for FastMail, Michael Weaver says iRedMail is a good alternative as well.
  • Matt mentioned nosupportlinuxhosting.com
  • Will suggests A2Hosting. Chris likes ASPnix.com.
  • John Woolsey pitches GreenGeeks.com.
  • Nate H suggests dreamhost (also recced by Tim as a site for “people who don’t know what they’re doing”, which is pretty much me) and siteground.
  • Mark Nichols uses WebFaction, but also supports Digital Ocean.
  • Brian Anderson suggests hostagor.com.
  • Kevin likes the roll-your own AWS solution: S3 for web, EC2 for wordpress, WorkMail for mail. Any thoughts on these?
  • Simon Davies agrees on AWS but suggests hosting email with zoho.com.
  • Dan Messing and Mark Bernstein like pair.com.

I’m looking for the simplest migration with the longest shelf life and the least worries. It should remain reasonably budget affordable as well.

I want to get this done quickly and easily and it scares me to pieces. This is, admittedly, way out of my comfort zone, which explains why I’m still with Bluehost even years after identifying the problems.

Any advice and support will be greatly appreciated.