Check Levi9 best QA positions to Backbase team!
×Закрыть

Swift: прекрасное и ужасное в одном лице

Изучаю в свободное время Swift и как язык он мне нравиться, но есть вещи — которые откровенно меня начинают немного раздражать.

Возьмем к примеру отрисовку фигур и нарисуем треугольник на C#

Point p1 = new Point(0, 50);
Point p2 = new Point(50, 0);
Point p3 = new Point(50, 100);
StreamGeometry streamGeometry = new StreamGeometry();
using (StreamGeometryContext geometryContext = streamGeometry.Open())   
{
    geometryContext.BeginFigure(p1, true, true);
    PointCollection points = new PointCollection{ p2, p3 };
    geometryContext.PolyLineTo(points, true, true);
}

streamGeometry.Freeze();
context.DrawGeometry(Brushes.Red, new Pen(Brushes.Red,3), streamGeometry);

Все довольно понятно и обратите внимание, как передается цвет, толщина линий и все остальное — все передается как параметры в метод: context.DrawGeometry(Brushes.Red, new Pen(Brushes.Red,3), streamGeometry);

Теперь возьмем и нарисуем треугольник на Swift.

let trianglePath = UIBezierPath()
trianglePath.moveToPoint(CGPoint(x: 5.0, y: 95.0))     // #1
trianglePath.addLineToPoint(CGPoint(x: 50.0, y: 12.5)) // #2
trianglePath.addLineToPoint(CGPoint(x: 95.0, y: 95.0)) // #3
trianglePath.closePath()

Что тоже довольно понятно. И теперь — что бы нарисовать этот треугольник скажем залитым внутри красным цветом я должен сделать вот так

UIColor.redColor().setFill()

Выглядит ужасно — я должен вызвать статический typed-method у совершенного другого типа, которые по коду явно не влияет на «context» и сразу возникает несколько моментов, а что если вызвать этот метод до создание UIBezierPath, или после метода trianglePath.fill(), что будет если я его вызову просто в коде или вызову дважды итд итд...

Возможно кто-то с больший опытом в мобильной разработке меня поправит или скажет, что это хорошо.

PS: Ну и сам класс -UIBezierPath()- называется в честь кривых Безье, я не против, но его надо помнить в противовес DrawingContext, который запомнить гораздо легче..

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Лучшие комментарии пропустить

func CGContextSetFillColorWithColor(_ c: CGContext?, _ color: CGColor?)

Стандартная либа, а не сам свифт.

Если вас не устраивает, всегда можете написать обертки, т.к. вы работает с низким уровнем.

В шарпе же вы, наоборот, используете высокий уровень. Т.е., вам бы уже лейеры тогда сравнивать.

А вот ужасно в свифте то, что вы не упоминаете:
— бажный компилер;
— бажная среда разработки;
— нет совместимости между версиями языка;
— отсутствие каррированых по дефолту функций на уровне языка
— уродский optional вместо result, как базовый тип;
— отстутствие интероперабельности с С++;
— зашитая в бандле стандартная либа;
— наличие форсированного optional (optional!);
— наличие исключений;
— наличие анвраппинга оптионалов через if let, guard;
— вызов внутренних методов и проперти без self;
— shadowing переменных в областях видимости без ворнингов.
— кривая интероперабельность с objective-c (чего по дефолту стоит возврат из методов в optional! виде, если в objc коде нет спецификаторов дял подсказки, типа nullable);
— отсутствие кодогенерации (макросы/шаблоны/доступ к ast);
— крайне нелогичный захват локальных переменных при отсутствии/наличии списка захвата.

Можно нашкрести еще, но мне лень.

учите С++, там можно рисовать прекрасные треугольники:
for(int i=1;i<10;i++) { for(int j=1;j<=i;j++) printf("*"); printf("\n"); }

Вот вам нормальный метод — CGContextSetFillColor(). И не благодарите.
Я молчу насчет того, что это к Swift вообще никак не относится.

А насчет всего остально и возмущений с сторону векторной графики — её нужно уметь готовить. Корни всего этого добра надежно лежат в сишном API CoreGraphics c углублением в Quartz.

Если это все, что раздрадает Вас в этом языке, то, очевидно Вы нашли свой язык програмирования)

А до чого тут Swift? UIColor та UIBezierPath — це класи фреймворку UIKit. На Objective-C їх теж можна використовувати.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вот ту смотрю нашлись люди, которые занялись некропостингом (т.е. воскрешением старого топика). Решил и я сделать свой вклад в некропостинг и вставить свои 5 копеек.

планы (портирование на Linux, open source, Server side development, «bytecode», etc.) амбициозны и они воплощаются/реализуются постоянно и последовательно.

по состоянию на осень 2018 года есть уже даже порт для винды — swiftforwindows.github.io .
насколько оно работающее — хз, но самому захотелось попробовать (ибо смотрю написано, что поддерживается и 64-битная «семерка») — интересно, что из этого выйдет...

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

... идишьты пишут якобы «Foundation module is included» — надо будет заново взять посмотреть.

ЗЫ: для изучения фичей языка оно более чем вполне рабочее конечно какой-нибудь wxSwift с понтом под зонтом гуй на свифте на винде рисовать х.з. зачем оно может быть нужно чисто в принципе.

Swift — отличный язык.
То, что там есть какая-то кривизна (ее совсем не много) — это временно — Apple регулярно релизит новые версии (3 на подходе — ужо вышла) где постоянно подправляет/подчищает кривизну.

Но главное не это — IBM «подписалась» под Swift. Почитайте перспективы и направления инвестирования усилий со стороны Apple и IBM (самые крупные «инвесторы») — планы (портирование на Linux, open source, Server side development, «bytecode», etc.) амбициозны и они воплощаются/реализуются постоянно и последовательно.

По инсайдерской информации — внутри IBM всякая новая разработка для iOS ведется строго на Swift.
В Северной Америке, по моему личному убеждению, новые проекты под iOS стартуют на Swift.

Так что ничего ни прекрасного ни ужасного в Swift нету. Просто «большие дяди» решили создать новый ЯП соответствующий всем новомодным течениям/тенденциям (+ свои моменты которые ооочень неплохи). И, стоит признать, получается очень неплохо да и в очень ,даже , быстрые сроки.

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

Официально Swift объявили Open Source, пробовал Swift на Xubuntu 15.10 — работа в командной строке, IDE никакого под Linux нет, а без либ вообще тупик — не знаю как в третей версии, но во второй уж много функционала в самом языке нет, а бриджуется из Cocoa, который yf Objective-C. Apple перевел лишь Foundation libdispatch и XCTest — swift.org/core-libraries

Без либ Swift обречен быть чисто стандартом для Apple не смотря на то что даже лучше за Python, как по простоте, так и по производительности и скорости.

работа в командной строке, IDE никакого под Linux нет, а без либ вообще тупик

А что вы хотели от Open Source? Найдутся энтузиасты — будет и IDE, и библиотеки, и много других плюшек.

Вон, Vapor есть, лично я им не пользовался, но уже что-то есть, под Ubuntu работает и, судя по тестам, неплохие результаты дает.

Другие фреймворки не стоят на месте и плюшки есть уже. Vapor выглядит ну очень заманчиво, с позиции программиста со знанием Swift, а для других языков — ну ож оочень удивленно вопросительно — по своим друзьям на RoR и .NET вижу.

Какой-то ускоритель нужен.

Не все сразу.
Темпы развития языка , лично меня , впечатляют — думал будет медленнее. Быстро все реализовывается.
Посему- будущее языка лично с моей калакольни видится ооочень оптимистично.

Go язык вродь как ранее появился — его тоже большой брат толкает только другой. Сегодня говорил с людьми которые писали на нем — блюют. Не нравится. Причем вся команда.

А Swift 1) продвигают аж два больших брата 2) упорно рисуется картина что новые проекты стартуют на Swift под iOS 3) те кто пробовали Swift — не хотять назад на Objective C и отзываются очень позитивно. Это косвенные признаки — но убедительные для оптимизма.

Swift мне очень нравится. Но.

Спрыгнул с Python на Swift как пошел на курс по iOS, так понравился, шо поставил себе на Kubuntu, далее оказалось, шо писать надо в командной строке, редактора под Swift нет, более менее подошел Sublime, файлы запускаешь тоже через терминал, даже для простеньких вычислений.

Вроде нормальная программерская работка, а с другой стороны на курсах Маки и в Playground все это выполняется автоматом в секунде без лишней суеты.

Потом выяснилось, шо без Foundation Swift урезан по самое немогу — на Apple решили бриджануть функционал, а не встроить в Swift , а это еще потрудится его на Ubuntu поставить, с менеджером версий тоже пробел.

Решил не мучатся и превратить свой Самсунг в Хакентош — 2 недели без нормально рабочего компа + под конец, шоб стало винт форматануть надо было его под HTFS+.

Плюнул, сменил Kubuntu на Xubuntu поставил виртуалку с el Capitan, ура все работает кроме терминальные программы на виртуалке не понятно работают, то да, то нет. С CocoaPods вообще мистика.

Короче, купил Мак и забыл за все эти муки.

Swift прекрасен. Но. Но, если есть Мак.

те кто пробовали Swift — не хотять назад на Objective C и отзываются очень позитивно

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

Swift на то и сделан, шоб еще более ООПшным быть чем Objective-C. Сообщения в нем через dot notation, а не как в Objective-C [Class message].

Swift на то и сделан, шоб еще более ООПшным быть чем Objective-C. Сообщения в нем через dot notation, а не как в Objective-C [Class message].

1. В swift нет сообщений, а есть вызов замыканий.
2. Сообщения — это не синтаксис. Не позорьтесь и идите читать, что это такое.
3. Swift — гибрид функционального и объектного языка, котоырй сам не может решить, чего в нем больше. До объектной ориентированности обжектива ему, как до луны. Просто банально потому, что Swift не выполняет 2 из базовых требований OOP: сообщения, локальное удержание, прятание и защита обработки состояния, позднее связывание. Угадаете, какие именно?

Насчет проблемы swift-objective c согласен с Вами. Большинство свифтеров не юзали objectiv-c и, максимум, что они могут, это кричать о том, что Objective уродлив. Лично мне нравится Objective за свой рантайм. Swift раздражает своей пугливостью по поводу и без :-))

Некропостинг процветает))

Лично мне нравится Objective за свой рантайм. Swift раздражает своей пугливостью по поводу и без :-))

Мне нравятяс оба языка. У обоих есть плсюы и минусы. Меня парит то, что свифт до сих пор в альфе. Компилер нестабилен, инструменты рзаработки нестабильны, нету ключевых фич языка, которые в swift evolution откладываются на потом во имя того, чтобы вставить очередное ненужное говно, типа async/await или exceptions.

поэтому — только плюсы и ниайпод

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

Лет через 10, если уберут самые мерзкие моменты. А до того времени переходить на свифт — себя не уважать, просто по той причине, что каждый новый релиз содержит несовместимость.

В Северной Америке , по моему убеждению, а также со слов мэстнэх рекрутеров — новые проекты стартуют почти всегда на Swift (это помимо «слухов» что, например, в IBM продукты под iOS стартуют строго на Swift).

Получается , все эти товарисчи «себя не уважают»..... либо, знают чего-то того, чего, вероятно, вы не знаете.

В Северной Америке , по моему убеждению, а также со слов мэстнэх рекрутеров — новые проекты стартуют почти всегда на Swift (это помимо «слухов» что, например, в IBM продукты под iOS стартуют строго на Swift).

Я таки не буду утверждать за всю СА. Могу говорить о Нью Йорке и офисе IBM там. Проект City Group — ObjC.

Рекруты из стартапов NY, SF, LA — обязательное знание ObjC, Swift — optional.

Получается , все эти товарисчи «себя не уважают»..... либо, знают чего-то того, чего, вероятно, вы не знаете.

Читайте выше. Свифт все еще не готов для продакшна, если, конечно, вы — не Ortha Therox в Artsy, да и тот уходит на React Native.

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

Его популярность также подтверждает количество опенсорсных библиотек написанных на свифт

По сравнению с обжективом, библиотек мизер, как бы. Во-вторых, даже на свифте, не все либы поддерживают swift3, swift2.3. Людей быстро задалбывает поддержка Но дело не в этом. Я тоже один из своих опен-сорс проектов перевожу на свифт. Опен-сорс — это хобби, посему, никаких претензий. форкнул и пошел поддерживать, если надо.

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

Миллионы мух не могут ошибаться? А еще больше разработчиков свифт не используют. И чо? Детская аргументация какая-то.

Swift здесь ни при чем. Это все iOS, на objective c так само будет.

А пробовал кто-нибудь AppCode от JetBrain www.jetbrains.com/objc ? Что скажете по сравнение с xCode ?

Xcode бесплатный, этот платный. И вообще откуда у Jet Brains Cocoa Touch либы и iOS симулятор возьмутся???

За что они тогда деньги просят ?

AppCode will not run without Xcode available. If Xcode is installed, AppCode detects it automatically and silently integrates with it.

Получается примочка к Xcode с тем, шо Apple еще не допилил. Сам не пользовался, но вижу, к примеру, шо есть рефакторинг для Swift, чего в Xcode нет

Для легкого рефакторинга всегда можно воспользоваться плагином Refactorator и опять не придется покупать лицензию на AppCode.

Надо попробовать. На гите пишет шо бетка под 8й Икскод.

Думаю, он нужен только людям с острой зависимостью от IntelliJ :-)

якщо зараз погратись з розробкою під іос, краще вибрати свіфт чи обж-с?

Если для души, то пофиг, если для дела — обжектив-с.

Якщо просто «погратись», то різниці нема. Якщо потрібно здобути навички для розробки під iOS, то — Swift. Це дитя Apple, вони вкладають у нього занадто багато ресурсів, щоб потім відмовитись від нього. Плюс є деякі сторонні проекти, що можуть дорости до чогось цікавого, наприклад Vapor. А Obj-C, скоріш за все, відправлять на пенсію, тому років через 3-4 він буде вже не актуальним. Плюс, все що написав Mobile Developer.

Ходят слухи, шо с 11 iOS будут поддерживаться апликухи только на Swift 3, а десятка — переходное время перевести проекты на Swift 3.

С другой стороны под капотом Swift 2.3 бриджован с Ojective-C (куча функционала не встроена в Swift, а берется с Ojective-C, особенно это раздражает работа со стрингами, где по сравнению с другими языками извращения сякие надо делать)

Соответственно надо учится писать на Swift так, шоб тя понимал Ojective-C

Конечно же Swift, для него даже есть песочница, в которой можно поиграться. Думаю уже поздно начинать знакомство с Objective-C, да и Apple с каждым годом оттесняет его все дальше и дальше.

Думаю уже поздно начинать знакомство с Objective-C, да и Apple с каждым годом оттесняет его все дальше и дальше.

Все нативные либы, включая AudioUnit V3, который совсем новый, написан на objc. Не начав знакомство с обжективом, у вас нет шанса писать нормальный код на яблоко и пользвоаться опенсорсом.

Не спорю, но речь шла о «поиграться».
Хотя вот пересмотрел свои зависимости и понял что зависимости на objc уже можно на пальцах перечесть, хотя еще буквально год назад все было на objc.

Все яблочные фреймворки в зависимостях — это на пальцах пересчитать? Я так понимаю, что со звуком/видео вы также не работаете? Работы с графикой тоже не осуществляете?

Да, разные простые врапперы, типа afnetworking ушли на свифт, туда же ушли изначально функциональные вещи, типа rxswift/reactivecocoa и т.п., которые на обежктиве смотрелись, как пятая нога у коня. Все, остальное так и осталось на обжективе. Более того, по-прежнему многие data-flow без обжектива организовать не выйдет. Хотя бы в силу того, что проксирование на свифте — это адов процесс с кучей дублирования, а люди не понимают, что гарды и иф леты использовать не надо, пользуясь вместо них type inference.

func CGContextSetFillColorWithColor(_ c: CGContext?, _ color: CGColor?)

Стандартная либа, а не сам свифт.

Если вас не устраивает, всегда можете написать обертки, т.к. вы работает с низким уровнем.

В шарпе же вы, наоборот, используете высокий уровень. Т.е., вам бы уже лейеры тогда сравнивать.

А вот ужасно в свифте то, что вы не упоминаете:
— бажный компилер;
— бажная среда разработки;
— нет совместимости между версиями языка;
— отсутствие каррированых по дефолту функций на уровне языка
— уродский optional вместо result, как базовый тип;
— отстутствие интероперабельности с С++;
— зашитая в бандле стандартная либа;
— наличие форсированного optional (optional!);
— наличие исключений;
— наличие анвраппинга оптионалов через if let, guard;
— вызов внутренних методов и проперти без self;
— shadowing переменных в областях видимости без ворнингов.
— кривая интероперабельность с objective-c (чего по дефолту стоит возврат из методов в optional! виде, если в objc коде нет спецификаторов дял подсказки, типа nullable);
— отсутствие кодогенерации (макросы/шаблоны/доступ к ast);
— крайне нелогичный захват локальных переменных при отсутствии/наличии списка захвата.

Можно нашкрести еще, но мне лень.

Добавлю наверно designated / convenience инициализаторы.

Та не. Эт, как раз. Годно. А то насмотрелся я уже на тех, кто в UIView init перегружает, а потом удивляется, что неработает. В обжективе тоже была беда, пока NS_DESIGNATED_INITIALIZER не ввели.

бажный компилер

,

бажная среда разработки

Да, Xcode конечно ужасненький если сравнивать с IDE типа IntelliJ

нет совместимости между версиями языка

 — язык еще молодой дальше наверно проще с этим будет

отсутствие каррированых по дефолту функций на уровне языка

Насколько я знаю возможна реализация через generics. Реально часто используете каррирование ?

уродский optional вместо result, как базовый тип

optional одно из главных преимуществ Swift

наличие исключений

 И это минус ? Лол

наличие анвраппинга оптионалов через if let, guard

 А как же еще можно писать нормальный код при работе c опшиналами ? guard можно использовать не только с optional

вызов внутренних методов и проперти без self

 А зачем вызвать их через self ?

Да, Xcode конечно ужасненький если сравнивать с IDE типа IntelliJ

Я смеялся. По сравнению с хкодом, идея — тот еще понос.

язык еще молодой дальше наверно проще с этим будет

Смотря на изменения стандарта свифта после версии 3, которые сейчас мусолятся сообществом, у меня возникают сомнения в том, что это будет скоро.

Насколько я знаю возможна реализация через generics. Реально часто используете каррирование ?

Возможна, но выглядит и читается хреново, type inference захлебывается. И компилер крякает. О том, что дженерики надо автогенерировать отдельно я вообще молчу. Пруф: github.com/...master/Swiftz/Curry.swift

Реально часто используете каррирование ?

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

optional одно из главных преимуществ Swift

Вы точно уверены, что понимаете достаточно языка, чтобы говорить о его преимуществах? А то пока никто из сильных девов не понимает, многие задают вопрос о том, как этим корректно пользоваться и экспериментируют, а пионэры перепевают маркетологические бредни яблока. Хочу также уточнить, на каких языках еще вы писали (кресты, жабу и шарп языками не считаем априори), чтобы понимать лучше вашу аргументацию?

Также, изучите, что такое result, потом возвращайтесь. ХОтя нет, проведу ликбез на примитивном примере: gist.github.com/...b7f585762975939f69d315beb Очевидные преимущества пояснять? Или хоть до этого додумаетесь, раз не додумались прочитать, о чем же говорит оппонент, перед тем, как размахивать своим мнением?

И это минус ? Лол

Безусловно. Нарушение контрол-флоу, как минимум. Ну кроме того, тем же резалтом исключения можно загнать под шконку и забыть о них, как о страшном сне. Можно было бы и самому извернуться и написать какую-нить обертку дял преобразования функций с эксепшнами в Result, но не тут-то было. type inference не справляется с функциями с исключениями и не может из функции вывести, какой тип исключения кидается. Пруф: gist.github.com/...c7912438ca0f3ef1bbd2fdc28

А как же еще можно писать нормальный код при работе c опшиналами?
Эмм... map, apply, bind для цепочек? Perform/dispatch для замыканий типа (T) -> Void в объектном стиле? Что-нить говорит вообще вам? Или вы считаете, что optional — это просто зануляемая переменная?

Код описываемый вами (иф летами и прочими гадостями) нормальным не является. Посему, не льстите ему.

guard можно использовать не только с optional

Вы хоть читаете, то, что ставится в претензию? Процитирую:

наличие анвраппинга оптионалов через if let, guard
Причем тут гард к другим случаям?
А зачем вызвать их через self ?

Гарантия скоупа и понимания, что вызвав функцию print, переопределенную внутри вашей области видимости, вы вызовете именно свою функцию, а не глобальную. Хоть слегка отбивает желание лазать каждый раз и вызывать метод вместо кеширования в локальные переменные. Эксплиситно показывает, что мы имеем дело не с переменной, а с геттером/сеттером дял проперти свифтовых. Контрдоводы?

Я смеялся. По сравнению с хкодом, идея — тот еще понос.

Нужны аргументы.
Преимущества IntelliJ:
— Разнообразный рефакторинг. В Xcode для Swift нету даже рефакторинга переименования, для Objective-C есть рефакторинг но намного беднее идеи
— Стабильность, скорость работы. Xcode часто вылетает, зависает при переходе со сториборда в код, не редко нужно клинить проект так как он иногда просто «заглючивает»
— Крутой автокомплишн который учитывает множество факторов
— Лучший встроенный инструментарий для работи с системами контроля версий, возможность установить разные плагины
— Более удобная работа с зависимостями через gradle не нужно вручную выполнять команды в терминале как в случае с cocoa pods
— Настоящий эмулятор который эмулирует работу реального устройства и на который можно установить реальные приложения из гугл плея, например Facebook что часто нужно при разработке. В Xcode же симулятор который работает совсем по другому принципу (не эмулирует работу реального устройства а напрямую обрабатывается процессором) что не позволяет установить приложения из епп стора

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

Нет) гард как раз и ввели для того чтобы избежать большой вложенности (Pyramid of Doom)

А то пока никто из сильных девов не понимает, многие задают вопрос о том, как этим корректно пользоваться и экспериментируют, а пионэры перепевают маркетологические бредни яблока.

Для меня optional это преимущество потому что я точно знаю какая переменная может быть неинициализированная а какая нет, что позволяет избежать многих вылетов и сделать код более читабельным

Также, изучите, что такое result, потом возвращайтесь.

Честно говоря тот пример кода сложновато читается :) Как это связано с optional ?

кресты, жабу и шарп языками не считаем априори

Почему ?

Хочу также уточнить, на каких языках еще вы писали

Плюсы, жаба, шарп, немного жаба скрипт, обжектив, свифт :)

Код описываемый вами (иф летами и прочими гадостями) нормальным не является

 Ну это же и есть нормальный код для свифта судя по документации Apple, как по мне читается нормально

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

 Не часто бывает так что функция или переменная переопределяется внутри области видимости, а если это так то в этом случае можно использовать self, но заставлять использовать self всегда это имхо не правильно

Не в тему топика, хочу вставить свои 5 копеек:

— Настоящий эмулятор который эмулирует...
Я не знаю разрабатываете ли вы на андроид, но я слышал отзывы что как раз таки эмулятор это печаль и беда, т.к. загрузка занимает много времени по сравнению с симулятором.

Стандартный эмулятор работает нормально если процессор поддерживает виртуализацию и включено использование GPU. Но есть также сторонний бесплатный эмулятор который работает быстрее iOS симулятора.

Да не работают они быстрее симулятора iOS. В последнем Android Studio хоть какие-то шаги в сторону ускорения загрузки/перезагрузки начались, но еще буквально год назад у меня уходило до 5 минут для того чтобы перезапустить приложение в эмуляторе и всего секунд 10 для того же в Xcode.

Нужны аргументы. Преимущества IntelliJ:

Недостатки IntelliJ:
— gradle работает абы как с точки зрения портабельности, нет гарантии того, что открыв тот же проект на другой машине, вы его даже скомпилить сможете;
— нет возможности по-челоечески искать, поиск по проекту заставляет иногда рыдать;
— очень неудобен переход к классу из кода;
— очень неудобно лазать по хедерам стандартной либы;
— тормозной автокомплишн, очень редко показывает то, что надо напечатать;
— эмулятор не запускаецца на многих процах, т.е. даже не все современные поддерживают технологию виртуализации, которая нужна;
— крайне неудобные настройки визуальной репрезентации стиля;
— при отладке, не переходит туда, откуда несловленный эксепшн был отправлен;
— при отладке в лог гадит и сама система, и ваше приложение.

Если брать конркетно аппкод, то туда же:
— нет интерфейс билдера;
— интеграция с отладкой оставляет желать лучшего;
— для билда и релиза все равно нужен хкод;
— сомнительная интеграция с тестами, которая обалдевает от поведенческих фреймворков, типа Kiwi.

Нет) гард как раз и ввели для того чтобы избежать большой вложенности (Pyramid of Doom)

Приведите пример, как вы с помощью гардов избавитесь от большого количества бойлерплейта. Для примера, преобразуйте этот код: gist.github.com/...a3b7816007bdfc86ce479f473

Для меня optional это преимущество потому что я точно знаю какая переменная может быть неинициализированная а какая нет, что позволяет избежать многих вылетов и сделать код более читабельным

Простите, но то, как вы описываете использование optional не приводит к читаемости, т.к. у вас адово количество бойлерплейта.

Честно говоря тот пример кода сложновато читается :) Как это связано с optional ?

Звыняйте, женерики — они такие, да и корректировать стилистику тестового примера откроенно лень, т.к. в реальной жизни я бы писал не так, а писать кучу протоколов дял того, чтобы показать пример типа — бессмысленно.

С оптионал связано напрямую, т.к. базовый тип оптионал — дериватив either, как и result, но не несет долстаточно полезной информации. Выбран, как базовый зря, о чем я упоминал в изначальном сообщении из-за усечения полезной информации в .None. Все-таки у нас основное — это вычисления, а не хранение, с описанием которых result справляется на порядок лучше.

Почему ?

Статический прошлый век с кучей бойлерплейта из-за статической типизации и недостаточности type inference. Т.е. то, как не надо писать в свифт и как пишет большинство.

Ну это же и есть нормальный код для свифта судя по документации Apple, как по мне читается нормально

По документации эппл все находится в контроллере и предварительная логика во viewDidLoad. Кивать на кал в примерах эппл не имеет смысла. Мы ж таки не индусы, не?

Плюсы, жаба, шарп, немного жаба скрипт, обжектив, свифт :)

Так понимаю, сильными сторонами обжектива вы не пользовались от слова «никогда»? Скажите, как вы бы написали на свифте и обжективе прокси, который часть методов оборачивает, а часть проксирует.

Не часто бывает так что функция или переменная переопределяется внутри области видимости, а если это так то в этом случае можно использовать self, но заставлять использовать self всегда это имхо не правильно

При использовании гардов и ифлетов — часто. Либо вносить новые не значащие имена. Кроме того, нет гарантии, что этого не произойдет и кто-то не досмотрит. Так хоть видно. Более того, так и для посвященных понятно, что геттеры постоянно дергать не надо.

эмулятор не запускаецца на многих процах, т.е. даже не все современные поддерживают технологию виртуализации, которая нужна;

для девелопмента это неправильные процессоры, особенно когда есть вагон десктопных и ноутбучных с поддержкой оной

Точно. Совсем забыл, что надо выкинуть ноут с i3 только ради того, чтобы запустить эмулятор. Android — way, однако.

Кто ж тебе доктор, что i3 брал. Хардварная виртуализация для того и придумана, чтоб фигней не страдать.

Мне никто, у меня i7. Но ви-таки, только что подтвердили невалидность и неоправданность утверждений моего оппонента. Благодарочка.

Не понял чем. Системные требования повыше, ну так и ок. Да и кроме ведроида бывает надо виртуалку запустить.

Тем, что эмулятор — плюс. Все равно на реальных девайсах надо тестить, а эмулятор не особо и спасет многих девов, т.е. ценность сомнительная. Выбирать железки, чтобы девелопить на дроид — эт абсурд, как-никак.

У мене i3 і емулятор андроїда прекрасно себе почуває. Що я роблю не так?
В мене таке відчуття, що ви змішуєте враження від AppCode з усіма іншими продуктами jetbrains. Так склалося, що спільного у них мало, починаючи з кодової бази.
— Портабельність gradle. Ви, певно, щось плутаєте. Проблема не в градлі, а в людях. У мене на останній роботі не збирався проект на вінді через те, що в гредл-тасках була використана робота з інструментами консолі. Я сподіваюся, ви розумієте, що це не проблема гредлу?
— Пошук. Ну от не знаю, мене double-shift i ctrl+shift+F повністю задовольняють.
— Перехід до класу. Це ви про ctrl+click? Мені норм, я не з класу тих, хто не використовує мишку. Плюс я впевнений, що на це можна забіндити шорткат.
— Автокомплішен андроїда студії, особливо для джаві — це краще, що коли-небудь зі мною ставалося. Є проблеми з groovy, але це таке. Ніхто в jetbrains ухил на неї не робив. Динамічна мова у цьому плані завжди програватиме тій же джаві. До того ж, скоро можна буде свої андроїдові білд-скріпти перевести на котлін, де автокомплішен теж хороший.
— Про емулятор вже сказав зверху. X86 працює досить швидко. Для запуску на amd є arm-образи. Також завжди можна спробувати genymotion. Він має працювати всюди, де заводиться virtualbox. Плюс є різниця між емулятором і симулятором. Емулятор — це фактично реальний бігаючий на віртуалці андроїд, який набагато ближче до кінечних девайсів, ніж симулятори.
— Про дебаг не зрозумів.
— Для логу є фільтри, «вы просто не умеете их готовить».
— Про аппкод нічого,хорошого сказати не можу, не користувався, але вони мають підстроюватися під обмеження apple, що стосується тих же білдів.

У мене i3 і емулятор андроїда прекрасно себе почуває. Що я роблю не так?

ark.intel.com
Вам повезло, но вписать это в сильную сторону при таком ограничении, как сделал мой оппонент, не выйдет.

В мене таке відчуття, що ви змішуєте враження від AppCode з усіма іншими продуктами jetbrains. Так склалося, що спільного у них мало, починаючи з кодової бази.

Пользовал RubyMine, PHPStorm, WebStorm, AppCode, Android Studio, Idea.

У них всех общие болячки, которые я и описал выше.

— Портабельність gradle. Ви, певно, щось плутаєте. Проблема не в градлі, а в людях. У мене на останній роботі не збирався проект на вінді через те, що в гредл-тасках була використана робота з інструментами консолі. Я сподіваюся, ви розумієте, що це не проблема гредлу?

Пробелма гредла, о которой я упоминал, не в скриптах, а в окружении. Необходимо полностью одинаковое окружение, чтобы гредл сработал. Причем, я говорю не о версии гредла, а именно об окружении. И это — пробелма гредла, а не людей. Править конфиги под разные окружения на разных девайсах — не айс и не плюс. Те же подсы или картеж, которым противопоставляет гредл мой оппонент, таких болячек не имеют.

— Перехід до класу. Це ви про ctrl+click? Мені норм, я не з класу тих, хто не використовує мишку. Плюс я впевнений, що на це можна забіндити шорткат.

По правому клику перейти нельзя. ктрл-клик — надо еще догадаться.

— Пошук. Ну от не знаю, мене double-shift i ctrl+shift+F повністю задовольняють.

Найдите все применения в одном файле и по ним поперескакивайте. Тот же хкод намного более удобен.

— Автокомплішен андроїда студії, особливо для джаві — це краще, що коли-небудь зі мною ставалося.

Даже в хкод лучше, хотя тоже ужасен.

— Про дебаг не зрозумів.

При падении не переходит на строку, где упало. Очень недобно посматривать состояние стека и кучи, неудобнго просматривать локальные переменные.

— Для логу є фільтри, “вы просто не умеете их готовить”.

И это грустно. Мне надо сдлеать +1 действие чисто дял того, чтобы посмотреть на то, что происходит в моем приложении. Или вы параллельно еще и дебажите сам дроид. Управление дебагом из командной строки тоже неудобно, т.к. у вас лог в одном месте, а консоль в другом.

— Про аппкод нічого,хорошого сказати не можу, не користувався, але вони мають підстроюватися під обмеження apple, що стосується тих же білдів.

Так таки тоже кал.

Пробелма гредла, о которой я упоминал, не в скриптах, а в окружении.

Навіть якщо такі проблеми і є, то це проблеми не IDE.

вписать это в сильную сторону при таком ограничении, как сделал мой оппонент, не выйдет.
Це не сильна сторона, але, по-перше, це не стосується студії, і по-друге, це не недолік, а апаратні вимоги. Коли якійсь грі потрібно більше ОЗУ, ніж є на компі, це проблеми користувача компа.
Пользовал RubyMine, PHPStorm, WebStorm, AppCode, Android Studio, Idea.
ктрл-клик — надо еще догадаться.
От про що з вами після цього можна говорити?) 6 IDE, і ні в одній ви не знайшли перехід до класу? А загуглити? А що, якщо я вам скажу, що є шорткати ctrl+shift+i для швидкого перегляду сорців елемента у плаваючому вікні? А як ctrl+q для швидкої документації?

Про те, що

Даже в хкод лучше
автокомплішен після цього не варто і говорити. Ви, певно, про ctrl+shift+space і завершення по табу теж не чули, як і про ctrl+click.
Найдите все применения в одном файле и по ним поперескакивайте.
«Применения» чого? Ctrl+F і слрілки вверх-вниз (shift+f3 i f3) не проходять? Тоді є Alt+f7 — всі використання змінної/методу/etc, в тому числі і в поточному файлі, ctrl+click на оголошення змінної/методу — те ж саме, тільки в плаваючому вікні.
Мне надо сдлеать +1 действие чисто дял того, чтобы посмотреть на то, что происходит в моем приложении
Фільтри настроюються 1 раз. І знову претензія до IDE, коли насправді це проблема андроїда. Тим більше, ці логи потрібні.
Управление дебагом из командной строки тоже неудобно
Навіщо? Чим вас не влаштовує для логів android monitor? Там навіть регекспом можна логи відфільтрувати, а ви ще й носом вернете)
При падении не переходит на строку, где упало.
В джаві/андроїді в лог пишеться стектрейс, з яким можна погуляти по всім місцям, що призвели до падіння. Лінки на власний код виділені. І дебаг цілком нормальний, на локальні змінні можна ставити вотчери, брекпоїнтам задавати умови саспенду, скажімо, за значенням змінних, або взагалі щоб на них програма не зупинялася, а писала щось у дебаг лог. В хіпі нечасто доводиться на андроїді ритися, так що тут не скажу, що вам там не подобається.

Загалом, складається враження, що ви просто ниасилили. Я теж пробував xcode і можу кричати, що

тот же хкод та же студия намного более удобна
але я розумію, що я недостатньо обізнаний з нею, щоб робити такі категоричні заяви. Ви ж не знаючи про елементарний ctrl+click репетуєте тут, що студія щось, що погано пахне. Не треба так.
Навіть якщо такі проблеми і є, то це проблеми не IDE.

Если бы вы потрудились, то увидели бы, что я овтечаю на претензии моего оппонента, что он указал, как плюс идеи, то я и разбил. dou.ua/...aign=reply-comment#985254

Це не сильна сторона, але, по-перше, це не стосується студії, і по-друге, це не недолік, а апаратні вимоги. Коли якійсь грі потрібно більше ОЗУ, ніж є на компі, це проблеми користувача компа.

Опять же, мой оппонент вписал это в сильную сторону, но это не так. Более того, все равно надо на девайсе тестить, поэтому, здесь мне было просто приятно потоптаться по оппоненту. И да, мы с вами не в игрушки играем. Когда не поддерживается куча меинстримных процессоров, что-то не так, не так ли?

От про що з вами після цього можна говорити?) 6 IDE, і ні в одній ви не знайшли перехід до класу? А загуглити? А що, якщо я вам скажу, що є шорткати ctrl+shift+i для швидкого перегляду сорців елемента у плаваючому вікні? А як ctrl+q для швидкої документації?

Я все нашел, однако, все это крайне неудобно, т.к. нет простого перехода из контекстного меню. О том, что чтобы пеосмотреть доку, надо жать дополнительные хоткеи — вообще отдельная песня. В хкоде ее можно посмотреть всегда. Только каретку установите на метод.

автокомплішен після цього не варто і говорити. Ви, певно, про ctrl+shift+space і завершення по табу теж не чули, як і про ctrl+click.

Вы не поверите, но в хкоде все то же самое есть, более того, не надо жать никаких дополнительных хоткеев. Аналог автокомплита по табу также есть. Странно, да?

“Применения” чого? Ctrl+F і слрілки вверх-вниз (shift+f3 i f3) не проходять? Тоді є Alt+f7 — всі використання змінної/методу/etc, в тому числі і в поточному файлі, ctrl+click на оголошення змінної/методу — те ж саме, тільки в плаваючому вікні.

Сравните с хкод. Есил я не хочу выделять переменную, а просто хочу ввести поисковую строку, то тут мне alt-f7 не помощник, не так ли?

Фільтри настроюються 1 раз. І знову претензія до IDE, коли насправді це проблема андроїда. Тим більше, ці логи потрібні.

Их надо настраивать. Закапывайте. Это, как раз, неудобство. Создать дефолтные фильтры в качестве удобных контроллов — религия не позволяет? Или не java-way?

Навіщо? Чим вас не влаштовує для логів android monitor? Там навіть регекспом можна логи відфільтрувати, а ви ще й носом вернете)

Я не говорю о логах. Я говорю об управлении дебагов. Почитайте, как работает gdb, сравните с вашими возможностями.

В джаві/андроїді в лог пишеться стектрейс, з яким можна погуляти по всім місцям, що призвели до падіння. Лінки на власний код виділені. І дебаг цілком нормальний, на локальні змінні можна ставити вотчери, брекпоїнтам задавати умови саспенду, скажімо, за значенням змінних, або взагалі щоб на них програма не зупинялася, а писала щось у дебаг лог. В хіпі нечасто доводиться на андроїді ритися, так що тут не скажу, що вам там не подобається.

С точки зрения юзабилити, всегда переход на место падения интересен пользователю Т.е. у вас +1 клик мышкой. Во вторых, при эксепшне кладется приложение, т.е. посмотреть не только колл стек, но и сам стек надо бы, но просто прямых путей для этого нет. Это — огромный минус. Вновь таки, киньте исклчюение в хкоде и сравните удобство.

Дебаг рудиментарен, нет много полезного, например, нормального принта в консоль, чтоыб не лазить по всем переменным во вьюере.

Как это нечасто? Никогда не надоб ыло проследить за изменением поля в объекте? В хкоде с этим тоже жах, хоть и есть просмотр кучи, но вот вотч лист — адово знаятие.

Загалом, складається враження, що ви просто ниасилили. Я теж пробував xcode і можу кричати, що

О! Знакомые крики от джавистов. Когда им говоришь о реальных пробелмах, начинают плакать о ниасилили.

але я розумію, що я недостатньо обізнаний з нею, щоб робити такі категоричні заяви. Ви ж не знаючи про елементарний ctrl+click репетуєте тут, що студія щось, що погано пахне. Не треба так.

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

Знакомые крики от джавистов. Когда им говоришь о реальных пробелмах, начинают плакать о ниасилили.
По аналогії: знайомі крики від айосніків. Коли їм показуєш функцію, вони вертять носом, бо це не кнопочка: «Зробити красиво».
Когда не поддерживается куча меинстримных процессоров, что-то не так, не так ли?
Те, що куча мейнстрімних процесорів не підтримує VT-x, це проблема процесорів. Як я вже казав, у мене core i3 3-го покоління, і він усе підтримує. Заглянув у спеки деяких мобільних проців i3 другого покоління — теж підтримують. Більш «домохозяєчних» проців серед програмістів треба пошукати. Але якщо знайдете, вам вже, як я казав, надали альтернативу у вигляді armeabi-емуляторів, або ж Genymotion. У iOS є альтарнативні симулятори?
нет простого перехода из контекстного меню. О том, что чтобы пеосмотреть доку, надо жать дополнительные хоткеи — вообще отдельная песня. В хкоде ее можно посмотреть всегда. Только каретку установите на метод.
Мене бісило би, якби при кожному встановленні каретки на метод вискакував би попап з доками. Але ж звісно, Apple знає, як ліпше, навіть для девелоперів. Ясно-понятно. В настройках чи шукали, навіть не питаю
Вы не поверите, но в хкоде все то же самое есть, более того, не надо жать никаких дополнительных хоткеев.
Тобто, автопопапу компліту в студії ви не помітили? А ще студія розуміє, який тип вам потрібен в даному контексті. Також уміє шукати ось так по ctrl+space+space yadi.sk/i/fzF4qdKPvaCcz
Есил я не хочу выделять переменную, а просто хочу ввести поисковую строку, то тут мне alt-f7 не помощник, не так ли?
Я вам вже казав про ctrl+shift+F для пошукового рядка по всьому проекту, але ви мене не чуєте. І ctrl+F для поточного файлу. Кнопочки шукати в меню, якщо вам так легше.
Их надо настраивать. Закапывайте. Это, как раз, неудобство. Создать дефолтные фильтры в качестве удобных контроллов — религия не позволяет?
Ви взагалі java-ідеологію пакетів зрозуміли, чи ні? У одному проекті може бути купа пакетів, як і модулів. І як студія вам має вибирати, що показувати? Які тут можуть бути дефолтні фільтри, якщо пакети у кожного проекту свої? Студія намагається по дефолту фільтрувати по процесу, але при креші він може померти (до вашого пункту про зникання логу), тому треба токласти зусиль і додати аж цілий фільтр. Але, як я розумію, серед яблучних девелоперів щось настроювати не прийнято. Буває.
С точки зрения юзабилити, всегда переход на место падения интересен пользователю Т.е. у вас +1 клик мышкой.
Меню Run -> View Breakpoints -> Exception Breakpoints. А, я ж забув, ви нічого не плануєте настроювати.
нет много полезного, например, нормального принта в консоль,
Right click по брейкпоїнту -> Log message to console або log evaluated expression.

Монітори присутні на вкладці Android monitor і підвкладці Monitors. Робіть там Dump Java Heap скільки хочете.

По аналогії: знайомі крики від айосніків. Коли їм показуєш функцію, вони вертять носом, бо це не кнопочка: “Зробити красиво”.

Так я этого и не отрицаю. Я изначально в претензиях говорил, что студия неудобна. И дело тут не в конопоччке сделать красиво, а в том, что банальный функционал сделан неудобно.

Як я вже казав, у мене core i3 3-го покоління, і він усе підтримує.

Я дал вам ссылку на поддержку. Куча ноутов не поддерживает.

У iOS є альтарнативні симулятори?

Нет.

Але якщо знайдете, вам вже, як я казав, надали альтернативу у вигляді armeabi-емуляторів, або ж Genymotion.

Главное — то, что этог не сильная сторона, как указал мой оппонент. И вы это подтвердили.

Мене бісило би, якби при кожному встановленні каретки на метод вискакував би попап з доками. Але ж звісно, Apple знає, як ліпше, навіть для девелоперів. Ясно-понятно. В настройках чи шукали, навіть не питаю

Меня бы тоже попап бесил. Благо, это же не интеллиж, которым впадлу подумать об удобстве девов. Ну и да, боковой тулбар мона и спрятать, если не нужен.
imgur.com/a/NFbJq

Тобто, автопопапу компліту в студії ви не помітили? А ще студія розуміє, який тип вам потрібен в даному контексті. Також уміє шукати ось так по ctrl+space+space yadi.sk/i/fzF4qdKPvaCcz

Как я и говорил ранее, он неудобен и тормознут. Т.е., все то же самое, что и в хкоде,, но менее удобно. О чем и писал изначально.

Я вам вже казав про ctrl+shift+F для пошукового рядка по всьому проекту, але ви мене не чуєте. І ctrl+F для поточного файлу. Кнопочки шукати в меню, якщо вам так легше.

Я ж вам сказал, что это неудобно. Вот почему в идее нет в результате поиска серчбара и надо жать что-то еще просто, чтобы изменить критерии поиска. Т.е, почему нет вот чегшо-то такого: imgur.com/a/Cm9lG
Именно об этом я и говорил ,как о неудобстве. У вас результат поиска в одном мексте, серч бар в другом, причем еще его зачастую и не видно, пока хоткей не нажмешь.

Ви взагалі java-ідеологію пакетів зрозуміли, чи ні? У одному проекті може бути купа пакетів, як і модулів. І як студія вам має вибирати, що показувати? Які тут можуть бути дефолтні фільтри, якщо пакети у кожного проекту свої? Студія намагається по дефолту фільтрувати по процесу, але при креші він може померти (до вашого пункту про зникання логу), тому треба токласти зусиль і додати аж цілий фільтр. Але, як я розумію, серед яблучних девелоперів щось настроювати не прийнято. Буває.

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

Меню Run -> View Breakpoints -> Exception Breakpoints. А, я ж забув, ви нічого не плануєте настроювати.

Именно, зачем это делать, если это можно вклчюить по дефолту? Ну да, студия настолько удобна, что базовое поведение по дефолту не включено.

Right click по брейкпоїнту -> Log message to console або log evaluated expression.

Как я уже упоминал ранее, я говорю о работе с командной строкой дебаггера сейчас. К брейкпоинтоам оно не имеет никакого отношения.

Монітори присутні на вкладці Android monitor і підвкладці Monitors. Робіть там Dump Java Heap скільки хочете.
Не то пальто. Я говорил об этом:
Никогда не надоб ыло проследить за изменением поля в объекте? В хкоде с этим тоже жах, хоть и есть просмотр кучи, но вот вотч лист — адово знаятие.

Итого, мой уважаемый собеседник, мы пришли к тому, с чего я начал, вы уже сами оправдываете неудобство студии, которые были озвучены мною в изначалньом посте и кричите, что в одну кнопочку — это не андроид-вей, как и банальные дефолтные поеведния. Т.е., мой поинт таки валиден. Спасибо за подтверждение.

Мені от цікаво, з яких це пір те, до чого конкретно ви звикли, стало дефолтною поведінкою?) Половина вами перечисленого — справа звички.

Как я уже упоминал ранее, я говорю о работе с командной строкой дебаггера сейчас. К брейкпоинтоам оно не имеет никакого отношения.
Брейкпоїнти пишуть в дебаг-лог. Або я не розумію, який ще вам лог потрібен.

Але ок, ваш поїнт я зрозумів: «На вкус и цвет фломастеры разные, но у меня все равно лучше».

Мені от цікаво, з яких це пір те, до чого конкретно ви звикли, стало дефолтною поведінкою?)

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

Те, що вам здається звичним зі свого досвіду, для інших буде незручним. Той же стектрейс для багатьох джавістів цікавіший за перескакування одразу на місце падіння. Мені, наприклад.
Взагалі, вам варто не переносити свої звички з одного інструменту на інший, а, скажімо, подивитися пару толків про студію/ідею зі способами використовувати її ефективніше. З останнього цікавого і корисного realm.io/...-search-refactoring-java про пошук там дещо теж є.

Той же стектрейс для багатьох джавістів цікавіший за перескакування одразу на місце падіння. Мені, наприклад.

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

Взагалі, вам варто не переносити свої звички з одного інструменту на інший, а, скажімо, подивитися пару толків про студію/ідею зі способами використовувати її ефективніше. З останнього цікавого і корисного realm.io/...-search-refactoring-java про пошук там дещо теж є.

Почему мне стоит это делать? Я за свою жизнь попользовался многими инструментами и меня всегда забавляет, как адепты идеи упоминают что-то о ее удобстве. Единственное, что в ней реально прикольное — это регекспы. Все остальная детятельность на идеевских продуктах — это просто банальное отсутствие анализа юзабилити.

эмулятор не запускаецца на многих процах, т.е. даже не все современные поддерживают технологию виртуализации, которая нужна;
Так юзай симулятор, в чём беда. А вообще девайс самое то.
Так юзай симулятор, в чём беда. А вообще девайс самое то.

Девайс — самое то. Я просто указал, что это — не плюс, как пытался доказать мой оппонент.

— при отладке в лог гадит и сама система, и ваше приложение.
Фильтр в помощь.
gradle работает абы как с точки зрения портабельности, нет гарантии того, что открыв тот же проект на другой машине, вы его даже скомпилить сможете;
— нет возможности по-челоечески искать, поиск по проекту заставляет иногда рыдать;
— очень неудобен переход к классу из кода;
— очень неудобно лазать по хедерам стандартной либы;
— тормозной автокомплишн, очень редко показывает то, что надо напечатать;
Та брось, мож просто оперативы мало, всё там ништяк работает, RAM’a просто студия много ест.
Фильтр в помощь.

+1 действие. Или вы дебажите параллельно с приложением и сам дроид. Наф этот мусор в дебаг логе?

Та брось, мож просто оперативы мало, всё там ништяк работает, RAM’a просто студия много ест.

16 гиг. Не знаю, как по мне, норм. Юзабилити на низком уровне. Тот же эклипс мне нравился намного больше в период его расцвета.

Так и до вима дойти можно

Ну... Юзабилити вима сомнительна, не?

Недостатки IntelliJ

Это на какой версии IntelliJ было ? Вы умеете ею пользоваться ?

Приведите пример, как вы с помощью гардов избавитесь от большого количества бойлерплейта. Для примера, преобразуйте этот код: gist.github.com/...a3b7816007bdfc86ce479f473

Код: gist.github.com/...​a890a39f263fb5c37cc746480

Простите, но то, как вы описываете использование optional не приводит к читаемости, т.к. у вас адово количество бойлерплейта.

Это не бойлерплейт, потому что если я что-то объявляю optional я знаю что там может не быть значения поэтому нужна дополнительная проверка в отличии от Objective-C который просто вылетит при доступе к nil

Статический прошлый век с кучей бойлерплейта из-за статической типизации и недостаточности type inference.

А лучше дебажить какие-то чудовищные баги которые могут появиться из за динамической типизации ?

прошлый век

Objective-C конечно не прошлый век (появился в 1983г если что)

По документации эппл все находится в контроллере и предварительная логика во viewDidLoad.

Я писал про документацию Swift (она помоем по лучше написана) а не iOS SDK.

При использовании гардов и ифлетов — часто.

Вы точно понимаете как работают if let и guard let ? Если вы делаете проверку переменной класса через эти операторы использовать self для доступа к этой переменной не нужно (так как она будет опциональная)

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

Код: gist.github.com/...a890a39f263fb5c37cc746480

Этот код ничем не отличаецца от gist.github.com/...5be6580e8069bdba06799f2d3 Он имеет весь тот же бойлерплейт, т.е. вы не сократили его ни на грамм.

Это не бойлерплейт, потому что если я что-то объявляю optional я знаю что там может не быть значения поэтому нужна дополнительная проверка в отличии от Objective-C который просто вылетит при доступе к nil

Первое, в обжектив-с отправка сообщений нулю не приводит к падению. Единственный кейс, когда этого делать нельзя также не приводит к падению. Вам рассказать этот кейс или предпочтете еще раз опозориться?

Второе, это все еще бойлерплейт. Дублирующийся код не несущий никаких полезных данных. Он свидетельствует лишь о том, что вы не умеете пользоваться свифтом и его пусть и примитивной, но тайп-инференс. Спецом для вас написал два варианта.

С оптионалом, который плох, по указанным мной ранее причинам:
gist.github.com/...f7e1ebd9551ef1381485cf8bf
И резалт:
gist.github.com/...2ed457ab6cdc09469f10208c6

Я не убирал все дублирование в типе Result, т.к. мне лень ради вас этим заниматься, но это можно сделать, используя flatMap в качестве точки входа. Если дял вас это так интересно и у меня будет время и настроение, может и нарисую.

Из этих сниппетов явно видно преимущество резалт над оптионал, которые ранее я указывал без примеров. ТАкже, из этих сниппетов прекрасно видно, что ни гард, ни иф лет не нужны, т.к. потом подобные вам пишут фигню с кучей дублирвания, подобную показанной вами. Так бы у вас вариантов не было.

Я вот все думаю, что ж вы никак не поймете, о чем я. А потом понял, что вы в силу своей некомпетентности и самоуверенности так и не удосужились прочитать, что же такое optional, result и either. В принципе, для джуна и неудивительно, которому лишь бы фигак-фигак и в продакшн.

И да, вы можете попытацца возразить, что кастомные операторы — это плохо, однако, вас же не смущают операции, типа +, как операторы. ТАк вот, map, apply, flatMap в терминологии свифта — это такие же математические операции. Но, к сожалению, поскольку вы не знаете, что такое монада, аппликатив и функтор, для вас это все дико. Естессно, я бы с большей радостью кастомные операторы заменил на символьные операторы, но свифт настолько примитивен, что не позволяет выражать все, что душе угодно, поэтому операторы позволено делать только с определенным character set.

Сами операторы для унификации взял из Swiftz.

Есстессно, без использования вообще операторов, выразительность теряется:
gist.github.com/...25e9e0190816ba8a1e911a6b5

Безусловно, вы можете возразить, что у меня больше кода написано, однако, операции, описанные мною стандартны для работы с функциями и контекстами (чем является и optional, и result) и отлично описаны где только можно, являются частью математики из теории категорий, да и пишутся один раз, т.е. переиспользуемы.

Я писал про документацию Swift (она помоем по лучше написана) а не iOS SDK.

Угу. Отличная дока, в результате который юные падаваны, вроде вас, выдают кал, подобный этому: gist.github.com/...a890a39f263fb5c37cc746480

Вы точно понимаете как работают if let и guard let ? Если вы делаете проверку переменной класса через эти операторы использовать self для доступа к этой переменной не нужно (так как она будет опциональная)

Я уверен в своем понимании, т.к., несмотря на то, что не готов переводить свою фирму на свифт, уже два года бьюсь над вопросом о том, как его корректно использовать дял того, чтобы минимизировать код и улучшить читаемость. Также, как и уверен в том, что и свифт, и обжектив, и саму платформу я знаю на порядок лучше вас. А вот вы даже не в состоянии понять, о чем говорит ваш оппонент. Попробуйте еще раз. На этот раз воспользуйтесь мозгом для анализа.

А лучше дебажить какие-то чудовищные баги которые могут появиться из за динамической типизации ?

Если при разработке пользоваться мозгом, то их не возникает. Я понимаю, вам это сложно, но вы попробуйте. Созадйте конвенции именования и стилизации, и все у вас будет ок. Забудете о статической типизацйии с кучей бойлерплейта, как о страшном сне.

Objective-C конечно не прошлый век (появился в 1983г если что)

Безусловно не прошлый. Как и лисп, который появился еще раньше, но по прежнему революционен в своих возможностях, что подтверждается тем, что меинстримные языки все еще тянут из него идеи.

Это на какой версии IntelliJ было ? Вы умеете ею пользоваться ?

2.1.3. Точно лучше, чем вы свифтом.

Я ждал, когда же все-таки Мобайл Девелопер раскроет, что он на самом деле некомпетентный недомобайл недодевелопер, и вот сие свершилось.

Поздравляю! Наверно сильно ждали, для вас это видно очень важно. А теперь по делу.

Этот код ничем не отличаецца

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

Первое, в обжектив-с отправка сообщений нулю не приводит к падению.

Если попробовать добавить такой объект в массив, словарь — вылетит.

Второе, это все еще бойлерплейт.

Повторюсь еще раз, если вы сами описываете переменную как optional и дальше проверяете ее if let или guard let — это не бойлерплейт, а дополнительная обработка вариантов когда некоторые переменные могут не иметь значения.

В принципе, для джуна и неудивительно, которому лишь бы фигак-фигак и в продакшн.

Тоже наверно долго ждали чтобы это написать ? Мне интересно по вашему все девелоперы которые пишут на свифт джуны и некомпетентны ?

Если при разработке пользоваться мозгом, то их не возникает.

Реально у вас при разработке никогда не возникают баги даже с использованием динамической типизации ?
2.1.3. Точно чем вы свифтомм вы свифтом
Вряд ли) Если вы не умеете искать по проекту (там много вариантов поиска), переходить к классу из кода

Поздравляю! Наверно сильно ждали, для вас это видно очень важно. А теперь по делу.

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

Там у вас была другая ссылка и я показал как избавиться от большой вложенности с помощью guard.

Я вам не о гардах говорил, а об анвраппинге. Ни иф лет, ни гард не спасают от бойлерплейта. Более того, они его генрируют.

Если вы имеете ввиду как правильно парить json в свифт, то тут надо юзать либы которые уменьшают количество лишнего кода

Я имею в виду, как правильно пользоваться оптионакл и почему он хуже резалт, с чего началось наше изначальное обсуждение. Парсинг жсона — это просто наиболее очевидный пример. Такая же беда с гардами у вас будет в любом failable initializer, где нет парсинга. А все от того, что вы так и не разобрались с тем, что такое optional, посему пользуете уродливые iflet/guard.

Если попробовать добавить такой объект в массив, словарь — вылетит.

Словарь — только один из методов:
gist.github.com/...9e9cb28256b85d78ca98c89aa

А вообще, лично у меня дял таких случаев уже сто лет в обед есть свои методы и свиззлинг. Более того, с тем же успехом можно гадить на оператор ! (который я, кстати, и обгадил). Однако, в общем случае нулебезопасность обежктива на том же уровне, но без лишнего бойлерплейта, в отличии от свифта, когда пишут в вашем стиле.

Повторюсь еще раз, если вы сами описываете переменную как optional и дальше проверяете ее if let или guard let — это не бойлерплейт, а дополнительная обработка вариантов когда некоторые переменные могут не иметь значения.

Вновь повторюсь, это и есть бойлерплейт. Тупое печатание чисто из-за того, что вы не умеете пользоваться type inference.

Тоже наверно долго ждали чтобы это написать?

Просто вас унижаю по мере сил, усиливая свое непомерное ЧСВ.

Мне интересно по вашему все девелоперы которые пишут на свифт джуны и некомпетентны ?

Нет, не все. Только те, кто не умеют пользоваться свифтом и пишут на нем, как на С++/С#/Java/ObjC, т.е. подобные вам.

Реально у вас при разработке никогда не возникают баги даже с использованием динамической типизации?

Да. Более того, я ей пользуюсь дял упрощения кода. Те же прокси и message forwarding дают мне возможность создавать сложную композицию без грамма лишнего кода.

Вряд ли) Если вы не умеете искать по проекту, переходить к классу из кода

Не приписывайте мне надуманные вами безосновательные утверждения. В том, что вы свифта не знаете, имели возможность убедицца все, кто читают данные тред. В обоснованности моих замечаний по юазбилити интеллиж продуктов в соседней ветке — также. Я нигде не говорил о невозможности, я гвоорил о крайнем неудобстве. И это — факт. Юзабилити продуктов интеллиж заставляет рыдать. Вот цитата моего поста, как пруф того, что ваши утверждения лишены основания:

— нет возможности по-челоечески искать, поиск по проекту заставляет иногда рыдать;
— очень неудобен переход к классу из кода;
там много вариантов поиска

И ни один из вариантов не отвечает критерию минимального удобства. Закапывайте.

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

Есть еще такое понятие как разработчик который и код пишет и формы делает

Ни иф лет, ни гард не спасают от бойлерплейта. Более того, они его генрируют.

Они спасают от вылетов еще на этапе компиляции

Вновь повторюсь, это и есть бойлерплейт.

Если вы так не любите «бойлерплейт» то как же пользуетесь обжективом когда там его хватает: хидеры которые полностью дублируют сигнатуру методов, переменных в реализации, создание переменных класса, логирование информации в консоль, лишние операторы без которых можно было бы обойтись и.т.д

Нет, не все. Только те, кто не умеют пользоваться свифтом и пишут на нем, как на С++/С#/Java/ObjC, т.е. подобные вам.

Да конечно, все же на С++/С#/Java/ObjC используют optional, guard, if let

Да. Более того, я ей пользуюсь дял упрощения кода.

Ну прям никогда не возникают баги, а если честно )

Есть еще такое понятие как разработчик который и код пишет и формы делает

Ну эт не про вас.

Они спасают от вылетов еще на этапе компиляции

Вы мне напоминаете маленького ватника. Он все причитает и плачет, покрикивая: «я вам ни верю, вы все врети». Как и вы. Я вам уже показал свифтовый код, полностью типобезопасный без использвоания этих монстров. Или вы настолько хорошо знаете свифт, что не распознали его в моих код-семплах? Или у вас просто не хватило сообразительности запустить сей код в плейграунде и посмотреть, что к чему?

Если вы так не любите «бойлерплейт» то как же пользуетесь обжективом когда там его хватает: хидеры которые полностью дублируют сигнатуру методов, переменных в реализации, создание переменных класса, логирование информации в консоль, лишние операторы без которых можно было бы обойтись и.т.д

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

1. Хедеры — это благо, как и разделение публичнгых и приватных интерфейсов в экстеншны приватные и хедер. Я готов потерпеть маленькое неудобство написания, чем не иметь подобного в свифте, где тупо глаза выпадают, если пытаешься найти нужный метод в исходнике среди микса приватных, публичных и т.п.
2. переменных в реализации, создание переменных класса, лишние операторы без которых можно было бы обойтись и.т.д — - эт вы о чем? Вы уточните, чтобы я понимал, умеете ли вы им пользвоаться также, как и свифтом или таки претензия обоснована.
3. логирование информации в консоль — эмм... А зачем вы ее логгируете, если она вам не нужна?

Да конечно, все же на С++/С#/Java/ObjC используют optional, guard, if let

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

Ну эт не про вас.

В смысле ? Откуда вы знаете что я делаю ?

Я вам уже показал свифтовый код, полностью типобезопасный без использвоания этих монстров.

Честно говоря монстром кажется тот код ) Зачем эти велосипеды когда из коробки и так есть хороший фунционал

переменных в реализации, создание переменных класса, лишние операторы без которых можно было бы обойтись

О всяких мелочах типа alloc init, @перед строкой, обязательный self(или _) и.т.д

логирование информации в консоль — эмм... А зачем вы ее логгируете, если она вам не нужна?

В смысле не нужна ?

Я о подходах к проектированию и умению пользоваться возможностями и особенностями языка.

А в чем огромные отличия свифта от джавы, си шарпа чтобы на нем писать сильно по-другому ?

В смысле ? Откуда вы знаете что я делаю ?

Мне достаточно с вами побеседовать. Вот, например, подтверждение тому, что вы формошлеп:

А в чем огромные отличия свифта от джавы, си шарпа чтобы на нем писать сильно по-другому ?

Т.е. вы взялись работать на платформе, фигак-фигак в продакшн и еще пытаетесь ее евангелизировать, даже не зная ее особенностей.

Чисто для вас:
— Расширения;
— Любой метод — замыкание;
— Type inference и pattern matching, хоть и гнилой, но лучше, чем в шарпе и яве.

ИМенно поэтому любой, кто хоть на секунду задумается о свифте, поймет, что писать на нем надо точно не так, как на яве и шарпе. Я так понимаю, у вас времени на это не нашлось?

Честно говоря монстром кажется тот код ) Зачем эти велосипеды когда из коробки и так есть хороший фунционал

Который обсепечивает массивный бойлерплейт с дублированием? Отличный функционал.

Во-вторых, монструозным велосипедом оно кажецца только дял тех, кто достаточно безграмотен, чтобы не знать, что такое map, flatMap, apply. Ну т.е. для вас.

О всяких мелочах типа alloc init, @перед строкой, обязательный self(или _) и.т.д

Как я уже указывал, отсутствие энфорса self приводит к тому, что пионеры, подобные вам, потом лазят все время в селф, созадвая кучу дублирования и неэффективности, вместо того, что кешировать в локальные переменные. Так что это — минус. Во-вторых, разделение на поле и проперти дает возможность работать с указателями на поля и убирать дублирование.
@ перед строкой обеспечивает возможность работать и с с-шными строками. Попробуйте поработать в свифте с сишными строками, количество бойлерплейта при withUnsafeMutablePointer вас приятно удивит, ведь вам дублирование нравицца.

alloc init заменяется на new. Либо метод класса. Возможно, в категории над NSObject. Т.е. бойлерплейтом является только для тех, кто не умеет пользвоатсья обжективом.

И вы так и не ответили на мой вопрос:

2. переменных в реализации, создание переменных класса, лишние операторы без которых можно было бы обойтись и.т.д
 — - эт вы о чем? Вы уточните, чтобы я понимал, умеете ли вы им пользвоаться также, как и свифтом или таки претензия обоснована.
В смысле не нужна ?

Вы указали логгирование, как минус, обсепечивающий бойлеплейт, я уточняю, зачем вы это делаете, если вам это не нужно?

Если вы так не любите «бойлерплейт» то как же пользуетесь обжективом когда там его хватает: хидеры которые полностью дублируют сигнатуру методов, переменных в реализации, создание переменных класса, логирование информации в консоль, лишние операторы без которых можно было бы обойтись и.т.д
Мне достаточно с вами побеседовать.

Нет, не достаточно

Т.е. вы взялись работать на платформе, фигак-фигак в продакшн и еще пытаетесь ее евангелизировать, даже не зная ее особенностей.

Я ее особенности знаю и активно использую extensions, closures.
— Расширения — есть базовая реализация в C#
— Замыкания тоже есть и в джаве и си шарпе
Не считаю что это кардинальные отличия

Который обсепечивает массивный бойлерплейт с дублированием?

Нет, если его правильно использовать

Как я уже указывал, отсутствие энфорса self приводит к тому, что пионеры, подобные вам, потом лазят все время в селф, созадвая кучу дублирования и неэффективности

О чем это ? Проблем с селфом в свифте нету

Нет, не достаточно

Отнюдь. Достаточно. Вы — непрофессионал, что явно выходит и из уваших утверждений, и из ваших знаний, которые вы столь любезно озвучили под час нашей дискуссии. Более того, в своей аргументации вы так и не показали свой код, т.к. вы, как я уже упомянул, юноша, который ничего не знает о платформе, на которой пытаецца писать. Сие вы еще раз любезно это подтвердили. Например:

— Расширения — есть базовая реализация в C#

Базовая реализация шарпа существенно отлична и от objc, и от swift. Естессно, вы сможете привести контраргументы с ассоциированными типами, расширениями протоколов, type inference на шарпе, не так ли?

Я ее особенности знаю и активно использую extensions, closures.
— Замыкания тоже есть и в джаве и си шарпе

Если бы вы потрудились перечитать мое сообщение, то увидели бы, что я не сказал, что в swift есть замыкания, я сказал, что любой метод является замыканием. Что далеко не одно и то же. Правда, я так понимаю, об этой особенности swift вы не знаете в принципе.

Не считаю что это кардинальные отличия

И именно из этого выплывает мое утверждение о том, что вы — профан и не имеете ни морального, ни профессионального права евангелизировать swift. Вы же его просто не знаете.

Нет, если его правильно использовать

Я продемонстрировал, как его правилньо использовать, вы показали код в котором смысловую нагрузку не несут большинство логики, что и есть первое определение бойлерплейта. Пруф кода в студию, где вы используете касты без бойлерплейта, т.к. тот ужас, котрый вы показали — это бойлерплейт в чистом виде, что вам сможет подтвердить любой опытный программист. В то же время, меня искренне интересует, как челвоек, евангелизирующий платформу, даже не удосужился разобраться, каким образом код можно писать лучше на платформе, которую евангелизирует.

О чем это ? Проблем с селфом в свифте нету

Если вы потрудитесь перечитать мои сообщения ранее, то вы увидите, что неиспользование self в свифте — это проблема. Также, я весьма четко поясчнил, почему это именно так. В ответ услышал аргументацию уровня «я вам ни верю, вы все врети». Аргументируйте на достойном профессионала уровне. Моя аргументация уже была озвучена ранее и я все еще с нетерпением жду контраргументов.

Того же я жду и по другим спорным вопросам, т.к. никакой аргументации, кроме «вы все врете» вы предоставить не смогли, что явно указывает на ваш непрофессионализм и отсутствие знаний по платформе.

Отнюдь. Достаточно. Вы — непрофессионал, что явно выходит и из уваших утверждений, и из ваших знаний, которые вы столь любезно озвучили под час нашей дискуссии.

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

Базовая реализация шарпа существенно отлична и от objc, и от swift.

Наверно поэтому я и назвал «базовая» реализация

любой метод является замыканием. Что далеко не одно и то же. Правда, я так понимаю, об этой особенности swift вы не знаете в принципе.

Знаю, и, не поверите, даже использую (я как минимум об вложенных функциях с доступом к переменным области видимости родительской функции).

Я продемонстрировал, как его правилньо использовать, вы показали код в котором смысловую нагрузку не несут большинство логики, что и есть первое определение бойлерплейта.

Повторюсь, в том примере я показал Только как избавиться от большой вложенности, для того чтобы не было бойлерплейта нужно юзать либу для парсинга джосн.
По поводу бойлерплейта в свифте не согласен, привел раньше аргументы и на обжс количество кода получаеться физически больше, это увеличивает шанс сделать где-то ошибку, тратить лишнее время на ее поиск, исправление, уменьшает читабельность кода. По поводу селф, тоже раньше писал, не вижу смысла заставлять его всегда использовать, только в closures чтобы было напоминание программисту что это strong reference на объект, может привести к утечки памяти.
Короче, спорить дальше бесполезно, вряд ли кто-то кого-то переубедит в чем-то

А разве это профессионально делать выводы не видев даже какую-то значительную часть кода, архитектурных решений, анализируя только какие-то утверждения по поводу того какой язык удобнее ?

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

Наверно поэтому я и назвал «базовая» реализация

У вас еще и со чтением пробелмы. Я и написал, что даже базовая отлична настолько, что сравнивать их и тем более писать на шарпе так, как пишут на обжективе/свифте, не выйдет.

Знаю, и, не поверите, даже использую (я как минимум об вложенных функциях с доступом к переменным области видимости родительской функции).

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

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

Знаете, что смешно? Есть куча кейсов, когда подобное надо делать не для парсинга. И там у вас либы жсона нет. Но, вы по-другому не смогжете написать, избежав бойлерплейта, т.к. просто не знаете этого и не желаете узнать. Уже могли сто раз изучить и понять, что пишете шлупости, но, я так понимаю, на то, чтобы убрать области незнания у вас времени нет, в отличии от беседы на ДОУ, в которой вы показываете свое вопиющее незнание.

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

Вы можете соглашаться, а можете нет. Но факт остается фактом — в приведенном вами примере есть бойлерплейт и вы не смогли его убрать. В то же время я вполне смог подтвердить валидность своих утверждений о том, что guard/iflet ужасен и не нужен, т.к. потом подобные вам пионеры пишут подобный вашему код.

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

По поводу селф, тоже раньше писал, не вижу смысла заставлять его всегда использовать, только в closures чтобы было напоминание программисту что это strong reference на объект, может привести к утечки памяти.

Как я и описывал раньше, не энфорс селфа приводит к ошибкам и к тому, что такие пионеры, как вы, рьяно и резво дублируют вызовы к пропертям вместо кеширования в локальную переменную, т.к. не понимают, что проперти — это метод, а не поле.

Короче, спорить дальше бесполезно, вряд ли кто-то кого-то переубедит в чем-то

Так вы пока и не спорили. У вас ни одного поинта, ни одного примера кода. Вы только оправдывались и пытались дуть щеки. Как сможете вести аргументированную дискуссию, возвращайтесь. Я с радостью с вами подискутирную, т.к. пока дискуссии не вышло, вы только расписывались в своем непрофессионализме и незнании того, о чем говорите.

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

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

Использовать платформу и не знать ее плюсы и минусы

Оценил плюсы и минусы и сделал вывод что ее ефективнее использовать

Собственно говоря, просто увидев ваш код разворота гардов уже говорит о вас все, что надо знать.

Если с первого раза не доходит пишу уже наверно раз 3 —

в том примере я показал Только как избавиться от большой вложенности

В свифт не всегда обязательно делать разворот опшиналов при их использовании, все зависит от правильности проектирования архитектуры

В то же время я вполне смог подтвердить валидность своих утверждений о том, что guard/iflet ужасен и не нужен, т.к. потом подобные вам пионеры пишут подобный вашему код.

Это вы так решили что подтвердили, но не значит что все с этим согласны так как читабельность вашего решения сильно уступает читабельности доступного из коробки гард/лет (если еще его правильно использовать а не всегда делать разворот когда это не нужно)

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

В смысле все является замыканием ? Может почитаете теорию и узнаете что замыкание это функция

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

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

Как я и предлагал ранее, давайте я вам напишу прокси, где количество проксируемых методов определено, а пробрасываемых нет, на обжективе, а вы мне код на свифте подобный. И сравним количество строк кода.

Ну да, все же программисты только и делают что пишут прокси, где количество проксируемых методов определено, а пробрасываемых нет. Сравнивать нужно на реальных проектах

Как я и описывал раньше, не энфорс селфа приводит к ошибкам

Почему-то у меня не приводит

и к тому, что такие пионеры, как вы, рьяно и резво дублируют вызовы к пропертям вместо кеширования в локальную переменную

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

т.к. не понимают, что проперти — это метод, а не поле.

Тут вы только подтверждаете свой непрофессионализм. Проперти это не метод. В свифте есть Stored property — сохраняют значение и Computed propety — значение не сохраняют, а просчитываются при доступе

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

Докажите обратное. Покажите код. Я показал код, т.к. мне не лень за 20 минут набросать варианты.

Оценил плюсы и минусы и сделал вывод что ее ефективнее использовать

Как вы можете оценить плюсы и минусы того, о чем не знаете?

В свифт не всегда обязательно делать разворот опшиналов при их использовании, все зависит от правильности проектирования архитектуры

Никакое проектирование вас не спасет от использования опшналов. Либо покажите пример, который доказывает ваше утверждение.

Это вы так решили что подтвердили, но не значит что все с этим согласны так как читабельность вашего решения сильно уступает читабельности доступного из коробки гард/лет (если еще его правильно использовать а не всегда делать разворот когда это не нужно)

Все — это типа товарища, который балгодарит в вашем посте? Так, если он поддерживает глупости, что пишутся вами, то я бы на вашем месте не искал в нем опоры.

Читаемость моего кода проблемна лишь для пионеров, типа вас, которые не знают, что такое map, flatMap и apply.

В смысле все является замыканием ? Может почитаете теорию и узнаете что замыкание это функция

Просто функция? Ну ок. В принципе, с учетом того, что вы не знаете, что такое проперти в свифте, я не удивлен. Но это к делу не относится. Вы просто не знаете одной из основных особеннойстей платформы, а я пока просто над вами позабавляюсь, т.к. вы все еще не понимаете, о чем я говорю, что намекает нам на то, что вы даже погуглить не догадались и узнать, в чем именно вы неправы.

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

Бойлерплейт, сравнивая с одним разворотом ифлетами/гардами в вашем стиле, минимален. Я так понимаю, контест на код вы не рискнете со мной делать. Жаль, я беще поржал и вас погнобил, увидев ваш «продакшн» код (уж извините, без кавычек писать не в силах).

Ну да, все же программисты только и делают что пишут прокси, где количество проксируемых методов определено, а пробрасываемых нет. Сравнивать нужно на реальных проектах

Так давайте сравним? Это очень частый кейс дял полноценной реализации композиции на более-менее высоком уровне. В продакшн проектах.

Почему-то у меня не приводит

Просто потому, что вы кода на свифте написали мало и никогла особо не вносили изменений в чужой код. Ну что ж взять с вас, дилетанта?

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

Докажете обратное? Вы свой код боитесь показать хуже огня, что как бы намекает.

Тут вы только подтверждаете свой непрофессионализм. Проперти это не метод. В свифте есть Stored property — сохраняют значение и Computed propety — значение не сохраняют, а просчитываются при доступе

Мама родная. Вы и этого не знаете. Это ужас. Я еще раз просто уточню, перед тем, как начать вас освистывать, вы не знаете, что проперти — это один или два метода в зависимости от того, ридонли оно или ридрайт? Т.е. вы дествительно думаете, что проперти — это прямой доступ к ivar? Ой-йеееееееее... Мрак.

Никакое проектирование вас не спасет от использования опшналов. Либо покажите пример, который доказывает ваше утверждение.

Например, в UILabel text опшинал, для его присваивания нет необходимости делать развертывание. Также использование операторов ? и ?? с опшиналами не требует их развертывания

Просто функция? Ну ок.

Не просто функция (раньше уже вам объяснял что это такое), но функция а не то что вы пишете «все в свифте является замыканием»

Бойлерплейт, сравнивая с одним разворотом ифлетами/гардами в вашем стиле, минимален.

Там еще много другого бойлерплейта, но и одних хидеров на каждый класс уже достаточно

Читаемость моего кода проблемна лишь для пионеров, типа вас, которые не знают, что такое map, flatMap и apply.

Да знаю, не переживайте, map и flatMap доступны из коробки в свифт

Как вы можете оценить плюсы и минусы того, о чем не знаете?
Докажете обратное?
Просто потому, что вы кода на свифте написали мало и никогла особо не вносили изменений в чужой код.

Тут вы как обычно включили режим экстрасенса и пишете какую-то выдуманную вами чушь

Мама родная. Вы и этого не знаете.

Да нет, это вы не знаете, если вы не понимаете что пишете я вам объясню — вы путаете обжектив со свифтом

слушай, ну хватит позорится, явно видно, что trimm тебя по профессионализму уделывает, тут не надо экстрасенсорных способностей, я просто оставлю это здесь www.eswick.com/2014/06/08/Inside-Swift

я просто оставлю это здесь www.eswick.com/2014/06/08/Inside-Swift

Групповые побои лежачего. Муа одобряе.

В данном случае мы обсуждали использование self в swift, в нем, в отличии от ojbc, нету разделения на property и ivar:
„If you have experience with Objective-C, you may know that it provides two ways to store values and references as part of a class instance. In addition to properties, you can use instance variables as a backing store for the values stored in a property.

Swift unifies these concepts into a single property declaration. A Swift property does not have a corresponding instance variable, and the backing store for a property is not accessed directly.”
developer.apple.com/...​_Language/Properties.html
Поэтому нету особого смысла кешировать в локальную переменную Stored property, можно это делать для Computed property если там какой-то затратный расчет
А в чем кстати заключается „позор” ?

В данном случае мы обсуждали использование self в swift, в нем, в отличии от ojbc, нету разделения на property и ivar:

dou.ua/...ign=reply-comment#1000811

Таки есть, дитятко. Только в свифте вы к бекинг стор получить доступ не можете так просто в сеттере.

Поэтому нету особого смысла кешировать в локальную переменную Stored property, можно это делать для Computed property если там какой-то затратный расчет

И вот опять лезет ваш непрофессионализм в полной мере. Сегодня оно сторед, завтра компьютед, послезавтра — лейзи, а после-послезавтра — опять сторед. Однако, пионерам, которые за свою жизнь кода почти не писали, это невдомек.

Сегодня оно сторед, завтра компьютед, послезавтра — лейзи, а после-послезавтра — опять сторед.

Что-то отклонились от темы. Что тут даст енфорс селфа ?

Что-то отклонились от темы. Что тут даст енфорс селфа ?

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

Так зачем заставлять использовать self ? И без того можно закешировать в локальную переменную

Так зачем заставлять использовать self ? И без того можно закешировать в локальную переменную

Ибо подобные вам пионеры иначе не закешируют. Ведь они считают считают проперти прямым доступом к бекинг стору.

Вы можете доказать мне, что self не нужен только продемонстрировав свой код, где вы кешируете проперти в локальные пременные без использования self. При этом, коммит должен быть с гит историей, а время коммита должно быть раньше начала нашего с вами обсуждения. У вас такого нет, ибо аматоры неспособны что-то учить сами и писать код просто дял себя. Более того, я понимаю, что код у вас каловый, посему вы его так отчаянно прячете и столь же отчаянно игнорируете мои предложения покодить и сравнить код и результат.

Ибо подобные вам пионеры иначе не закешируют. Ведь они считают считают проперти прямым доступом к бекинг стору.

Вы думаете что закешировав сторед проперти в локальную переменную то ускорите работу приложения :) ? Кешировать можно для улучшения читабельности кода а иначе это можно назвать бойлерплейтом

Вы можете доказать мне, что self не нужен только продемонстрировав свой код, где вы кешируете проперти в локальные пременные без использования self.

Вы действительно не понимаете как закешировать проперти без использования self ? Это так само только убрав оператор self. )

игнорируете мои предложения покодить и сравнить код и результат.

Писал уже что сравнивать нужно на реальных проектах

Писал уже что сравнивать нужно на реальных проектах

Я вам предложил задачу из реальных проектов. Вы убежали с криками, что это — не задача с реалнього проекта (что лишь подтверждает ваше аматорство). Ну оно и неудивительно. Еще больше позорится не хотите, дилетант.

Вы думаете что закешировав сторед проперти в локальную переменную то ускорите работу приложения :) ? Кешировать можно для улучшения читабельности кода а иначе это можно назвать бойлерплейтом

Т.е. вы действительно считаете, что практика кеширования в локальные переменные дял избежания дублирования пошла от читаемости, а свовсем не от того, что любой метод, включая проперти может статья тяжелвоесным и множественное его выполнение нежелательно? Читаемость — это лишь приятный бонус.

Вы действительно не понимаете как закешировать проперти без использования self ? Это так само только убрав оператор self. )

Я действительно хочу посмотреть ваше уродливый код на костылях.

Я вам предложил задачу из реальных проектов.

Я не говорю о задаче я говорю о реальном проекте (надеюсь вы понимаете разницу)

Т.е. вы действительно считаете, что практика кеширования в локальные переменные дял избежания дублирования пошла от читаемости

Уходите от темы, мы говорим о stored property в swift которые созданы для использования без кеширования в локальные переменные без потери производительности

Я не говорю о задаче я говорю о реальном проекте (надеюсь вы понимаете разницу)

Реальный проект складывается из задач. Например, в MVVM viewmodel идеально делать с помощью проксирования модели. Я могу и на реальном проекте посоревноваться. Выбираем используемый подход и вперед. Для практичности оценки, разделим код на два типа:
1. Проектный код, специфичный дял данного проекта;
2. Переиспользуемый код.

Проект предлагаю следующий:
Приложение на два скрина:
1. Табличное представление restcountries.eu следующих полей:
— название страны;
— название столицы;
— презентация всех языков страны по одному языку на страну.
По нажатию на любую из ячеек страны переходим на второй скрин.
2. Показывается страна на карте с пином, кинутым на локейшен страны, показываются кастомные комментарии с стране в табличной форме под картой. Комменты можно добавить или удалить. Для этого первой ячейкой табличного представления является UITextField.

Для честности оценки переиспользуемый код будем оценивать на гибкость и переиспользуемость, проектный на бойлерплейт и дублирование. Естессно, чтобы было по-честному, можно использовать только свой переиспользуемый код, либо писать его с нуля, никаких внешних зависимостей. С нетерпением жду ваших новых отмазок, почему вы не сможете этого сделать.

Уходите от темы, мы говорим о stored property в swift которые созданы для использования без кеширования в локальные переменные без потери производительности

Я не ухожу от темы, к сожалению, вы настолько ограничены в знаниях, что не понимаете, о чем вам говорит ваш оппонент. Как я и сказал ранее, вы действительно считаете, что кеширование в локальные переменные нужно дял проивзодительности. Это позор дял программиста хотя бы 3 месяцами опыта. Сколько у вас лет опыта?

Например, в UILabel text опшинал, для его присваивания нет необходимости делать развертывание. Также использование операторов ? и ?? с опшиналами не требует их развертывания

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

? и ?? — идите и читайте, как работает оно. Т.е. разворачивает оно также. Но дело в том, что это не спасает вас от разворачивания никоим образом.

Мы же с вами говорили об архитектуре, т.е. взаимодействии нескольких модулей, а скатились вы до отдельной сущности, которую еще и не вы спроектировали.

И самое главное — код в студию. Вашего проектирования без разворотов. Я знаю, как такое сделать, но мне крайне интересно, как это сделает безграмотный дилетант, типа вас.

Там еще много другого бойлерплейта, но и одних хидеров на каждый класс уже достаточно

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

А теперь, на закуску, вы мне напишете код, когторый жто доказывает? Я вам предложил классический пример с композицией на основе проксирования. Я пишу на обжективе, вы на свифте. И мы сравниваем количество бойлерплейта. Для разнообразия, не будем пользвоаться сторонними библиотеками и сравним потом код на основе переиспользуемости и лаконичности. Или ребеночку слабо тягаться со взрослыми дядями? Только и хватает гонору хныкать в углу «явамниверювывсеврети».

Можем даже огранизовать такой баттл в публичном пространстве, например, в каком-нить коворкинге или в моем офисе. Как реффери пригласим кого-нить из членов нашего сообщества. Заодно похвастаюсь своим старым добрым «макбуком» (кавычки — это не ошибка).

Да знаю, не переживайте, map и flatMap доступны из коробки в свифт

Я и не переживаю. Вы этого не знаете и не понимаете. И очень удобно выпустили аппликатив. На это указывает то, что вы говорите, что в свифт это есть из коробки. Из коробки там кастраты дял нескольких сущностей, в которых нет ни pure, ни lift, ни стрелок, ни композиции.

Тут вы как обычно включили режим экстрасенса и пишете какую-то выдуманную вами чушь

Мне не надо быть экстрасенсом. Мы на настолько разном уровне понимания, что я вижу это из ваших тезисов и безграмотности, т.к. такие тезисы исходят только из мизерного опыта и нежелания развиваться.

Не просто функция (раньше уже вам объяснял что это такое), но функция а не то что вы пишете «все в свифте является замыканием»
Да нет, это вы не знаете, если вы не понимаете что пишете я вам объясню — вы путаете обжектив со свифтом

Бгг... Ну ок. Сами напросились.
Надеюсь, что вы хотя бы знаете о том, что функции в свифте могут быть высшего порядка, т.е. возвращать функции и принимать функции, как параметры. Также, они могут являться замыканиями, т.е. захватывать внешний скоуп.

Теперь давайте просто посмотрим на AST swift (2.3), который я сгенерил ниже.
gist.github.com/...bb0984cd2de9df454dd86e5f7

Посмотрим сначала на обычную stored property, которую вы, в виду своего непрофессионализма, считаете доступом к ivar. Я молчу о том, что сам apple в своей доке писал: «A Swift property does not have a corresponding instance variable, and the backing store for a property is not accessed directly.» ( developer.apple.com/..._Language/Properties.html ) Что уже могло бы дать толчок сообразительному и любознателньому юноше, которым вы не являетесь, что что-то тут нечисто. Ведь apple прямо говорит, что property и его backing store — это разные вещи.

Так вот, если мы взглянем на проперти в AST, то увидим следующее, что это — не более, чем метод, принимающий self и устанавлиюващий/возвращающий значение из бекинг стора. Специально для самоуверенных безграмотных пионеров, типа вас, я сделал перевод этого AST в формат swift, который даже вы, несмотря на свою безграмотность, сможете понять.

gist.github.com/...69dea8e3e44c0efde8009c016

Как вы и сами видите, проперти является методами, как я и говорил ранее.

Более того, как я и говорил ранее, и методы, и проперти являются замыканиями, о чем свидетельствует сигнатура сгенерированных методов. При вызове любого метода у сущности вы на самом — то деле обращаетесь не к методу, показанному в AST, а к методу, полученному путем вызова метода из аста с параметром селф. Т.е., вызывая метод свифтовой сущности вы обращаетесь к замыканию, которое произвело захват self. Что и видно из вызова globalFunction.

Более опытные товарищи, конечно, могли бы поспорить с моим выбором именно структуры для примера, т.к. они зачастую вообще через регистры передаются. Да и на самом-то деле проперти в результате оптимизации могут и напрямую в ивар полезть, однако, это уже оптимизации и сие не имеет отношения к языку и его идеологии. А идеология свифта — это то, что любой метод — это замыкание, а проперти — это тоже метод.

Заворачивайтесь в простыню и пользите в сторону кладбища, ленивый непрофессионал.

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

Не важно где реализовано, программистам как клиентам класса UILabel не нужно разворачивать текст перед присваиванием. Но со стороны реализации UILabel разворачивать прийдется (я не говорил что разворачивать вообще не прийдется) и в этом и есть плюс так как компилятор подскажет что переменная может не иметь значения — заставляет программиста писать обработку данной ситуации вместо возможного вылета/неправильной работы

Посмотрим сначала на обычную stored property, которую вы, в виду своего непрофессионализма, считаете доступом к ivar.

Вот результат вашых неверных догадок, я так не считаю, выше уже написал про это, но нужно уточнить про private stored property это возможно прямой доступ к бекинг стору. Называть проперти в свифте методом не правильно — так как это низкоуровневая реализация (скорее всего с оптимизацией) доступа к бекинг стору на уровне языка. В методах же свифта мы не можем иметь доступ к бекинг стору в отличии проперти

в этом и есть плюс так как компилятор подскажет что переменная может не иметь значения — заставляет программиста писать обработку данной ситуации вместо возможного вылета/неправильной работы

Так тогда и обжектив точно такой же. Передали ноль, а оно не упало. Все норм.

Только вот это никак не отвечает на мой вопрос о правильной архитектуре.

Вот результат вашых неверных догадок, я так не считаю, выше уже написал про это, но нужно уточнить про private stored property это возможно прямой доступ к бекинг стору.

Вы это написали вот здесь:

Тут вы только подтверждаете свой непрофессионализм. Проперти это не метод. В свифте есть Stored property — сохраняют значение и Computed propety — значение не сохраняют, а просчитываются при доступе

В то же время, как я любезно успел вам доказать, проперти — это метод.

Называть проперти в свифте методом не правильно — так как это низкоуровневая реализация (скорее всего с оптимизацией) доступа к бекинг стору на уровне языка.

Это шедевр. Вы — безграмотный дилетант, уже спорите с выхлопом яблочного компилера, который по вашим утверждениям поступает неправильно? Я вас уже ткнул носом в то, как компилер воспринимает проперти на уровне аста. Можете глянуть и на уровне SIL, если вы хотя бы знаете, что это такое.

И если компилер создает под это метод, то это таки метод.

В методах же свифта мы не можем иметь доступ к бекинг стору в отличии проперти

Т.е. что такое inout, unsafe вы тоже не знаете. Позор. Мне интересно, насколько долго вы еще сможете демонстрировать границы своего невежества.

Так тогда и обжектив точно такой же. Передали ноль, а оно не упало. Все норм.

Нет, попробуйте в нем добавить nil элемент в массив — упадет. Но суть не только в том чтобы приложение не падало а также чтобы компилятор подсказал что нужно обработать ситуации nil значений чтобы на этапе выполнения не было ошибок

В то же время, как я любезно успел вам доказать, проперти — это метод.

Нужно разделять метод и проперти — так как оно используется только для доступа к бекинг стору, тогда как методы в большинстве случаев не имеют прямой доступ к нему

Т.е. что такое inout, unsafe вы тоже не знаете.

Вы вижу тоже. Надеюсь вы не предлагаете передавать проперти в метод через inout. Unsafe pointer тоже не очень идея использовать просто чтобы получить доступ к бекинг. Но лучше уточнить — «В методах же свифта мы не всегда можем иметь доступ к бекинг стору в отличии проперти»

Нет, попробуйте в нем добавить nil элемент в массив — упадет.

Как я уже ранее писал, у меня уже лет так 8 есть категории на коллекции, которые нолебезопасны. Т.е. мое решение возносит обжектив по вашим же словам в ранг свифта.

Но, на самом деле, вопрос дата-сета здесь важен, а ноль или не ноль. Ноль — часть датасета обжектива, но тип в свифте. С тем же успехом можно аппелировать к тому, что в Swift есть out of bounds exception, которые компилер не проверяет, т.к. это — часть датасета.

Нужно разделять метод и проперти — так как оно используется только для доступа к бекинг стору, тогда как методы в большинстве случаев не имеют прямой доступ к нему

Кому нужно разделять? ЗАчем нужно разделять? Почему компилятор swift не разделяет? Эппл неправы и их компилер, а правы вы, непрофессионал?

Проперти используются толкьо дял доступа к бекинг стора? Т.е. лейзи, компьютед, обзервабл проперти вы за проперти не считаете?

Вы вижу тоже.

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

Надеюсь вы не предлагаете передавать проперти в метод через inout. Unsafe pointer тоже не очень идея использовать просто чтобы получить доступ к бекинг.

Я ничего не предлагаю, мне не интересно вас обучать, мне интересно только вас обоснованно унижать и растить свое ЧСВ. Я опроверг очередное ваше безграмотное утверждение, которое цитирую ниже:

В методах же свифта мы не можем иметь доступ к бекинг стору в отличии проперти
Но лучше уточнить — «В методах же свифта мы не всегда можем иметь доступ к бекинг стору в отличии проперти»

Мы всегда может это сделать в любом методе, который имеет доступ к проперти (т.е. кому vsivibility разрешает это делать). Так вот, само ваша попытка разделения методов и проперти абсурдна. Т.к. компилятор, что я вам уже доказал раньше, генерирует сеттер и геттер методы, когда вы объявляете проперти.

Соответственно, мой забавный, но бесполезный собеседник-дилетант, от вас я бы с удовольствием таки хотел услышать, что именно вы хотите оспорить? Что то, что делает яблочный компилер? Я также хочу уточнить, вы, я так понимаю, даже не сходили по линкам на аст, которые я кидал выше, посему и продолжаете расписываться в своем незнании базовых вещей?

З.Ы. Ваше «явамниверювывсеврети» искренне доставляет. Никогда бы не подумал, что в нашей сфере такие глупые люди, как вы, что вместо изучения аргументов оппонента и ликвидации своего незнания, продолжают настаивать на том, что объективно не является правдой и что было доказано оппонентом путем неоспоримых пруфов (а AST и SIL, сгенеренный swiftc — неоспоримый пруф, т.к. компилер получше вас понимает, как именно ему надо воспринимать разные statement языка).

Как я уже ранее писал, у меня уже лет так 8 есть категории на коллекции, которые нолебезопасны. Т.е. мое решение возносит обжектив по вашим же словам в ранг свифта.

Нет, суть optional не только чтобы приложение «не падало», выше уже писал. Но проверка компилятором намного безопасней кастомных решений

Кому нужно разделять? ЗАчем нужно разделять? Почему компилятор swift не разделяет? Эппл неправы и их компилер, а правы вы, непрофессионал?

Да Эппл как раз правы — они не называют проперти методом

Т.е. лейзи, компьютед, обзервабл проперти вы за проперти не считаете?

А при чем тут это если мы говорим о stored property ? Это совсем разные понятия

Мы всегда может это сделать в любом методе, который имеет доступ к проперти

Так мы же доступаемся через stored property — а это не прямой доступ к бекинг (по-моему если не private stored property).

Нет, суть optional не только чтобы приложение «не падало», выше уже писал. Но проверка компилятором намного безопасней кастомных решений

Проверки компилятором не спасает ни от чего, кроме ошибок типов. Большинство ошибок связаны, как раз, не с ошибками типов. Т.е., компилятор вас, в оснеовном, ни от чего не спасает. Самое ужасное — это то, что вы даже не понимаете разницы между типом и датасетом. Вы создаете впечатление глухого, который просто игнорирует все, что не знает (т.е. почти все, что было мною написано).

Да Эппл как раз правы — они не называют проперти методом

Орли?
gist.github.com/...bb0984cd2de9df454dd86e5f7
gist.github.com/...69dea8e3e44c0efde8009c016

Я так понимаю, что этот код, сгенеренный яблочным компилером из свифтового кода — это не называние проперти методом? Я понимаю, что вы, в силу своей безграмотности и лени, так и не заглянули в эти линки, чтобы не портить свою стройную ватненькую картину мира? Вы — уникум (в плохом смысле этого слова), ИТ-ватник.

А при чем тут это если мы говорим о stored property ? Это совсем разные понятия

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

Так мы же доступаемся через stored property — а это не прямой доступ к бекинг (по-моему если не private stored property).

Честно? Млин, это гениальное по своей глупости утверждение. Unsafe и inout по-вашему идут через property? Что еще расскажете? А ансейф и инаут, как я и утверждал ранее, дают вам прямой доступ к бекинг стору.

Т.е., компилятор вас, в оснеовном, ни от чего не спасает.

Ну от всех ошибок конечно не спасет, но по сравнению с другими языками предотвращает больше ошибок

Я так понимаю, что этот код, сгенеренный яблочным компилером из свифтового кода — это не называние проперти методом?

Я говорю про документацию Эппл

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

Но разница между computed и stored property очень большая, поэтому их нужно разделять

Unsafe и inout по-вашему идут через property?

Выше уже уточнил «В методах же свифта мы НЕ всегда можем иметь доступ к бекинг стору в отличии проперти»
Unsafe и inout используется очень редко

Ну от всех ошибок конечно не спасет, но по сравнению с другими языками предотвращает больше ошибок

Спасает только от ошибок типов. Optional-подобные boxы делают и в других языках, поднимая датасет до типа. Однако, это не спасает от большего количества ошибок даже в статически типизрованных языках. Ну точнее, пионеров, типа вас, может и спасает, которые даже динамических языков бояцца, т.к. пишут отвратительный код. А для грамотных специалистов спасения нет, т.к. единственные ошибки исходят из датасетов, а не системы типов. О чем я и говорил ранее.

Я говорю про документацию Эппл

Дока эппл написана для пионеров, которым не интересно, как работает. Я говорю о фактической реализации. Т.к. компилер и восприятие компилера всегда имеет примат над докой, т.к. именно компилер воспринимает правилньо язык, то можете ныть, сколько влезет, дилетант, но проперти — методы.

Но разница между computed и stored property очень большая, поэтому их нужно разделять

Между ними разницы нет. Что то — метод, что это. То, что вы даже таких простых вещей не понимаете — еще одлин минус в копилку вашего отсутствующего багажа знаний.

То, что вы считаете методы, которые лезут в ивар через указатель (сторед, обзервед) и методы, которые лезут в ивар через метод, который лезет через указатель (компьютед) очень сильно различными — это гениально. Никогда не думал, что лично буду общаться с человеком с настолько отсутствующим абстрактным мышлением, т.к. толкьо этим можно объяснить то, что вы не можете сгруппировать одинаковые методы, если в одном из их типов представлена небольшая indirection.

Unsafe и inout используется очень редко

Только пионерами, типа вас, дял которых дублирование — второе имя. Да и тем же inout пользуетесь вы постоянно, просто, в силу безграмотности, отсутствия понимания и знания свифта, вы даже не знаете, что используете inout и в какие моменты.

Между ними разницы нет.

Вот это точно шедевр. Нету разницы между computed и stored property ? Лол. Stored property позволяет сохранить значение, а computed — нет. Если в computed property происходит сложный расчет это повлияет на производительность при доступе к ней, тут может пригодиться кеширование в локальные переменные в отличии от stored property

Только пионерами, типа вас, дял которых дублирование — второе имя. Да и тем же inout пользуетесь вы постоянно,

Снова уходите от темы, я вам показал отличие stored проперти от обычного метода — «В методах же свифта мы НЕ всегда можем иметь доступ к бекинг стору в отличии проперти»

Вот это точно шедевр. Нету разницы между computed и stored property ? Лол. Stored property позволяет сохранить значение, а computed — нет. Если в computed property происходит сложный расчет это повлияет на производительность при доступе к ней, тут может пригодиться кеширование в локальные переменные в отличии от stored property

Как было сказано ранее, механзимы проперти отличаются частностями. Компилеру пофик, дял него все это — методы. Пруф:
gist.github.com/...d74fdb339bc04aa8ea95440ac
gist.github.com/...90112e2c744da2c95106ea182
gist.github.com/...e6ed30c31f4beb4aa84b6c57d

Из AST выше видно, что все проперти имеют одинаковый механизм. Все они являются геттером и сеттером. Переход с одного типа на другой не вызовет нигде ворнинга, т.к. синтаксический конструкт один и тот же и компилер воспринимает их все одинаково.

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

Снова уходите от темы, я вам показал отличие stored проперти от обычного метода — «В методах же свифта мы НЕ всегда можем иметь доступ к бекинг стору в отличии проперти»

Я не охтожу от темы, просто у вас не хватает опыта и знаний, чтобы понимать, о чем говорит ваш собеседник. Как я только что доказал, между типами проперти нет разницы. Так вот, в проперти вы также не всегда имеете доступ к бекинг стору. Разницы нет на уровне копилятора. К сожалению, у вас не хватает компетенции, чтобы это осознать.

Как было сказано ранее, механзимы проперти отличаются частностями.

Частностями ? Между сторед и компьютед проперти кардинальные отличия, это в первую очередь должны знать разработчики на свифт, так как это может повлиять на производительность приложения. Есть сложное вычисление, лучше его сделать один раз и результат записать в сторед проперти или каждый раз заново просчитывать при доступе к компьютер проперти (вы же говорите разницы между ними нету) ?

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

Об отсутствии профессионализма в свифте тут говорят только ваши высказывания. Не смешите, вы предлагаете кешировать все сторед проперти только из за того что в будущем (вероятность очень маленькая) возможно вы переделаете их в компьютед ? Это называется бойлерплейт. И когда я меняю тип проперти на компьютед я понимаю что между ними есть разница в отличии от вас.

Так вот, в проперти вы также не всегда имеете доступ к бекинг стору.

В сторед проперти ?

Разницы нет на уровне копилятора.

Не выкручивайтесь, нас интересует разница в реальности (которая очень большая) для того чтобы писать эффективный код

Частностями ?

Именно. Механизм один и тот же. АСТ выше по треду это убедителньо доказал.

Есть сложное вычисление, лучше его сделать один раз и результат записать в сторед проперти или каждый раз заново просчитывать при доступе к компьютер проперти (вы же говорите разницы между ними нету) ?

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

Поразительно, насколько вы безграмотны и бесполезны, что не понимаете, что хранение или вычисление — это частность. Та же хранимая проперти может стать обзервабл и иметь в себе при доступе тоже длительные вычисления.

Об отсутствии профессионализма в свифте тут говорят только ваши высказывания.

Мне это говорит человек, пишущий следующее:

Не смешите, вы предлагаете кешировать все сторед проперти только из за того что в будущем (вероятность очень маленькая) возможно вы переделаете их в компьютед ?

Я их и в обзервабл могу переделать. А то, что вы говорите о вероятности, лишь в очередной раз выдает то, что вы — постыдный аматор, забредший в айти случайно.

Да и в комьютед их переделывать не обязательно, чтобы усложнить вычислительно доступ.

Это называется бойлерплейт.

Давайте мне пруф бойлерплейта в вашем подходе. Задача — настроить каждое из полей navigationItem у UIViewController в методе designated init. А я с вас потом посмеюсь. Или будете лепить опять отмазки, т.к. неспособны написать 2 строчки кода?

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

Ну вот, предположим, вы сменили тип проперти, так уж вышло. Что вы будете делать со всем своим кодом, дилетант? Будете панически искать, где же вы проперти использовали и его кешировать в локальную переменную? У вас сколько дней опыта, вообще, джуник?

В сторед проперти ?

Как я убедительно доказал выше с помощью AST. Проперти не имеет смысла разделять на типы, т.к. механизм одинаков. Именно поэтому проперти не всегда имеют доступ к бекинг стору. Я просто поражаюсь тому, что вы даже банальные концепции компилера не потрудились осилить, перед тем, как лезть в спор с умными дядями.

Не выкручивайтесь, нас интересует разница в реальности (которая очень большая) для того чтобы писать эффективный код

Мне не имеет смысла выкручиваться. За меня все сказал компилятор. То, что у вас не хватает моска и опыта, чтобы понять, что вам говорит ваш более грамотный и опытный оппонент — не моя проблема.

А чтобы писать эффективный код, надо уметь хотя бы две вещи:
— анализировать задачу, с чем вы с треском не справились, исходя из вашего же утверждения о том, что всегда сложное вычисление надо кешировать в сторед проперти;
— делать код гибким к изменениям, с чем вы также не справились, т.к. даже не можете себе представить ситуации, что тип проперти может сменится, посему утверждаете, что локальное кеширование проперти не имеет смысла.

Ваш код опирается на то что у User может быть только конструктор с 3-мя параметрами (Int, String, String?).
Если допустим у класса сущности будет несколько конструкторов, да и еще и с 3-мя параметрами разных типов — ваш код просто не будет компилироваться, так как надо будет создать еще методы `curry` для 1, 2 и т д параметров.

Пример:

pastebin.com/Ysg7qaMb

Вариант с Codable (если это json) / guard / if-let выглядит все-таки жизнеспосбнее.

UPD. Хотя стоп, если заменить

static let create = curry(User.init)

на

static let create = curry(User.init(id:name:email:))

то все нормально компилится.

Если допустим у класса сущности будет несколько конструкторов, да и еще и с 3-мя параметрами разных типов — ваш код просто не будет компилироваться, так как надо будет создать еще методы `curry` для 1, 2 и т д параметров.

Ну для знатоков свифта неудивительно не знать о том, как выбрать одну из функций с одинаковым именем и разными параметрами:
pastebin.com/SdbTiMFm

Да. Curry надо создать. Для этого легко использовать gyb. Хоть знаете, что это такое? Точно так же и сами свифтовцы создают с помощью gyb кучу операторов github.com/...​blic/core/Tuple.swift.gyb

Макросы-то в свифт не завезли. А кодогенерация sourcery для данного случая не подходит от слова ’аще’.

Вариант с Codable (если это json) / guard / if-let выглядит жизнеспосбнее.

Для начинающих разработчиков — да. Более опытным, обычно, впадлу писать бойлерплейт ради бойлерплейта. ну это кроме того, что это — единственный способ в свифте писать безопасный код, не превращая его в жабу.

Кстати, у вас там еще в коде json values это AnyObject, хотя на самом деле значения в словаре имеют типы Int, String — это структуры, не классы, т. е. Any.

Почитал ваши комменты. Видно, что вы спец в ObjC. Конструктивно/аргументированно пытаетесь доказать, что Swift — гуано и не должон бы выстрелить. Но.....

Помнится когда Microsoft «изобрело» C# подобная критика была в сторону сего языка. Мол не выстрелит. Выстрелило. И мощно. Независимо от инженерных изьяов (кои вероятно там были и много).

Подобное будет и со Swift -ом. Только ,лично мое мнение, выстрелит он еще сильнее. Судя по вашему энтузиазму в вопросе доказать обратное (аругментированно) , вы и сами «чувствуете как крадется» закат славного (?) ObjC.

Кстати, наверное подобные вам жестко критиковали в свое время выход ARC. и ведь были не правы.

Почитал ваши комменты. Видно, что вы спец в ObjC. Конструктивно/аргументированно пытаетесь доказать, что Swift — гуано и не должон бы выстрелить. Но.....

Орли? Я пытаюсь доказать, что swift — гуано? Я указываю на существенные недостатки языка в парадигме, в которой swift отличен. Мне он нравится для своих проектов. Я скачу между обжективом и свифтом, как конь на конкуре. Но мои проекты не требуют поддержки, я ими развлекаюсь. А брать реальныйц проект и делать его на свифте, если заказчик не готов к тому, что каждый релиз свифта надо будет чинить код и частично рефакторить — это мазохизм.

Кстати в мои замечания еще надо докинуть минусом ограниченный чарактер сет операторов свифта. Вообще абсудр — не иметь возможность выразить на языке, созданном для выразительности, нужное вам.

Судя по вашему энтузиазму в вопросе доказать обратное (аругментированно) , вы и сами «чувствуете как крадется» закат славного (?) ObjC.

Да мне разницы нет, как бы. Еще один язык. Хотелось, чтобы он был более функциональным, но эппл решила пожалеть бедных хомяков, которые бы его тогда никогда не освоили. Да хотелось бы, чтобы компилер поумнел, а то неработающий type inference в языке, где type inference служит дял того, чтобы убрать бойлерплейт — это идидотизм.

Кстати, наверное подобные вам жестко критиковали в свое время выход ARC. и ведь были не правы.

Подобные мне профи, которые не ощущают маркетологический оргазм от wwdc, а подходят с позиции целесообразности, посему начали осуществлять переход на ARC не как early adopter, а когда был уже в этом смысл (т.е. когда опенсорс перешел на ARC)? Ну да. Все равно MRC знать надо даже сейчас. И до сих пор я критикую ARC, т.к. он не анаклизирует AST, а следует конвенциям, в результате чего пионеры с завидным упорством делают то ритейн лупы на ARC, то за счет неправилнього именования падают от overrelease.

Просто залишу цитату з вашого кометнтаря:

Кроме того, что свифт — фекалия, его подходы сложны для новичков. А стандартную библиотеку, подходы к проектированию, лексическую составляющую кода, по сути, без разницы, на чем учить.
Ну а то, что в нем нет сообщений и самых базовых вещей (KVO, KVC), которые делают ObjC столь годным языком, как бы намекает нам на мертворожденность этого поделия.
Просто залишу цитату з вашого кометнтаря:

Еще более раннюю цитату не могли привести? К нему масса претензий, который я озвучил тут: dou.ua/...aign=reply-comment#984414

И да, я все еще считаю, что языки без сообщений мертворожденные. Свифт спасает в этом плане бриджинг с ObjC, а потому выходит лучшее из двух миров: И объектный ObjC и недофункциональный Swift.

Туда же еще докину, следующие замечания:
— нет возможности частичной спецификации generic через typealias;
— custom operators ограничены по character set;
— и еще раз подчеркну, что компилер туповат, т.к. видеть подобные сообщения от компилера — верх абсурда: «Expression was too complex to be solved in reasonable time».

По делу на замечания из коммента вверху и в этом комменте есть, что ответить? Или максимум, на что вы способны — искать в нерелевантных топику комментов собеседника?

ну я бы запихнул треугольник в клас и потом только давал команду triangle1.drawYourself(). а как там внутри класа он рисуется и красится можна через две недели забыть.

Можете меня поправить, но по моему, данный пример не имеет никакого отношения к синтаксису и удобству ЯП (С# и Swift).

Речь идет о удобстве использования прикладный библиотек (.Net и «че там под маком...»).

Да — все верно. Сам по себе язык мне нравится, то прикладные библиотеки оставляют желать лучшего...

Вот вам нормальный метод — CGContextSetFillColor(). И не благодарите.
Я молчу насчет того, что это к Swift вообще никак не относится.

А насчет всего остально и возмущений с сторону векторной графики — её нужно уметь готовить. Корни всего этого добра надежно лежат в сишном API CoreGraphics c углублением в Quartz.

На CoreGraphics посмотрю чуток позже — возможно не все так и плохо. Хотя UIBezierPath просто wrapper над core graphic.

Еще и виндовый GDI+ весьма на CoreGraphics смахивает

Я вам больше скажу — у обоих ноги растут из древнейшей С-шной либы под Х-ы, где было moveto и lineto.
Пример на шарпе до боли напомнил WinApi 3.0 с ее первым GDI на чистом с, на свифте логично бриджится в CoreGraphics, который в свою очередь в С-шную либу NextStep-а, которая растет из той самой под Х-ы.

учите С++, там можно рисовать прекрасные треугольники:
for(int i=1;i<10;i++) { for(int j=1;j<=i;j++) printf("*"); printf("\n"); }

А что тут, собственно, «плюсового»? По-моему тут C99 в чистом виде.

Я бы даже сказал что K&R 1973 тоже подойдет. ))

UIColor.redColor().setFill()
Всё хорошо, яблоку можно.

Но если у кого-то из нас в тестовом задании или на гитхабе обнаружат такой подход (я не об этой инструкции) — то не перезвонят.

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

Это пример — я могу найти и другие примеры. Да — это не типичная задача, просто использована в качестве примера.

Приведите еще пример, пожалуйста.


enum Error1: ErrorType {
case Error1_1
case Error1_2
}

enum Error2: ErrorType {
case Error2_1
case Error2_2
}

func throwError1() throws -> NSString {
throw Error1.Error1_1

return NSString()
}

func throwError2() throws -> NSString {
throw Error2.Error2_1

return NSString()
}

И сама обработка ошибок


do {
_ = try! throwError1()
_ = try! throwError2()
}
catch Error1.Error1_1 {
}
catch Error1.Error1_2 {
}
catch Error2.Error2_1 {
}
catch Error2.Error2_2 {
}

Какая разница с C#? Можт я не настолько хорошо знаю этот язык, чтобы понимать, чем там лучше/проще.

Набросал вам простейший пример по флоу, как можно было бы сделать по-другому: gist.github.com/...28c4260a19fe5eeb9f97d681f

Есть только трабла, type inference swift имеет такие жесткие ограничения и настолько тормознут пока, что грусть берет. Когда компилер поумнеет, оно будет преобразовано в gist.github.com/...ddea4c9052460d7b85c0d5fa4

Для вашего же случая, можно вот так, если не делать result: gist.github.com/...c7615ef0df76b644a86967850

Но я по-прежнему не понимаю, чем в шарпе лучше, если честно.

Или вот так для случая, когда функции могут кидать только определенный тип исклчюения:
gist.github.com/...86d5cb68005ac4d5397153748

Дело не в треугольнике — он взят как пример.

Да, если рисовать кастом UI ручкой, не тащить картинки на каждый чих под кучу разрешений.

Спасибо) Век живи — век учись))

Та нзш. Вы ж тоже самое через цссы разные делаете.

У нас леняцца многие, но размер приложения в 10 метров таки мотивирует заморачиваться.

А до чого тут Swift? UIColor та UIBezierPath — це класи фреймворку UIKit. На Objective-C їх теж можна використовувати.

Причому навіть UIKit не є їх джерелом. Код має виглядати так:

let trianglePath = UIBezierPath()
trianglePath.moveToPoint(CGPoint(x: 5.0, y: 95.0))
trianglePath.addLineToPoint(CGPoint(x: 50.0, y: 12.5))
trianglePath.addLineToPoint(CGPoint(x: 95.0, y: 95.0))
trianglePath.closePath()
trianglePath.fill()

Колір є частиною graphics context, разом зі stroke, transformation matrix і ще деякими штуками. Історично це окремі «об’єкти». Swift лише дає прозорі bindings на модель, яка до Swift’а не має ніякого відношення.

1.0 0.0 0.0 setrgbcolor
5.0 95.0 moveto
50.0 12.5 lineto
95.0 95.0 lineto
closepath fill

en.wikipedia.org/wiki/Display_PostScript

Код на C# теж не має відношення до C#, це просто інша графічна модель.
Умовно GPU/DirectX/modern-OpenGL. Звідки ідуть points collection як базова структура даних.
Якщо у Swift’а є можливість малювати 2D через 3D інтерфейси, код має вийти дуже схожим на C#.

Хз тільки чому воно Bezier path, а не просто path.

Попробуй нарисовать треугольник в OpenGL или Vulkan.

В Директ3Д версии эдак 3 все было веселее)

А че там, уже нет нужды писать 100 строчек кода чтобы инициализировать ком объект ?

С хелперами от МС все давно проще. А вот заполнять ручками буфер, который скармливается потом видяхе было весело. DrawPrimitive появился только в 5.

Если это все, что раздрадает Вас в этом языке, то, очевидно Вы нашли свой язык програмирования)

Видимо «порыдать» проще чем зарефрешить понимание :)))

Отличная идея — собрать под этим постом все, что нас раздражает в этой жизни.

Меня в последнее время инкапсуляция оч раздражает.

а от полиморфизма АЖ ТРИСЕТ!

Подписаться на комментарии