Но можно было сделать одно и то же

JSON, XML...

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

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

Ну это зависит от требований. Например мы имеет классы языках программирования. У них объектов есть имя класса и множество параметров. Ветвь - это имя класса, множество параметров это параметры листа. Для описания объекта из ЯП xml подходит хорошо. Если использовать JSON то придется городить условности, типа "а давайте хранить имя класса в поле className, а проперти в классах с именем className запретим"

Ну это зависит от требований. Например мы имеет классы языках программирования. У них объектов есть имя класса и множество параметров. Ветвь - это имя класса, множество параметров это параметры листа. Для описания объекта из ЯП xml подходит хорошо. Если использовать JSON то придется городить условности, типа "а давайте хранить имя класса в поле className, а проперти в классах с именем className запретим"

но можно же?

Ну это зависит от требований. Например мы имеет классы языках программирования. У них объектов есть имя класса и множество параметров. Ветвь - это имя класса, множество параметров это параметры листа. Для описания объекта из ЯП xml подходит хорошо. Если использовать JSON то придется городить условности, типа "а давайте хранить имя класса в поле className, а проперти в классах с именем className запретим"

т.е. XML выгоднее тем, что можно 2 атрибута с одинаковым именем хранить?

Ну технически можно.

ну и зачем оно мне?

ну и зачем оно мне?

Чтобы не было как раз условностей.

Чтобы не было как раз условностей.

зато путаница будет

Путаница будет как раз при условностях.

Давайте пример.

Тише тише Виталий) Отвечу)

Путаница будет как раз при условностях.

зачем мне 2 проперти class к примеру? для чего? Только путать буду лишний раз человека

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

В том что в xml обязывает давать названия ветвям и листьям (узлам)

вот мне кажется в json например структуру типичного экрана в iOS описать будет проще

Не понял вопроса.

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

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

ну и что тут такого то?

Работать пойдем сегодня?

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

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

А это потому что у XML нет такого понятия в спецификации как массив вообще

И все еще от парсера зависит

ну и что тут такого то?

В том что вам нужно завести условность "а давайте мы детей будет хранить в поле children" и постоянно везде писать это children.

я прекрасно представляю UIView в виде JSON, с полем subViews, а UIView в виде XML где все сабвьюхи будут внутри скобочек не очень представляю

Насчет верстки в XML. У нас есть некоторые приложения, верстка которых сделана в XML. И есть такой файлик, который называется project.xml

И вот в ряде случаев он занимает 10-15к строк xml

И редактировать это руками это пиздец

А это потому что у XML нет такого понятия в спецификации как массив вообще

Дети и так обычно рассматриваются как массив. Если у вас не кастомный интерпретатор конечно.

Дети и так обычно рассматриваются как массив. Если у вас не кастомный интерпретатор конечно.

Ну т.е. с одной стороны мы педантично ковыряем json, а тут "обычно рассматривается"?

Ради бога, ты можешь придумывать сколько угодно спецификаций. Но зачем, когда есть xml который делает все это из коробки: добавляет детей без боли, имеет имя узла. Имя узла особенно важно для ООП, потому что почти всегда объекты имеют класс.

А причем тут ооп вообще?

Ну т.е. с одной стороны мы педантично ковыряем json, а тут "обычно рассматривается"?

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

Ради бога, ты можешь придумывать сколько угодно спецификаций. Но зачем, когда есть xml который делает все это из коробки: добавляет детей без боли, имеет имя узла. Имя узла особенно важно для ООП, потому что почти всегда объекты имеют класс.

какая же это боль то, обратиться к полю?

Я не понимаю что происходит. XML 1) избыточен 2) сложнее парсится (время на парсинг) 3) сложнее редактируется 4) Если есть схема то вообще пиздец

Опиши на JSON коллекцию из строк, которая не может иметь скажем больше 3 строк и содержит в данный момент 2 строки. Вот как бы выглядело это на xml: <collection maxItems="3"> <str>qwe</str> <str>qwe</str> </collection>

ЧТобы описать это на JSON вам потребуется большее количество узлов.

Я не понимаю что происходит. XML 1) избыточен 2) сложнее парсится (время на парсинг) 3) сложнее редактируется 4) Если есть схема то вообще пиздец

Если XML избыточен - используйте менее избыточные нотации - xml, json. Но для описания View иерархий XML не избыточен, а JSON и YAML "недостаточно многословные", хз как это сказать по русски. Короче противовположность избыточности. Когда вы говорите об избыточности, вы говорите для чего, потому что абстрактно язык не может быть избыточным.

Если xml избыточен, используйте xml

Кек

Да

Если есть опыт настройки пушей с firebase - отпиши пожалуйста. серт никак не толкается в firebase

Я ж говорю, это все красиво, но у меня есть project.xml в 15к строк

И когда туда надо добавить одно поле — это пиздец

Если xml избыточен, используйте xml

Ну просто есть же разные структуры данных, разные деревья. Если у вас нет имен узлов, используйте json. Если есть имена узлов то xml.

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

Это наверное сложно понять.

А у тебя строки каких классов. Ты куда str проебал?

Ты классы то добавь, не читери. Представь что там Cat Dog а не строки.

какой-то бред имхо. наркоманы

классы str. str имя класса пусть будет, давай, пихай str куда-нибудь

типа className="str"

А у тебя maxItems к потолку прибито? Как понять что это относится к collection?

Так это атрибуты, не?

Оба вы правы. Для описания дерева UI удобнее юзать XML, но читать его хреново

Так это атрибуты, не?

+

А у тебя maxItems к потолку прибито? Как понять что это относится к collection?

maxItems это из какого парсера?

классы str. str имя класса пусть будет, давай, пихай str куда-нибудь

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

Хотя я согласен с тем, что андроидская верстка неплохо лежит в xml. Но в JSON тоже можно было бы без проблем все сделать

Хотя я согласен с тем, что андроидская верстка неплохо лежит в xml. Но в JSON тоже можно было бы без проблем все сделать

+

Да, и проблема в маппинге этого xml в классы в дальнейшем есть.

Json лучше описывает обычные объекты с пропертями

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

Если вопрос в принципиальной возможности то я согласен, что в JSON можно как-то отобразить. Но это будет не полный эквивалент. JSON из коробки строит деревья без имен узлов и для детей нужно выделять именованое поле. Т.е. если у нас есть дерево без имен узлов и без детей, то мы сможем описать его и в XML и в JSON. Но если у нас есть деревья с именами узлов и детьми, то получается, что это дерево мы можем отобразить в XML 1к1. А в JSON мы начинаем рисовать другое дерево. И потом это другое дерево трактовать в оригинальное. В этом и есть вся разница. Нельзя построить дерево с помощью XML и с помощью JSON 1к1. С JSON ты получишь другое дерево, которое сможешь по своим правилам трактовать, но это будет другое дерево, без имен узлов, и с именоваными полями в объявлениях детей.

Я все.

Ну и собственно, Виталий, челендж ты проиграл, потому что ты нарисовал другое дерево, и не мог в принципе нарисовать дерево, как в XML, потому что использовал JSON. Вот теперь точно все. Сори.

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

а pointer to pointer в свифт можно сделать? или свифт не поддерживает такие извращения?)

Да как так-то

Да. Все зависит от дерева.

Да как так-то

Ну потерпи пару недель или бету качай xcode 9. Эти возмущения уже устарели

Да как так-то

Так и живем, 9ку ставь

Так и живем, 9ку ставь

Я с девятки откатился)

Да как так-то

это потому что не на xml написано

Уж подожду релиза

Уж подожду релиза

Ну хз, последняя бетка очень гуд работает

Аж подозрительно

Ну хз, последняя бетка очень гуд работает

А, ну значит икскод в целом паршив))