title: Proper namespacing (or class naming) convention in Swift frameworks (for iOS)
body: <p><strong>TLDR</strong></p>
  
  <ol>
  <li><p>If framework is called <strong>AEConicalGradient</strong>, should classes in it be called <strong>ConicalGradientLayer</strong> and <strong>ConicalGradientView</strong> or just <strong>Layer</strong> and <strong>View</strong>?</p></li>
  <li><p>If framework is called <strong>AELog</strong>, and it has class also called <strong>AELog</strong> and other class called <strong>Line</strong> with some delegate callback which is using this <strong>Line</strong> type, how to implement this delegate if your code also has defined type called <strong>Line</strong>, because adding framework name as a prefix in method signature <code>func didLog(line: AELog.Line)</code> will make error <code>'Line' is not a member type of 'AELog'</code> which in fact it isn't (it's part of <strong>AELog framework</strong>, but it's not member of <strong>AELog class</strong> inside of it).</p></li>
  </ol>
  
  <p><strong>Read More</strong></p>
  
  <p>While updating several frameworks of mine for Swift 3 I was having a lot of second thoughts about what's the proper naming convention for framework classes depending on framework name itself.</p>
  
  <p>In the end I realized that I didn't really used same convention across different frameworks, so now I don't like this lack of consistency.</p>
  
  <p>I'll jump straight into some real-world examples which I encountered:</p>
  
  <p><strong>1. Example: Framework doesn't have a class named as framework name:</strong>  </p>
  
  <p>Framework is named <strong>AEConicalGradient</strong> and it consists of 2 public classes:  </p>
  
  <ul>
  <li>CALayer subclass</li>
  <li>UIView subclass</li>
  </ul>
  
  <p>What should be proper name for each of these classes?</p>
  
  <p>a) <strong>AEConicalGradientLayer</strong> and <strong>AEConicalGradientView</strong></p>
  
  <p>b) <strong>ConicalGradientLayer</strong> and <strong>ConicalGradientView</strong></p>
  
  <p>c) <strong>Layer</strong> and <strong>View</strong></p>
  
  <p><strong>Discussion:</strong>  </p>
  
  <p>a) <em>I used this in the first version of framework with both of these classes in single <strong>AEConicalGradient.swift</strong> file. I don't like this approach anymore, I'm separating sources into multiple files so now I'm thinking between <strong>b)</strong> and <strong>c)</strong> approaches.</em></p>
  
  <p>b) <em>In this approach I like the fact that someone can just drag these files into project (e.g. without using any dependency manager) or copy/paste code and it wouldn't loose context too much (because of clear names), but on the other side it sounds a little bit repetitive if you think of it as <strong>AEConicalGradient.ConicalGradientLayer</strong> and <strong>AEConicalGradient.ConicalGradientView</strong>.</em></p>
  
  <p>c) <strong><em>AEConicalGradient.Layer</strong> and <strong>AEConicalGradient.View</strong> sounds like the way I want it, but on the other side those are more likely to make a conflict if someone has their own <strong>Layer</strong> or <strong>View</strong> classes, or if they just drag files or copy/paste code context is pretty much lost (like what is this <strong>Layer</strong> or <strong>View</strong> class for?).</em></p>
  
  <p><strong>2. Example: Framework does have a class named as framework name:</strong></p>
  
  <p>Framework is named <strong>AELog</strong> and it consists of 3 public classes and a delegate protocol:</p>
  
  <ul>
  <li>Shared Instance (and delegate for it)</li>
  <li>Log Line model</li>
  <li>Config</li>
  </ul>
  
  <p><strong>Discussion:</strong></p>
  
  <p>a) <em>Similar to the first example in the first version of framework I had classes named <strong>AELog</strong>, <strong>AELogDelegate</strong>, <strong>AELogLine</strong> and <strong>AELogConfig</strong> - all inside single <strong>AELog.swift</strong> file.</em></p>
  
  <p>b) <em>In the latest update for Swift 3 I ended up with multiple files and class names: <strong>AELog</strong>, <strong>AELogDelegate</strong>, <strong>Line</strong> and <strong>Config</strong>.</em></p>
  
  <p><em>That's when I realized that if you <code>import AELog</code> and implement <code>AELogDelegate</code> (which has only <code>func didLog(line: Line)</code>) AND you already have a different <code>Line</code> class defined in your own module <strong>it will make a conflict which can be solved only by renaming one of those two <code>Line</code> classes!</em></strong></p>
  
  <p><em>To be honest, I don't really understand how to avoid this. Because if you try to namespace type in delegate method like <code>func didLog(line: AELog.Line)</code> you'll get error <code>'Line' is not a member type of 'AELog'</code> which in fact it isn't (it's part of <strong>AELog framework</strong>, but it's not member of <strong>AELog class</strong> inside of it).</em></p>
  
  <p><em>That's when I started to feel a bit concerned on this "loose" naming. Any suggestions or opinions on this specific matter?</em></p>
  
  <p>c) <em>In the spirit of very "loose" naming like in <strong>1.c)</strong> approach, is it ok to rename <strong>AELog</strong> class to just <strong>Log</strong>, and <strong>AELogDelegate</strong> to just <strong>Delegate</strong>? Would this fix error stated in <strong>2.b)</strong> because there's no class named same as framework name so maybe compiler would recognize <strong>AELog.Line</strong> in that case?</em></p>
  
  <p><strong>Question:</strong><br>
  What are some "clean code" arguments on either of these approaches? Is there an obvious "proper" way on how it should be done? Am I missing something important here?</p>