Comments 27
Поставил плюс вашей статье за перевод, но вот не понимаю тягость современных программистов-блоггеров к пересказу документации. Apple выпустила на столько детализированную и лаконичную книгу, что она читается за 2 часа. Кроме того, она так отлично разбита на главы, что часто можно просто перейти к интересующей главе. Но не смотря на это выходит какое-то невообразимое количество статей в англоязычном сегменте о том как сделать сабкласс на Swift, let и var в Swift, коллекции в Swift.
+15
Я бы не отнесла эту статью к разряду просто пересказа документации. В документации все есть, но в разных местах: часть — в Functions, часть (метод init) — в Classes and Structures, Enumerations. Для тех, кто пришел с Objective C, где все было просто, есть некоторая путаница, когда в методах нужно внешнее имя, а когда — нет. Здесь она собрала все в одном месте. Мне показалось это полезным. Кроме того, следует обратить внимание на автора поста Natasha Murashev — у нее очень интересные посты — короткие и по делу. И, вообще, она сейчас «звезда» Swift сообщества и выступает на всех Swift мероприятиях.
-2
Другое замечание относительно variadic параметров: variadic параметр должен быть последним параметром в вашем списке параметров!
Впервые читаю про синтаксис Swift'а и на этом месте сделал грустишку. Простейший для реализации синтаксиса момент, почему его игнорируют во многих языках? В этом плане впервые порадовало Ruby (у кого-то могло быть иначе), конечно. Представим себе прототип функции (абстрактного языка в вакууме) — «func(param1, param2, ...variadic_param..., param4, param5)», вычленить массив параметров в рамках variadic_param проще пареной репы — взяли массив всех параметров, убрали два именованных спереди и сзади — остальное variadic. Ну и запрет на два variadic подряд по вполне понятным причинам и прежде всего из-за логики.
0
Предлагаемая вами фича не сочетается со значениями аргументов по умолчанию и некоторыми другими фичами. Функции с переменным числом аргументов даже при текущих ограничениях способны приводить к неоднозначным и неочевидным ситуациям при перегрузке функций.
+1
Swift — язык молодой (декларирован 4 июня 2014 года на WWDC — 2014) и пока все время меняется, даже концептуально. Есть проблемы и ограничения, но Apple team их устраняет от релиза к релизу. Пока, конечно, много критики, но уверена — все сделают в «лучшем » виде, хотя и не сразу.
+1
Меня мучает вопрос: как в Swift сделать функцию, которая возвращает функцию которая возвращает функцию?
+1
func add (a1:Int, a2:Int) ->Int {return (a1 + a2)}
func multiply (a1:Int, a2:Int) ->Int {return (a1 * a2)}
func funcReturnFunc (funcOperation: (Int,Int) -> Int) -> (Int, Int) ->Int {
return funcOperation
}
func funcReturnFunc2 (funcOperation: (Int,Int) -> Int) -> (Int, Int) ->Int {
return funcReturnFunc(funcOperation)
}
let returnedFunction = funcReturnFunc2 (multiply)
let returnedFunction1 = funcReturnFunc2 (add)
returnedFunction(5,6) // Получим 30 на playground
returnedFunction1(5,6) // Получим 11 на playground
<source>
+1
Вы сделали функцию, которая возвращает функцию. Как это сделать в книжке в примерах пишут. А нужна функция, которая возвращает функцию, и каковая тоже возвращает функцию. Не вижу как синтаксически это оформить без мудреного typealias.
Извините за мой JavaScript:
Извините за мой JavaScript:
var test = function (i) {
return function (j) {
return function (k) {
// oh finally!
return i + j + k;
};
};
};
test(1)(2)(3); // == 6
0
Вы имели ввиду каррированные функции ( curried functions).
Их можно реализовать в Swift двумя способами:
Их можно реализовать в Swift двумя способами:
func add (i:Int, j:Int, k:Int, l:Int) -> Int {return(i + j + k + l)}
// 1- ый метод
func curry<A,B,C,D,R>(f: (A,B,C,D) -> R) -> A -> B -> C -> D -> R {
return { a in { b in { c in { d in f(a,b,c,d) } } } }
}
let sum4 = curry (add )
// 2- ый метод (curried function in Swift)
func sum4Swift(i: Int)(j:Int)(k: Int)(l:Int) -> Int {
return add(i, j, k, l)
}
sum4 (1)(2)(3)(5) // playground 11
sum4Swift (1)(j: 2)(k: 3)(l: 5) // playground 11
0
Однако сейчас все получается.
func chained(i: Int) -> (Int) -> (Int) -> Int {
return { (j: Int) -> (Int) -> Int in
return { (k: Int) -> Int in
return i + j + k;
}
}
}
chained(1)(2)(3)
+1
Проблема встроенных optionals в том, что для них нет монадических комбинаторов. Но уже есть swiftz :)
+2
«Магическое» будущее Swift описано в замечательных статьях ALEXANDROS SALAZAR The Culmination: Final Part (есть перевод «Кульминация — финальная часть.),
0
UFO just landed and posted this here
По поводу «вывода типов» и «похожести» Swift на Haskell есть ряд интересных статей Tony DiPasquale:
«Эффективный JSON c функциональными концепциями и дженериками в Swift.» (перевод) — оригинал «Efficient JSON in Swift with Functional Concepts and Generics».
«Реальный мир парсинга JSON.» (перевод) — оригинал «Real World JSON Parsing with Swift.»
«Парсинг вложенных JSON и массивов в Swift.» (перевод) — оригинал «Parsing Embedded JSON and Arrays in Swift.»
«Эффективный JSON c функциональными концепциями и дженериками в Swift.» (перевод) — оригинал «Efficient JSON in Swift with Functional Concepts and Generics».
«Реальный мир парсинга JSON.» (перевод) — оригинал «Real World JSON Parsing with Swift.»
«Парсинг вложенных JSON и массивов в Swift.» (перевод) — оригинал «Parsing Embedded JSON and Arrays in Swift.»
0
UFO just landed and posted this here
Ну к этому можно привыкнуть, зато как удобно искать методы в Xcode
<img src="
" alt=«image»/>
<img src="
![](https://habrastorage.org/files/9ff/cf1/767/9ffcf17674724fe382e92442d03723e6.png)
+1
UFO just landed and posted this here
Sorry, это я действительно не в тему.
Но вас-то что раздражает?
Методы выглядят абсолютно одинаково, что в Swft, что в Objective-C
Но вас-то что раздражает?
Методы выглядят абсолютно одинаково, что в Swft, что в Objective-C
override func tableView(tableView: UITableView, numberOfRowsInSection section: Int) -> Int { } //Swift
- (NSInteger)tableView:(UITableView *)tableView numberOfRowsInSection:(NSInteger)section {} // Objective-C
override func tableView(tableView: UITableView, cellForRowAtIndexPath indexPath: NSIndexPath) -> UITableViewCell {} //Swift
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath {} //Objective-C
<source>
0
Методы в Obj-C очень литературные, читается легко и понятно.
В Swift возникает мешанина скобок и двоеточий, которая не сказать прямо что помогает.
В Swift возникает мешанина скобок и двоеточий, которая не сказать прямо что помогает.
0
Согласна. Но сейчас держит Cocoa Touch, написанная на Objective-C: весь API оттуда. Если перепишут Cocoa Touch на Swift, то, возможно, будет другой API.
0
а планируют ли вообще переписывать, не знаете случайно?
0
Конечно, не знаю. Но думаю, что будут, так как слишком много «некрасивостей» в Swift вылезает из Cocoa Touch на Objective-C.
0
ну может встречали где-то в блогах инфу такую )
ну что-же, нам остается только надеяться и ждать.
ну что-же, нам остается только надеяться и ждать.
0
Sign up to leave a comment.
Многоликие функции Swift