Re[12]: Как объяснить падение популярности .net?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.12.19 13:23
Оценка: +5
Здравствуйте, zverjuga, Вы писали:

Z>переписанный код на сишарпе будет таким

Z>
Z>var foo = someObject as ConcreteClass;
Z>var array = Enumerable.Range(200, 299).ToArray();
Z>if (foo == null || !array.Contains(foo.someValue)) {
Z>    // запустить в главном потоке код
Z>    // self.authenticationDidFail = true
Z>}
Z>

Ну это же враньё. Оператор приведения типа с проверкой в шарпе выглядит как if (someObject is ConcreteClass foo) — всё, мы ввели переменную foo, которая у нас имеет тип ConcreteClass.
.

Z>то есть, конструкция

Z>
Z>guard let foo = ...
Z>


Z>в данном примере одновременно объединяет в себе и приведение типов и проверку на нуль. в данном пример + еще и проверку на совпадение в заданном диапазоне. и если любое из двух условий не было выполнено, то выполняется блок else, где из главного потока вызвается

Z>
Z>self.authenticationDidFail = true
Z>


Z>опять так, сравниваем синтаксис создания списка по заданному диапазону в свифте

Z>
Z>(200...299)
Z>


Z>против сишарпа


Z>
Z>Enumerable.Range(200, 299)
Z>

Опять враньё. В новый шарп (8.0) встроили range-оператор. А в production версии "великую проблему синтаксиса шарпа" решаем вот так:
public static bool Contains(this (int start, int endInclusive) range, int value) => value >= range.start && value <= range.endInclusive;

После этого мы пишем (200, 299).Contains(httpResponse.Code) и волосы становятся мягкими и шелковистыми.
В "старых" версиях С# (начиная с 3.0) мы использовали "прямой" синтаксис httpResponse.Code.IsBetween(200, 299).
Z>я уже и не помню, как в сишарпе одной строкой запустить код в главном потоке, потому опустил эту часть.

Да уже видно, что вы просто не владеете C#. Конечно, он вам кажется неудобным.
Z>и это только одна конкретная мелочь, коих в свифте, конечно же, можно привести полно. когда проект большой, то таких мелочей вагон и ты начинаешь чувствовать их мощь и удобство. потому каждый раз говорить одно и то же реально задолбало.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: Как объяснить падение популярности .net?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.12.19 13:29
Оценка: +4
Здравствуйте, zverjuga, Вы писали:

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>

Нет, по итогу получается так:
if (response is HTTPURLResponse httpResponse && (200..300).Contains(httpResponse.statusCode) {
  return;
else self.authenticationDidFail = true;

Видите — 1:1.

Z>я уже говорил, что я не утверждаю, что в сишарпе нельзя сделать того, что можно сделать в свифте. не нужно мне отдельные куски показывать, нужно показать пример целиком, чтобы была видна разница.

Я и показал. Вы просто передёргиывете.
Z>и уже говорил, что прекрасно знаю, как продолжаются и заканчиваются подобные срачи. нет смысла дискутировать, пока оппонент не будет знать предмета разговора. то есть — как минимум не изучит синтаксис свифта или котлина, чтобы с ним было о чем говорить предметно. а для этого достаточно пару вечеров прочтения книги, не обязательно даже что то программировать.
Ну вы же не хотите потратить пару вечеров изучить C#. Поэтому критикуете придуманные недостатки.
Я в свифте конечно мало что понимаю, но ваш пример явно выглядит на С# лучше, чем на свифте. Есть риск, что если вы продолжите приводить более интересные примеры, то свифт вообще сольёт даже шарпу трёхлетней давности, не то что 8.0.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Отредактировано 12.12.2019 13:40 Sinclair . Предыдущая версия .
Re[13]: Как объяснить падение популярности .net?
От: zverjuga Беларусь  
Дата: 12.12.19 13:31
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Ну это же враньё. Оператор приведения типа с проверкой в шарпе выглядит как if (someObject is ConcreteClass foo) — всё, мы ввели переменную foo, которая у нас имеет тип ConcreteClass.

здесь уже отвеченно тебе же
http://rsdn.org/forum/flame.comp/7609323.1
Автор: zverjuga
Дата: 12.12.19


S>Опять враньё. В новый шарп (8.0) встроили range-оператор. А в production версии "великую проблему синтаксиса шарпа" решаем вот так:

хорошо, с этим я согласен. за последними версиями сишарпа я не следил. видимо, сперли у свифта решение (сарказм если что).
проклятый антисутенерский закон
Отредактировано 12.12.2019 13:31 zverjuga . Предыдущая версия .
Re[4]: Как объяснить падение популярности .net?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.12.19 14:06
Оценка: +2
Здравствуйте, Mamut, Вы писали:

AA>>Эволюция ограничена первоначальными установками. Яркий пример — записи,

AA>>то что было изначально заложено в скала, фшарп и т.п. с 2016 года не могут завести в сишарп.

M>Что такое «записи»? Но да, эволюция ограничена первоначальными установками, есть такое.

Подозреваю, что речь как раз про
public (string Name, int age) Foo()=> ("Hello", 42);

Которые там куда-то не могут завести

AA>>есть Color c;

AA>>Код будет чище если использовать if(c.Red == 255), а не c switch => (255, _, _);

M>Не обязательно чище. Паттерн матчинг даже в урезанном виде — очень мощная штука, в которой главная мощь — это то, что ты можешь матчить и по значениям и по типам. Даже в твоем примере если матчить только по одному значению, то проще if. А если по нескольким? А если по нескольким условиям? А если по нескольким типам и условиям?

+1. Опять же, тут только что рядом фанаты шарпа показывали, как можно совершенно прямолинейный код выписать в совершенно противоестественном виде — через Enumerable.Range().ToArray() и так далее.
Ну так в нормальной-то обстановке всё ровно наоборот: пишут самый короткий и понятный код, а не самый длинный и дурацкий. Не будет никто деконструкцию делать, когда можно просто вычислить c.Red == 255.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: Как объяснить падение популярности .net?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.12.19 14:09
Оценка: +3
Здравствуйте, zverjuga, Вы писали:

Z>Здравствуйте, Sinclair, Вы писали:


S>>Ну это же враньё. Оператор приведения типа с проверкой в шарпе выглядит как if (someObject is ConcreteClass foo) — всё, мы ввели переменную foo, которая у нас имеет тип ConcreteClass.

Z>здесь уже отвеченно тебе же
Z>http://rsdn.org/forum/flame.comp/7609323.1
Автор: zverjuga
Дата: 12.12.19

Ну там же опять враньё и передёргивание. Я там ответил.

S>>Опять враньё. В новый шарп (8.0) встроили range-оператор. А в production версии "великую проблему синтаксиса шарпа" решаем вот так:

Z>хорошо, с этим я согласен. за последними версиями сишарпа я не следил. видимо, сперли у свифта решение (сарказм если что).
Даже без range operator шарп прекрасен.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[13]: Как объяснить падение популярности .net?
От: Bj777x Германия  
Дата: 12.12.19 15:08
Оценка:
M>А ну да. Платежеспособные юзеры же платят только и исключительно производителю телефона за телефон. На этом их платежеспособность заканчивается. Как мы могли об этом забыть.

я работаю в немецком телекоме и нам дают 1 телефон раз в 3 года бесплатно(на выбор 5 моделей), так вот, большинство выбирает huawei
„Nun gut, wer bist du denn?“ „Ein Teil von jener Kraft, Die stets das Böse will und stets das Gute schafft.“
Re[18]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 15:23
Оценка: -1 :)
Z>ты в своем уме? никто тебе не мешает делать эту проверку

О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор. Ну то есть необходимость guard'а стала вообще нулевая.

Но уровень развития языка, кончено, забавляет.

Z>guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль


То есть заставляет тебя принудительно извлекать значение при помощи гарда. Кривейшей конструкцией почти полностью повторяющей if.

Z>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно


«В зависимости от ситуации», «то, что нужно», «нет, это в других языках эволюция путем нагромождения функционала и ненужных конструкций, свифт не такой»


M>>Да даже Java с x.filter(x => x > 10).orElseThrow(...) для Optional'ов лучше и адекватнее этого убожества.


Z>ну это вообще капец. оказывается, что лучше использовать фильтр, чем просто lete

Z>
Z>x.filter(x => x > 10).orElseThrow(...) // тут еще проверки на нуль не хватает
Z>


orElse/orElseThrow — это уже проверка на нуль.


Z>let и guard

Z>1. гарантируют, что x не нулевая. то есть после них ты можешь использовать x без опасений, что там может оказаться нуль и избавить от дополнительных проверок
Z>2. производят принудительное извлечение из оптиональной переменной в новую переменную, которая далее уже и используется

Итого, и let и guard делают одно и тоже, но при этом две конструкции. Одна из них явно лишняя.

Что самое смешное, что любые статьи и любая документация про guard прямо из кожи вон лезет, чтобы пытаться доказать, что guard — это что-то нечто особенное, а не вырожденный if с кривым синтаксисом. Потому что это и есть if с кривым синтаксисом.

Z>проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение


А да. Ведь магический гард этого никогда не делает, ты что:

guard let httpResponse = response as? HTTPURLResponse,
            (200...299).contains(httpResponse.statusCode) else


Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.


dmitriid.comGitHubLinkedIn
Re[16]: Как объяснить падение популярности .net?
От: · Великобритания  
Дата: 12.12.19 15:26
Оценка: +2
Здравствуйте, zverjuga, Вы писали:

Z>>>я говорил конкретно про АНДРОИД, что там до сих пор нет нормального тула для асинхронных запросов. да, на джаве. не скажешь, почему?

M>>Потому что ты не осилил найти библиотеку, видать.
Z>я не нашел. может ты найдешь?
А чем какой-нибудь okhttp не устраивает? А ещё есть retrofit, volley, Android-Async-Http и прочее хипстерство.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[11]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 15:28
Оценка: +3
S>Я в свифте конечно мало что понимаю, но ваш пример явно выглядит на С# лучше, чем на свифте. Есть риск, что если вы продолжите приводить более интересные примеры, то свифт вообще сольёт даже шарпу трёхлетней давности, не то что 8.0.

Справедливости ради, правильный аналог будет таким:

// swift
//   guard <condition == true> else { <code> }
// это прямой аналог
//   if <condition != true> { <code> }

guard let httpResponse = response as? HTTPURLResponse, (200...299).contains(httpResponse.statusCode) else {
  self.authenticationDidFail = true;
}

// строго аналогично

if(!(response is HTTPURLResponse httpResponse && (200..300).Contains(httpResponse.statusCode)) {
  self.authenticationDidFail = true;
}


Что все равно приводит к выигрышу Шарпа, потому что ему не нудны никакие дополнительные синтаксические конструкции.


dmitriid.comGitHubLinkedIn
Re[19]: Как объяснить падение популярности .net?
От: Sinclair Россия https://github.com/evilguest/
Дата: 12.12.19 16:24
Оценка: +1
Здравствуйте, Mamut, Вы писали:

Z>>guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль

M>То есть заставляет тебя принудительно извлекать значение при помощи гарда. Кривейшей конструкцией почти полностью повторяющей if.
Тем временем, взрослый компилятор, естественно, не должен заставлять учить магию типа guard let x = x
Z>>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно

Z>>let и guard

Z>>1. гарантируют, что x не нулевая. то есть после них ты можешь использовать x без опасений, что там может оказаться нуль и избавить от дополнительных проверок
Z>>2. производят принудительное извлечение из оптиональной переменной в новую переменную, которая далее уже и используется
M>Итого, и let и guard делают одно и тоже, но при этом две конструкции. Одна из них явно лишняя.

M>Что самое смешное, что любые статьи и любая документация про guard прямо из кожи вон лезет, чтобы пытаться доказать, что guard — это что-то нечто особенное, а не вырожденный if с кривым синтаксисом. Потому что это и есть if с кривым синтаксисом.


Z>>проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение

Тем временем, драфт спеки C# 8.0 обещает nullability tracking "таким же образом, как мы отслеживаем definite assignment".
То есть никакой распаковки в новую переменную не требуется, как и магии с x = x:
public static int Foo(string? firstName, string? lastName)
{
   if(firstName == null) throw new ArgumentException(nameof(firstName)); 
   return
     firstName.Length + // здесь warning-а нету: firstName is non-null
     lastName.Length + // а здесь - есть.
     1;
}

То есть обычный if, будучи правильно реализован, прекрасно справится с "избавить от дополнительных проверок".
Не знаю, смогут ли это же докрутить до Nullable<T> типов, но было бы логично.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[19]: Как объяснить падение популярности .net?
От: std.denis Россия  
Дата: 12.12.19 17:06
Оценка: +1
M>О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор
ты уже несколько раз повторил эту мантру про nil и ни разу не удосужился проверить это на актуальной версии языка? хоть бы на том же самом repl.it

M>- у нас внезапно добавляется новый ненужный синтаксис (да еще и дико кривой: guard <condition> else {} вместо хотя бы guard <condition> {})

M>guard — это что-то нечто особенное, а не вырожденный if с кривым синтаксисом. Потому что это и есть if с кривым синтаксисом.
guard не что-то прям особенное, просто наверное ты его не использовал на практике вот он для тебя как-то дико выглядит. И поэтому ты сделал вон то "странное" предложение с убиранием "else". Синтаксис guard сделан так, чтобы программа читалась как текст, а не набор символов пунктуации. По сути его можно было назвать ассертом: нужно [утверждение] иначе [аварийное действие]
guard let ad = post as? AdPost else { return }
guard books.amount > 0 else { return nil }

Читается как "должно быть книг.количество больше нуля, иначе результат – пустота"

Z>>проверку на нуль можно делать и при помощи обычного if, только он делает только одну проверку, но не извлекает значение из оптионала. то есть при if тебе все равно где то придется завести новую переменную и в нее скопировать значение

M>А да. Ведь магический гард этого никогда не делает, ты что:
guard и if схожи, у них главное отличие: if-let создаёт поле внутри блока if, а guard-let создаёт это поле до конца текущего скоупа. При этом let там не обязателен, можно простое условие, без создания поля.

M>guard let httpResponse = response as? HTTPURLResponse,

M> (200...299).contains(httpResponse.statusCode) else
M>Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.
Что значит "на ровном месте меняет"? Автор кода явно задекларировал "допустим response это HTTPURLResponse", всё меняется как запланировано, точнее не меняется а создаётся новое поле с указанным типом.
Хотя мне в свисте очень не хватает смарт кастинга котлина:
if (response !is HttpResponse || response.statusCode !in 200..299)
    return
// тут response имеет тип HttpResponse и statusCode находится в диапазоне [200..299]
Re[20]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 17:51
Оценка: -1
SD> ты уже несколько раз повторил эту мантру про nil и ни разу не удосужился проверить это на актуальной версии языка? хоть бы на том же самом repl.it

Поставил свежую Каталину. Поставил на нее свежий XCode (на момент установки Каталины). Получил то, что получил.

Ах, надо было обновиться на версию, которая, видать, толкьо вчера вышла? Ну извиняйте.

И тем более, раз можно if x == nil, то смысл иметь в языке guard исчезает напрочь.

SD>guard не что-то прям особенное,


я нигде не говорю, что он что-то особенное. это утверждает зверюга. Я говорю прямым текстом, чем оно является: ненужной дополнительной кастрированной версией if'а.

SD>просто наверное ты его не использовал на практике вот он для тебя как-то дико выглядит. И поэтому ты сделал вон то "странное" предложение с убиранием "else". Синтаксис guard сделан так, чтобы программа читалась как текст, а не набор символов пунктуации.


guard сделан так, чтобы потом надо было тратить много страниц текста на объяснение, наига он нужен, и чем он отличается от if'а. Рационализация этого костыля слаба. И «программа должна читаться как текст» очень смешно выглядит в контексте практически любого языка в общем, и в С-синтаксисе Свифта в целом.

SD>По сути его можно было назвать ассертом: нужно [утверждение] иначе [аварийное действие]


Нельзя было.

SD>Читается как "должно быть книг.количество больше нуля, иначе результат – пустота"


Ну то есть читается, как if.

M>>А да. Ведь магический гард этого никогда не делает, ты что:

SD>guard и if схожи, у них главное отличие: if-let создаёт поле внутри блока if, а guard-let создаёт это поле до конца текущего скоупа. При этом let там не обязателен, можно простое условие, без создания поля.

Итак, на ровном месте создали, согласно зверюге «доп функционал и нагромождение синтаксиса», которое не нужно даже даром (при наличие внятного компилятора, понятное дело).

Потому что то, что ты написал ровно ничем не отличается от банального if'а. Чем guard и является.

M>>guard let httpResponse = response as? HTTPURLResponse,

M>> (200...299).contains(httpResponse.statusCode) else
M>>Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.
SD>Что значит "на ровном месте меняет"? Автор кода явно задекларировал "допустим response это HTTPURLResponse", всё меняется как запланировано, точнее не меняется а создаётся новое поле с указанным типом.

Ты не в том месте разорвал цитату. зверюга утверждал, что другие языки говно, потому что надо вводить временные переменные. Хотя прекрасно видно, что guard легко вводит временные переменные.

Вдобавок. В отличие от любых (?) других конструкций, эти временные переменные появляются не внутри гарда, а внутри всей области видимости, где находится этот гард. Удобно, чо. Главное, единообразно, ага.

А можно сделать вот так:

Было:
let response : URLResponse? = .... 

// обязаны использовать as? потому что 
// response имеет тип URLResponse?
self.token = (response as? HTTPURLResponse).value


Стало:

let response : URLResponse? = .... 

guard let response = response else {
  return
}

// response поменял тип на URLResponse
self.token = (response as? HTTPURLResponse).value


Отличный, замечательный язык.

SD>Хотя мне в свисте очень не хватает смарт кастинга котлина:

SD>if (response !is HttpResponse || response.statusCode !in 200..299)

Или сишарпа
Автор: Sinclair
Дата: 12.12.19


dmitriid.comGitHubLinkedIn
Отредактировано 12.12.2019 18:06 Mamut [ищите в других сетях] . Предыдущая версия . Еще …
Отредактировано 12.12.2019 17:52 Mamut [ищите в других сетях] . Предыдущая версия .
Re[19]: Как объяснить падение популярности .net?
От: zverjuga Беларусь  
Дата: 12.12.19 18:18
Оценка: :))
Здравствуйте, Mamut, Вы писали:

Z>>ты в своем уме? никто тебе не мешает делать эту проверку


M>О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор.

если у тебя xcode со времен динозавров, то возможно. но такой проблемы не было никогда, начиная с самых первых версий свифта. боюсь, что ты чего то не договариваешь. или не разобрался тогда. я по крайней мере не пропомню, когда у меня была такая проблема, правда я со свифтом начал работать около 4 лет назад только.

Z>>guard тебя избавляет от принудительного излечения значения из оптиональной переменной, так как он уже это сделал + проверка на нуль

M>То есть заставляет тебя принудительно извлекать значение при помощи гарда. Кривейшей конструкцией почти полностью повторяющей if.

это все потому что свифт поддерживается парадигмы строгой типизации. он не допускает своевольничания и предположений. если тип оптионал, то ты обязан перед тем, как работать со значением, его извлечь. при этом оператор принудительного извлечения ! не является безопасным, и ты вполне можешь получить исключением, если попытаешься что то извлечь из нуля. строгая типизация она да, такая. и использование просто IF не дает тебе гарантии, что ! не выдаст тебе исключения

Z>>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно


M>orElse/orElseThrow — это уже проверка на нуль.


а он разве не сработает после вызова метода filter? а ведь нужно — до
и лучше использовать фильтр, чем let, я это уже понял.

M>Самое прекрасное, конечно, это то, что guard на ровном месте меняет тип переменной.


guard НЕ МЕНЯЕТ тип переменной. он (вернее не он, а let) создает НОВУЮ КОНСТАНТУ в которую копируется безопасное извлечение из оптионала. то есть, чтобы было понятнее
guard let y = x else {
}


или
if let y = x {
}


создается новая КОНСТАНТА y, которая инициализируется значением из оптионала x. примеры выше были такими
guard let x = x else {
}
x.foo() // здесь X уже не тот X, который был ранее. это новая константа


и таки да, свифт позволяет делать такие вещи, чтобы не плодить лишних имен. это обычное замещение переменной, когда новое имя перебивает старое. ты волен выбирать, как тебе удобнее, так или сяк.
проклятый антисутенерский закон
Отредактировано 12.12.2019 18:48 zverjuga . Предыдущая версия . Еще …
Отредактировано 12.12.2019 18:25 zverjuga . Предыдущая версия .
Отредактировано 12.12.2019 18:23 zverjuga . Предыдущая версия .
Re[21]: Как объяснить падение популярности .net?
От: std.denis Россия  
Дата: 12.12.19 18:26
Оценка: +1
M>guard сделан так, чтобы потом надо было тратить много страниц текста на объяснение
ну не все могут понимать лаконичную документацию языка, этим разжёвывают, да 🙂

SD>>Хотя мне в свисте очень не хватает смарт кастинга котлина:

SD>>if (response !is HttpResponse || response.statusCode !in 200..299)

M>Или сишарпа
Автор: Sinclair
Дата: 12.12.19

скорее твой вариант, а не синклера. правда !(...) выглядит уродско
Re[12]: Как объяснить падение популярности .net?
От: zverjuga Беларусь  
Дата: 12.12.19 18:39
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Что все равно приводит к выигрышу Шарпа, потому что ему не нудны никакие дополнительные синтаксические конструкции.


спорно, на мой взгляд. вариант на свифте читается слева-направо как есть. одно условие следует за другим, и если любое из них нарушено, срабатывает блок else.
вариант на сишарпе уже заставляет вникать в логику. времени на осмысление условия требуется больше. сначала нужно прочитать условие внутри скобок, потом его еще и инвертировать. и потом сообразить, в каком случае будет true или false

swift
guard let condition1, condition2 else { // условия выполняются слева направо
    // не выполнено любое из условий
}



c#
if !(condition1 && condition2) {
    // не выполнено любое из условий
}
проклятый антисутенерский закон
Отредактировано 12.12.2019 18:46 zverjuga . Предыдущая версия .
Re[4]: Как объяснить падение популярности .net?
От: smbdnew  
Дата: 12.12.19 19:45
Оценка:
Здравствуйте, zverjuga, Вы писали:

Z>Здравствуйте, Mamut, Вы писали:


Z>если бы свифт был под виндой, я бы только на нем и сидел и забыл бы о сишарпе как страшный сон.


сразу видно человека, который на нём никогда ничего серьезного не писал (ну или человека который не писал на нём года 3 назад).
сам ушёл со свифта (и всей этой эппл-параши) года 3 назад на .net и ни разу не пожалел.
Re[13]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 20:51
Оценка: +1
Z>вариант на сишарпе уже заставляет вникать в логику. времени на осмысление условия требуется больше.

1. Не требует
2. Использует единообразные подходы, а не убогое нагромождение неенужного функционала и синтаксических конструкций © ты

Пример, который мы обсуждаем, как мы уже увидели, в C# в реальности выглядит так:

var response = await httpClient.GetAsync(url);
if (!response.IsSuccessStatusCode){
   <вызов любого async кода>
   return;
}


Во-первых, никаких «заставляет вникать в логику». Во-вторых никаких кривых дополнительных конструкций. В-третьих, код, до которого Свифту, как до Пекина раком (хотя await таки хотят вводить).

Еще раз: guard не является ничем иным, как убогой урезанной версией if'а, на которую еще нагромодили доп. функционал: вводит новые переменные в scope, переопределяет тип существующих переменных. То есть ровно то, что ты называешь плохим в других языках.


dmitriid.comGitHubLinkedIn
Re[22]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 20:51
Оценка:
M>>Или сишарпа
Автор: Sinclair
Дата: 12.12.19

SD>скорее твой вариант, а не синклера. правда !(...) выглядит уродско

Потому что высосанный из пальца пример. Полный аналог примера в C# тут: https://rsdn.org/forum/flame.comp/7608728.1
Автор: Mamut
Дата: 11.12.19


dmitriid.comGitHubLinkedIn
Re[20]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 21:03
Оценка: -1 :)
M>>О. У меня как раз обновился XCode и ВНЕЗАПНО if error == nil перестало выдавать ошибку "error must implement Equatable". Видимо наконец-то пофиксили компилятор.
Z>если у тебя xcode со времен динозавров, то возможно

Поставлен сразу на новую Каталину.

Z>это все потому что свифт поддерживается парадигмы строгой типизации. он не допускает своевольничания и предположений.


Ага, и гард своевольничает и предполагает: вводит новые переменные в scope и переназначает типы переменным.

Z>если тип оптионал, то ты обязан перед тем, как работать со значением, его извлечь. при этом оператор принудительного извлечения ! не является безопасным, и ты вполне можешь получить исключением, если попытаешься что то извлечь из нуля. строгая типизация она да, такая. и использование просто IF не дает тебе гарантии, что ! не выдаст тебе исключения


Да неужели? Правда, что ли? В жизни никогда не подумал бы!

Это был сарказм, если что. guard для этого не нужен, от слова совсем.

Z>>>можно вместо него использовать обычный let. в зависимости от ситуации используются либо let, либо guard, смотря что нужно

M>>orElse/orElseThrow — это уже проверка на нуль.
Z>а он разве не сработает после вызова метода filter? а ведь нужно — до

Нет, не сработает. Нет, не нужно. Более того, Свифту даже до уровня Optional'ов в Java — как из Парижа до Пекина на карачках.

Z>guard НЕ МЕНЯЕТ тип переменной. он (вернее не он, а let) создает НОВУЮ КОНСТАНТУ в которую копируется безопасное извлечение из оптионала. то есть, чтобы было понятнее



То есть чтобы было понятнее: Swift — единственный в мире язык со «парадигмой строгой типизации, который не допускает своевольничания и предположений», в котором переменная внутри scope'а меняет тип в зависимости от того, участвовала она внутри присваивания в определенной конструкцией или не участвовала.

Ни у одной другой конструкции в языке нет такого функционала. Как ты там говорил? Упрощние синтаксиса? Не надо нагромождать функционал и ненужные синтаксические конструкции? Бугагага


Z>и таки да, свифт позволяет делать такие вещи, чтобы не плодить лишних имен. это обычное замещение переменной, когда новое имя перебивает старое. ты волен выбирать, как тебе удобнее, так или сяк.


Это не обычное замещение имен. Это смена типа переменной. С Optional<T> на T. Но великому прекрасному статически типизированному языку без своевольничания и предположений это почему-то невдомек.


dmitriid.comGitHubLinkedIn
Re[14]: Как объяснить падение популярности .net?
От: Mamut Швеция http://dmitriid.com
Дата: 12.12.19 21:05
Оценка:
B>я работаю в немецком телекоме и нам дают 1 телефон раз в 3 года бесплатно(на выбор 5 моделей), так вот, большинство выбирает huawei

Работал в банке, стартапе, уже второй стриминговой компании. Максимум до половины выбирает Андроиды (даже флагманы). Большинство — айфоны.

Что должны показать эти личные истории, не представляю.


dmitriid.comGitHubLinkedIn
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.