Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, zverjuga, Вы писали:
Z>>Здравствуйте, Mamut, Вы писали:
M>>>Вот пример C#:
Z>>он не соответствует исходному примеру.
Z>>1. нет приведения response к HTTPURLResponse с соответствующей проверкой на валидность S>Это в C# делается вот так: S>
S>if(response is HTTPURLResponse httpResponse)
S>
Z>>2. коды должны быть в диапазоне от 200 до 299. а не IsSuccessStatusCode S>Это делается через Range operator 200..300. (Ranges в C# — end-exclusive).
и по итогу получается вот так
if (response is HTTPURLResponse httpResponse) {
if (!Range(200...3000).Contains(httpResponse.statusCode) {
self.authenticationDidFail = true;
}
}
else {
self.authenticationDidFail = true;
}
когда в оригинальной версии было
guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { // перенес в одну строчку, чтобы было наглядно, что это часть конструкции guard let, аналог AND (&&) в сишарпе
self.authenticationDidFail = true; // этот код работает, когда response НЕ является HTTPURLResponse ИЛИ statusCode не входит в заданный диапазон
}
я уже говорил, что я не утверждаю, что в сишарпе нельзя сделать того, что можно сделать в свифте. не нужно мне отдельные куски показывать, нужно показать пример целиком, чтобы была видна разница. и уже говорил, что прекрасно знаю, как продолжаются и заканчиваются подобные срачи. нет смысла дискутировать, пока оппонент не будет знать предмета разговора. то есть — как минимум не изучит синтаксис свифта или котлина, чтобы с ним было о чем говорить предметно. а для этого достаточно пару вечеров прочтения книги, не обязательно даже что то программировать.
Здравствуйте, zverjuga, Вы писали:
Z>Здравствуйте, Sinclair, Вы писали:
S>>Здравствуйте, zverjuga, Вы писали:
Z>>>Здравствуйте, Mamut, Вы писали:
M>>>>Вот пример C#:
Z>>>он не соответствует исходному примеру.
Z>>>1. нет приведения response к HTTPURLResponse с соответствующей проверкой на валидность S>>Это в C# делается вот так: S>>
S>>if(response is HTTPURLResponse httpResponse)
S>>
Z>>>2. коды должны быть в диапазоне от 200 до 299. а не IsSuccessStatusCode S>>Это делается через Range operator 200..300. (Ranges в C# — end-exclusive).
Z>и по итогу получается вот так Z>
Z>guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else { // перенес в одну строчку, чтобы было наглядно, что это часть конструкции guard let, аналог AND (&&) в сишарпе
Z> self.authenticationDidFail = true; // этот код работает, когда response НЕ является HTTPURLResponse ИЛИ statusCode не входит в заданный диапазон
Z>}
Z>
Тебе привели пример страницу назад, а ты все еще копротивляешься?
Z>то есть — как минимум не изучит синтаксис свифта или котлина, чтобы с ним было о чем говорить предметно. а для этого достаточно пару вечеров прочтения книги, не обязательно даже что то программировать.
Я тебе предметно показал, что все твои сдледующие утверждения по поводу C#/Java смешны, потому что они точно так же относятся к swift'у, который ты боготворишь. Или не относятся
— «это не та эволюция, которая от них ожидается. накидывание новых интерфейсов или расширений — это не эволюция, а расширение функционала».
Ты смотри, в Свифте накидывают все новые интерфейсы и расширения, причем постоянно
— «эволюция, когда упрощается синтаксис, убираются синтаксические нагромождения, которые не нужны, перекладывание части работы на компилятор и так далее».
В свифте синтаксис с каждой версией только усложняется
— «так и не появились нормальные красивые асинхронные http(s) вызовы апи сервера. казалось бы, маст хэв, но делается через одно место.».
Ага. Вон в Свифте API просто загляденье, ага-ага. Всего-лишь в четыре раза длиннее, чем на C#, все делается в ручную, да еще на коллбэках построено, потому что в async/await Swift не умеет. Причем сам Lattnet говорит, что подобные API — говно и хочет, ой, расширить синтаксис и функционал чтобы получить async/await, акторов и т.п. Но это другое, ага, не то, что в C#
AA>Эволюция ограничена первоначальными установками. Яркий пример — записи, AA>то что было изначально заложено в скала, фшарп и т.п. с 2016 года не могут завести в сишарп.
Что такое «записи»? Но да, эволюция ограничена первоначальными установками, есть такое.
AA>Что касается жавы там тоже есть нюансы, см кложу. AA>- прикольно же(если рид-конфиг вернул nil то cfg по умолчанию)?
В какой-нибудь гипотетической библиотеке на Java с Optional'ами будет примерно так же:
read("config.json").orElse(...свой конфиг...)
Проблема в том, что в Java нет полезных шорткатов для создания map'ов, классов (как в C#) и т.п.
AA>есть Color c; AA>Код будет чище если использовать if(c.Red == 255), а не c switch => (255, _, _);
Не обязательно чище. Паттерн матчинг даже в урезанном виде — очень мощная штука, в которой главная мощь — это то, что ты можешь матчить и по значениям и по типам. Даже в твоем примере если матчить только по одному значению, то проще if. А если по нескольким? А если по нескольким условиям? А если по нескольким типам и условиям?
IID>Ты придуриваешься ? IID>Речь о платежеспособных юзерах. Которые ВНЕЗАПНО не коррелируют с ценой девайса. Откуда опять разработчики взялись ?
IID>>>>>Причём тут доходы мобильных приложений? CC>>>>Это доходы разработчиков приложений. IID>И эпла...
А ну да. Платежеспособные юзеры же платят только и исключительно производителю телефона за телефон. На этом их платежеспособность заканчивается. Как мы могли об этом забыть.
Здравствуйте, Mamut, Вы писали:
M>- «так и не появились нормальные красивые асинхронные http(s) вызовы апи сервера. казалось бы, маст хэв, но делается через одно место.».
M>Ага. Вон в Свифте API просто загляденье, ага-ага. Всего-лишь в четыре раза длиннее, чем на C#, все делается в ручную, да еще на коллбэках построено, потому что в async/await Swift не умеет. Причем сам Lattnet говорит, что подобные API — говно и хочет, ой, расширить синтаксис и функционал чтобы получить async/await, акторов и т.п. Но это другое, ага, не то, что в C#
ну раз ты настаиваешь, чтобы эту глупость прокомментировал, то изволь.
асинхронные http(s) вызовы в свифте еще сто лет назад были реализованы в библиотеке AFNetworking, которая практически всегда и используется. URLSession — это самый низкий уровень, на котором реализованы сетевые запросы. использовать их можно, но это если ты по каким то причинам не можешь работать с нормальными тулзами или просто извращенец. ниже пример POST запроса на AFNetworking
manager.POST(url, parameters: params,
success:
{
(requestOperation, response) in
print("success")
},
failure:
{
(task, error) in
print("error")
}
)
Z>ну раз ты настаиваешь, чтобы эту глупость прокомментировал, то изволь. Z>асинхронные http(s) вызовы в свифте еще сто лет назад были реализованы в библиотеке AFNetworking
Ну то есть ты наезжаешь на Java, что там нет «красивого асинхронного API». Как говоришь, что в Свифте API говно, ВНЕЗАПНО выясняется, что надо всего лишь найти библиотеку?
Ну и у кого глупость?
Это не говоря о том, что лапша из коллбэков считается плохим тоном в программировании уже оооочень давно. Неудивительно, что Lattner собирается вводить в язык async/await.
Здравствуйте, Mamut, Вы писали:
M>Ну то есть ты наезжаешь на Java, что там нет «красивого асинхронного API». Как говоришь, что в Свифте API говно, ВНЕЗАПНО выясняется, что надо всего лишь найти библиотеку?
M>Ну и у кого глупость?
я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?
Z>я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?
Потому что ты не осилил найти библиотеку, видать.
Возвращаясь к свифту. Ты тут привел пример очередной говнобиблиотеки с говно-API. Других в Свифте и не может быть, потому что он не умеет в async/await, а умеет только в спагетти из коллбэков.
Oh wait
— зверюга: «эволюция, когда упрощается синтаксис, убираются синтаксические нагромождения, которые не нужны, перекладывание части работы на компилятор и так далее». Свифт — бог, С# говно.
— Lattner: наши коллбэк-API говно, я хочу ввести в язык новые синтаксические конструкции async, await и actor
Здравствуйте, Mamut, Вы писали:
Z>>я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?
M>Потому что ты не осилил найти библиотеку, видать.
Ее ты не видишь. Код на C# делает немного не то, что Свифт. Решается добавлением ровно одного ! безо всяких else А так синтаксис практически один в один, но только без лишнего нагромождения ненужных синтаксических конструкций в виде guard.
guard в свифте существует ровно по одной причине: вместо того, чтобы «убрать синтаксические нагромождения, которые не нужны, и переложить части работы на компилятор» по твоим заветам, авторы свифта не осилили переложить на компилятор проверку на nil. То есть они не осилили ни полноценную проверку на nil (что можно делать if'ом), ни более-менее полноценный Optional (можно не такой, как в Haskell'е, но хотя бы как в Rust'е).
Поэтому они сделали половинчатое решение, придумав абсолютно бессмылсенную и ограниченную во всех смыслах конструкцию, которая даже в простебйших примерах выглядит, как говно (потому что и есть говно).
Зачем? Ты же будешь считать, что библиотека — говно, потому что там, например, не божественный `(200...299).contains` а богомерзкий `(200..300).Contains` или что-то в этом же роде.
Здравствуйте, Mamut, Вы писали:
Z>>я не нашел. может ты найдешь?
M>Зачем? Ты же будешь считать, что библиотека — говно, потому что там, например, не божественный `(200...299).contains` а богомерзкий `(200..300).Contains` или что-то в этом же роде.
нет не буду. я хочу посмотреть, как в андроиде под джавой делаются удобные http(s) запросы на сервер. я как то упомянул, что в андроиде это по каким то причинам не реализовано, ты эту тему начал развивать. только запросы, никаких отдельных contains (правда ты пропустил Range(2000...300), против свифтового (200...300)) я сравнивать не буду, так как это тема для отдельных подветок.
будешь
Z>я хочу посмотреть, как в андроиде под джавой делаются удобные http(s) запросы на сервер. я как то упомянул, что в андроиде это по каким то причинам не реализовано
В Свифте тоже не реализовано. Но почему-то внезапно ты для Свифта нашел библиотеку. А для Java не осили найти. Но виновата Java
Z>, ты эту тему начал развивать. только запросы, никаких отдельных contains (правда ты пропустил Range(2000...300), против свифтового (200...300)) я сравнивать не буду, так как это тема для отдельных подветок.
Здравствуйте, Mamut, Вы писали:
M>guard в свифте существует ровно по одной причине: вместо того, чтобы «убрать синтаксические нагромождения, которые не нужны, и переложить части работы на компилятор» по твоим заветам, авторы свифта не осилили переложить на компилятор проверку на nil. То есть они не осилили ни полноценную проверку на nil (что можно делать if'ом), ни более-менее полноценный Optional (можно не такой, как в Haskell'е, но хотя бы как в Rust'е).
пример использования let и guar
исходный пример
func fooManualCheck(x: Int?) {
if x == nil || x <= 0 {
// Условия не соблюдены, выходим из функции
return
}
// Работаем с x
x!.description
}
этот же пример, но с использованием optional binding. недостаток — помещение x.description внутрь if
func fooBinding(x: Int?) {
if let x = x where x > 0 {
// Работаем с x
x.description
}
// Условия не соблюдены, выходим из функции
}
этот же пример, но с использованием guard. достоинство, что то, что после guard — это рабочий кот функции. то есть там кроме x.description может быть еще и простыня другого кода. то есть guard делает проверку на нуль и принудительное извлечение из оптиональной переменной, гарантируя, что x после него точно что то содержит
func fooGuard(x: Int?) {
guard let x = x where x > 0 else {
// Условия не соблюдены, выходим из функции
return
}
// Работаем с x
x.description
}
Я в курсе. Это — говно. Это ни if ни match (а ля rust) это какое-то говно посередине. Причем которое моментально становится максимально нечитаемым. Он почти полностью дублирует код if'а (то есть добавляет абсолютно лишнюю перегруженную конструкцию) и частично работает как match.
Причем это видно прямо в твоем же примере, но у тебя настолько глаз замылился своей верой в исключительность свифта, что ты этого не видишь:
func fooManualCheck(x: Int?) {
if x == nil || x <= 0 {
// Условия не соблюдены, выходим из функцииreturn
}
// Работаем с x
x!.description
}
// идентичен
func fooGuard(x: Int?) {
guard let x = x where x > 0 else {
// Условия не соблюдены, выходим из функцииreturn
}
// Работаем с x
x.description
}
разница только в том, что:
— у нас внезапно добавляется новый ненужный синтаксис (да еще и дико кривой: guard <condition> else {} вместо хотя бы guard <condition> {})
— guard магически распаковывает Optional
Они просто не осилили ни нормальный if (if не умеет делать проверку на nil) ни нормальный паттерн матчинг на Optional (как в Rust'е, да хотя бы как в C#). Мега-язык, ты что.
Да даже Java с x.filter(x => x > 10).orElseThrow(...) для Optional'ов лучше и адекватнее этого убожества.
Здравствуйте, Mamut, Вы писали:
M>Они просто не осилили ни нормальный if (if не умеет делать проверку на nil)
ты в своем уме? никто тебе не мешает делать эту проверку
if x != nil {
x!.description // только тут придется использовать принудительное извлечение
или
x?.description // эти два примера в данном конкретном случае практически равносильны
}
guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль
guard let x = x
можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно
if let x = x {
x.description
}
M>Да даже Java с x.filter(x => x > 10).orElseThrow(...) для Optional'ов лучше и адекватнее этого убожества.
ну это вообще капец. оказывается, что лучше использовать фильтр, чем просто lete
x.filter(x => x > 10).orElseThrow(...) // тут еще проверки на нуль не хватает
или
let x = x where x > 0 {
}
let и guard
1. гарантируют, что x не нулевая. то есть после них ты можешь использовать x без опасений, что там может оказаться нуль и избавить от дополнительных проверок
2. производят принудительное извлечение из оптиональной переменной в новую переменную, которая далее уже и используется
проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение