You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal supersedes #1, which was tentatively abandoned. This proposal is a breaking API change predicated on the approval of improved key paths in swift SE-0161.
New Text Table Creation
I propose a new API for constructing a TextTable instance. In particular, the way column definitions are mapped to values. Column/value mapping will be defined via a dictionary of key paths to columns.
Current API
The current API uses an initializer that takes a closure which is expected to return an array of column definitions given an instance of some row type Person.
We can't get the column definition without a value passed to the closure, so a dummy value (the instance for the 0th row) is passed to get the column names.
When computing column widths we actually want to traverse all the values of one column at a time, but we are forced to get the whole row each time.
The column definition itself loses the type information of the value, storing it in an Any.
New API
With the new API, TextTable will conform to ExpressibleByDictionaryLiteral. A TextTable<T> will be created by using a dictionary literal of [PartialKeyPath<T>: Column].
The above snippet of code is just short hand for the following (Column will conform to ExpressibleByStringLiteral, so Column does not have to be explicitly constructed):
The above snippet is also short hand for the following code. This example illustrates the default values that are used when you leave out the optional arguments. Typically you would only provide arguments where you want to customize the specific column.
You would never type this out, but for illustration purposes here is an even more explicit version. Once again, this is equivalent to all the previous examples:
Another change to consider: Extending String with an init for TextTable instead of using a string(for:) method.
lets=String(table: table)
Instead of
lets= table.string(for: data)
Stream Print
TextTable tries to be memory efficient. It will not copy the contents of your collection, instead it will call back to your collection whenever it needs a value.
Currently the print method on table just creates a string using the aforementioned API and just passes it to Swift.print. The next version will instead stream the contents of the table to Swift.print roughly line-by-line as the table is generated.
Conformance to Sequence Type
TextTable will actually conform to swift's Collection (or maybe just provide a Sequence). This will let one lazily pull the string parts of the rendered table.
The text was updated successfully, but these errors were encountered:
This proposal supersedes #1, which was tentatively abandoned. This proposal is a breaking API change predicated on the approval of improved key paths in swift SE-0161.
New Text Table Creation
I propose a new API for constructing a
TextTable
instance. In particular, the way column definitions are mapped to values. Column/value mapping will be defined via a dictionary of key paths to columns.Current API
The current API uses an initializer that takes a closure which is expected to return an array of column definitions given an instance of some row type
Person
.This has a few disadvantages:
Any
.New API
With the new API,
TextTable
will conform toExpressibleByDictionaryLiteral
. ATextTable<T>
will be created by using a dictionary literal of[PartialKeyPath<T>: Column]
.The above snippet of code is just short hand for the following (
Column
will conform toExpressibleByStringLiteral
, soColumn
does not have to be explicitly constructed):The above snippet is also short hand for the following code. This example illustrates the default values that are used when you leave out the optional arguments. Typically you would only provide arguments where you want to customize the specific column.
You would never type this out, but for illustration purposes here is an even more explicit version. Once again, this is equivalent to all the previous examples:
String Constructor Instead of String Method
Another change to consider: Extending
String
with aninit
forTextTable
instead of using astring(for:)
method.Instead of
Stream Print
TextTable
tries to be memory efficient. It will not copy the contents of your collection, instead it will call back to your collection whenever it needs a value.Currently the
print
method on table just creates a string using the aforementioned API and just passes it toSwift.print
. The next version will instead stream the contents of the table toSwift.print
roughly line-by-line as the table is generated.Conformance to Sequence Type
TextTable
will actually conform to swift'sCollection
(or maybe just provide aSequence
). This will let one lazily pull the string parts of the rendered table.The text was updated successfully, but these errors were encountered: