А не надо возвращать nil. Используйте ADT, то бишь в данном случае enum'ы:
enum FooResult {
case Success(Int),
case PEBKACError,
case SomeOtherError(String /*reason*/)
}
func foo(...) -> FooResult { ... }
И при вызове паттерн-матчинг (который вызывающему придется написать, и, соответственно, как-то обработать все ошибки):
switch foo (...) {
case .Success(let result):
...
case .PEBKACError:
...
case .SomeOtherError(let reason):
...
}
Единственное, что здесь плохо — прокидывать придется вручную. Были бы полноценные монады — было бы проще (впрочем, исключения — это по сути и есть классическая error monad, которая неявно подсовывается во все типы).
Вы не поверите, но в Swift как раз функция не может внезапно вернуть nil. Точнее, может, но тогда и тип возврата у нее будет optional, а не просто данный класс — и это нужно явно указывать.
Что-то среднее между C# и Kotlin, но с подсчетом ссылок вместо GC, не memory safe (есть unowned-ссылки), и компилируется непосредственно в нативный код.
Еще, там очень втфная семантика у массивов. Процитирую guide. Для начала, переопредляется смысл термина «immutable», причем очень странным образом:
«Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed.»
Т.е. в Swift immutable-массивы можно изменять, но только одним способом.
Дальше — веселее. Опять же guide, на тему того, что есть value type:
«Structures and Enumerations Are Value Types. A value type is a type that is copied when it is assigned to a variable or constant, or when it is passed to a function. Swift’s Array and Dictionary types are implemented as structures.»
Ну ок, т.е. типы значений как обычно — копируются данные, нет identity. Дальше уже интереснее — массивы и словари тоже являются типами значений. Несколько непривычно, но логика в этом есть — в конце концов, коллекции, это действительно просто данные. И все бы ничего, но у массивов тут опять непонятная магия:
«If you assign an Array instance to a constant or variable, or pass an Array instance as an argument to a function or method call, the contents of the array are not copied at the point that the assignment or call takes place. Instead, both arrays share the same sequence of element values. When you modify an element value through one array, the result is observable through the other. For arrays, copying only takes place when you perform an action that has the potential to modify the length of the array. This includes appending, inserting, or removing items, or using a ranged subscript to replace a range of items in the array»
WTF? Ведь это не просто косяк, это так специально задизайнено… Зачем? И главное, о чем думали дизайнеры, задавая такое неочевидное и нестандартное поведение для наиболее часто используемого типа коллекции?
Ну вот и возникает вопрос — а почему, собственно, copy-item — это не метод на коллекции элементов, раз уж у нас есть методы? По какой логике разделять функционал на коммандлеты и методы, и где его искать в каждом конкретном случае?
(копирование в данном случае — это просто пример, аналогичный вопрос можно задать про любую операцию)
В вашем примере, Name — это как раз данные. Поведение — это методы вроде CopyTo.
Объекты нарушают не столько саму концепцию пайпа, а концепцию шелла в целом. Поведение, обработка данных — это команды. Передача данных от команды к команде — это пайпы. Когда у вас объекты в пайпах начинают нести свое собственное поведение, вся система становится размытой, и непонятно, где именно искать нужное поведение. Например, в чем разница в PS между copy-item и CopyTo()? И почему вообще они существуют как две отдельные сущности с разным поведением?
Правильность подхода статье именно в том, что он позволяет делать это все постепенно. Т.е. сначала определяется некий стандартный протокол для структурированных данных в пайпах с подборкой утилит для удобной работы с ним, и адаптеры для существующих неструктурных форматов. Если это постепенно взлетит, то тогда уже можно будет ожидать и --json из коробки в обычных утилитах.
Я бы скорее сказал, это попытка прикрутить «объектность» к существующему юниксовому пайплайну, не трогая существующие наработки в нем (в отличие от PS, который замещает собой большую часть досовых команд).
И, кстати, более грамотная попытка, имхо. В PS мне активно не нравится то, что в пайпах там именно объекты — т.е. сущности с поведением. Имхо, это противоречит самой концепции «трубы», через которую льются данные, а поведение предоставляют программы с той и с другой стороны.
Посмотрите еще на XQuery. Там вообще полный turing complete с весьма навернутыми запросами а ля SQL — группировки, окна, вот это все.
Единственный недостаток — длинноватый синтаксис для «повышенной читабельности». Но при этом куда более лаконичный XPath является чистым subset, поэтому можно пользоваться в основном им, а FLWOR оставить для сильно навернутых запросов, где эта читабельность реально имеет смысл.
С другой стороны, сам XML как формат явно избыточнен для таких целей, а вот JSON — самое оно.
В некотором смысле это (такая конструкция диска) была фичей. Там ведь не было отдельной кнопки «набор», и тот факт, что ноль был так далеко, позволял иметь которкие номера вроде 01 и 02, которые легко запомнить, но при этом практически невозможно набрать случайно именно из-за этого нуля. При выборе 911 и 999 этот критерий тоже фигурировал.
Тут все упирается в несколько мутное определение понятия object. С одной стороны, написано так:
«An object is created by a definition (3.1), by a new-expression (5.3.4) or by the implementation (12.2) when needed.»
При этом 12.2 — это исключительно temporaries, поэтому про них можно пока забыть.
С другой стороны, если есть вот такой вот код:
int* p = (int*)malloc(sizeof(int));
То в нем *p — это, определенно, объект (точнее, lvalue, которая его обозначает) — хотя ни объявления, ни new здесь не было.
Но есть и 3.8/1, где сказано:
«The lifetime of an object of type T begins when:
— storage with the proper alignment and size for type T is obtained, and
— if the object has non-trivial initialization, its initialization is complete.»
Очевидно, что malloc(sizeof(int)) выделяет память достаточного размера и выравнивания для int. Т.е. вроде как у нас есть int. Но эта память имеет размер и выравнивание, подходящие и для const int, и для volatile int, а на 32-битных реализациях — и для long, и для указателей самых разных типов. Возникает вопрос: сколько объектов на самом деле «создал» malloc?
На эту тему на comp.std.c++ периодически случаются холивары. Распространено мнение, что это такая как бы квантовая штука — т.е. там одновременно разом существуют объекты всех POD-типов, для которых это валидный storage (размер + выравнивание). Т.е. такой неявный union с соответствующей семантикой, в котором, как и в случае с обычным, можно работать только с объектом одного типа за раз, за исключением случаев, оговоренных семантикой union'ов — разница в cv qualifiers, структуры с common initial sequence и т.д.
Если принять это, то в вашем случае там «существует» объект типа volatile char, который и читается через указатель соотв. типа.
И при вызове паттерн-матчинг (который вызывающему придется написать, и, соответственно, как-то обработать все ошибки):
Единственное, что здесь плохо — прокидывать придется вручную. Были бы полноценные монады — было бы проще (впрочем, исключения — это по сути и есть классическая error monad, которая неявно подсовывается во все типы).
А почему? Вы думаете, что, например, V8 JIT оптимизирует хуже, чем LLVM?
Еще, там очень втфная семантика у массивов. Процитирую guide. Для начала, переопредляется смысл термина «immutable», причем очень странным образом:
«Immutability has a slightly different meaning for arrays, however. You are still not allowed to perform any action that has the potential to change the size of an immutable array, but you are allowed to set a new value for an existing index in the array. This enables Swift’s Array type to provide optimal performance for array operations when the size of an array is fixed.»
Т.е. в Swift immutable-массивы можно изменять, но только одним способом.
Дальше — веселее. Опять же guide, на тему того, что есть value type:
«Structures and Enumerations Are Value Types. A value type is a type that is copied when it is assigned to a variable or constant, or when it is passed to a function. Swift’s Array and Dictionary types are implemented as structures.»
Ну ок, т.е. типы значений как обычно — копируются данные, нет identity. Дальше уже интереснее — массивы и словари тоже являются типами значений. Несколько непривычно, но логика в этом есть — в конце концов, коллекции, это действительно просто данные. И все бы ничего, но у массивов тут опять непонятная магия:
«If you assign an Array instance to a constant or variable, or pass an Array instance as an argument to a function or method call, the contents of the array are not copied at the point that the assignment or call takes place. Instead, both arrays share the same sequence of element values. When you modify an element value through one array, the result is observable through the other. For arrays, copying only takes place when you perform an action that has the potential to modify the length of the array. This includes appending, inserting, or removing items, or using a ranged subscript to replace a range of items in the array»
WTF? Ведь это не просто косяк, это так специально задизайнено… Зачем? И главное, о чем думали дизайнеры, задавая такое неочевидное и нестандартное поведение для наиболее часто используемого типа коллекции?
Но это уже совсем другая история, которая к традиционному юниксовому шеллу имеет мало отношения.
(копирование в данном случае — это просто пример, аналогичный вопрос можно задать про любую операцию)
Объекты нарушают не столько саму концепцию пайпа, а концепцию шелла в целом. Поведение, обработка данных — это команды. Передача данных от команды к команде — это пайпы. Когда у вас объекты в пайпах начинают нести свое собственное поведение, вся система становится размытой, и непонятно, где именно искать нужное поведение. Например, в чем разница в PS между copy-item и CopyTo()? И почему вообще они существуют как две отдельные сущности с разным поведением?
--jsonиз коробки в обычных утилитах.И, кстати, более грамотная попытка, имхо. В PS мне активно не нравится то, что в пайпах там именно объекты — т.е. сущности с поведением. Имхо, это противоречит самой концепции «трубы», через которую льются данные, а поведение предоставляют программы с той и с другой стороны.
Единственный недостаток — длинноватый синтаксис для «повышенной читабельности». Но при этом куда более лаконичный XPath является чистым subset, поэтому можно пользоваться в основном им, а FLWOR оставить для сильно навернутых запросов, где эта читабельность реально имеет смысл.
С другой стороны, сам XML как формат явно избыточнен для таких целей, а вот JSON — самое оно.
«An object is created by a definition (3.1), by a new-expression (5.3.4) or by the implementation (12.2) when needed.»
При этом 12.2 — это исключительно temporaries, поэтому про них можно пока забыть.
С другой стороны, если есть вот такой вот код:
То в нем *p — это, определенно, объект (точнее, lvalue, которая его обозначает) — хотя ни объявления, ни new здесь не было.
Но есть и 3.8/1, где сказано:
«The lifetime of an object of type T begins when:
— storage with the proper alignment and size for type T is obtained, and
— if the object has non-trivial initialization, its initialization is complete.»
Очевидно, что malloc(sizeof(int)) выделяет память достаточного размера и выравнивания для int. Т.е. вроде как у нас есть int. Но эта память имеет размер и выравнивание, подходящие и для const int, и для volatile int, а на 32-битных реализациях — и для long, и для указателей самых разных типов. Возникает вопрос: сколько объектов на самом деле «создал» malloc?
На эту тему на comp.std.c++ периодически случаются холивары. Распространено мнение, что это такая как бы квантовая штука — т.е. там одновременно разом существуют объекты всех POD-типов, для которых это валидный storage (размер + выравнивание). Т.е. такой неявный union с соответствующей семантикой, в котором, как и в случае с обычным, можно работать только с объектом одного типа за раз, за исключением случаев, оговоренных семантикой union'ов — разница в cv qualifiers, структуры с common initial sequence и т.д.
Если принять это, то в вашем случае там «существует» объект типа volatile char, который и читается через указатель соотв. типа.