time icon indicating copy to clipboard operation
time copied to clipboard

Hide Internal Public Types

Open Mordil opened this issue 3 years ago • 3 comments

Motivation

LTO* and GTO* prefixed protocols act as markers for conditional conformance clauses, and as such need to be public symbols, but for all intents and purposes they are internal to Time.

This means these types appear in autocompletion as well as have symbol documentation generated in DocC.

Changes Made

  • Change: LTO* and GTO* prefixed protocols to be prefixed by _

Results

The swift compiler will "hide" _LTO* and _GTO* symbols for purposes such as DocC and autocompletion while still leaving them public.

Mordil avatar Oct 31 '21 06:10 Mordil

I thought about either namespacing or prefixing things related to Template as well - but decided against it, as it seems there's some requests to make Template more generally useful or configurable by consumers of the Time library.

For example #53

I also was hesitant to propose any changes, as there is some usefulness to allow developers to create variables of templates without having to use or lookup _ prefixed types for whatever reason they may want to:

func format(using template: Template<Year>) {
  self.first = firstDate.format(year: template)
  self.second = secondDate.format(year: template)
}

--

In hindsight, this reason could be argued for the LTO* and GTO* protocol types as well... as people might want to write their own algorithms or such for all the different units... 🤔

Mordil avatar Oct 31 '21 06:10 Mordil

I'm torn on this. I get the point of using the underscore to de-emphasize their usage, but the [LG]TOE protocols are also necessary for context-specific extensions. I think that will be even more important once work begins in earnest on the relative time periods.

I'd be open to namespacing the protocols, potentially:

public protocol _LTOEEra { ... }
public enum LTOE {
    public typealias Era = _LTOEEra
}

extension TimePeriod where Largest: LTOE.Era { ... }

Although I'm not sure what that would really get us other than being nifty.

davedelong avatar Oct 31 '21 19:10 davedelong

This is entirely fair and in hindsight I think I was a little too earnest in proposing this.

we can probably close until a discussion happens on the purpose of the protocols in terms of usage.

where I was coming from is the DocC engine exposes these types, and AFAIK they only way of hiding symbols is by using the prefix, and my understanding of the library is these types are not meant to be conformed to

Mordil avatar Oct 31 '21 22:10 Mordil