Зачем хранить конф файлы в XML ?!

по поводу Data - тоже не точно (тоже надо в доке глядеть)

а тут строго определенные правила, именуемые не иначе как

Это именно быдлокодинг - притаскивание чужеродных правил.
Хотя о чём это я, це же маководы.

ОК.
Если так защищаете данный быдлокодинг, то покажите XPath выражение для выборки заданной пары.

Не только '( и ') и не только для лиспа. Правда, для других языков это не так удобно.

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

Я тоже пока. Но! передача информации между человеками происходит путём упорядоченного вынимания на поверхность сознания получателя идей, размышление над которыми может привести к появлению у получателя клона передаваемой идеи. Пример: «функция, имеющая непрерывную производную на всём множестве определения» - вспомнили, что такое «функция», что такое «непрерывная», что такое «производная», и т.д. Каждая из этих идей ранее была заложена в сознание тем же трудоёмким способом, ссылками на более простые ранее засунутые идеи. Почему то же нельзя было передавать в виде картинок с самого рождения? По той же простой причине - средства визуального вывода человеческого тела сильно хуже звуковых(впрочем, может и не сильно, многие обходятся ими). Чего, очевидно, нельзя сказать о входных каналах, тут визуальные рулят по всем параметрам, кроме ширины диаграммы направлености(хотя это тоже плюс вне дикой природы, т.к. сложные идеи требуют концентрации). Увы, при передаче человек-человек полоса ограничивается более узким каналом, речью. Соответственно, с приходом всяких NT теоретически возможно передавать данные более эффективно, т.к. «вывод» нужен сильно реже «ввода» - если учитель/автор/etc будет писать неделю то, что миллион проглотит за минуту, общие затраты составят 1.0024 Mминут, а при 2хминутном(что очень оптимистично) проговаривании/прослушивании - 2.000002Mм. Это не очень подходит для real time/life, где задержка может быть критичной, но такого становится всё меньше, и там сложность информации отсутствует, т.ч. хватит языка попроще.

После применения a=b b=c a!=c, а после применения b=c a=b между собой равны все три параметра

>общий вид в таком случае теряется
Что?

>вовторых число может быть любое
[facepalm.png]

Whatever.

Мнимое преимущество JSON над XML только в том, что открытие и закрытие блока происходит короткими символами «{» и «}». Это преимущество исчезает, когда появляется всякая вложенность, и непонятно, какой элемент закрывает очередная скобка.

А больше «преимуществ» то и нет.

Я настолько слоупок, что всё ещё хочу старые добрые .conf ?

Не слоупок, а суперстар :) . Пора хотеть YAML.

А потом сравни результаты.

Да вы совсем дурачок.

Это именно быдлокодинг - притаскивание чужеродных правил.
Хотя о чём это я, це же маководы.

послушайте... по поводу реализации Property List - негодуйте в Apple Developer Forum или Support Communities, объясняйте им, что у них негодный - неправильный xml и вообще они быдлокодеры у которых руки из жопы растут, все криво косо и ничего не работает.. какой смысл со мной это обсуждать?

тема разговора конф файлы в XML, а где у нас широко используются конфиги в XML? (и не просто широко - а так сказать «глобально») - в макосх.., нет жеж надо набижать на мой коммент и начать мне разъяснять что «это чтото плохое» и «приличные люди так не делают».. Вы меня в чем то хотите убедить? может в том что синтаксис plist резко отличается и не XML-ный ниразу, или в том что plist не является ни xlink, ни xsl, ни svg и вообще из мордора? так а зачем тогда демагогию было разводить...

ОК. Если так защищаете данный быдлокодинг, то покажите XPath выражение для выборки заданной пары.

не знаю я хпатча..

вы меня просите строку из плист в хпатч перевести?

После применения a=b b=c a!=c, а после применения b=c a=b между собой равны все три параметра

С чего вдруг? Вы понимаете, где значение, а где ключ в данном случае?

(в продолжение вышесказанного) валидируется как раз «содержимое»:

То есть какая-то валидация всё же есть?

Удаляюсь, сражённый вашей аргументацией.

Ну и зачем валидация в данной ситуации нужна? Структура конфига то заранее известна. Что мешает сделать как-то так в программе?

unsigned long read_config_int(char *var_name, int default_value);
...
int my_int_param = read_config_int("my-int-param", 100500);

Зачем пользователю задавать тип для каждого параметра, когда программа и так знает, что хочет. Ну что какой смысл? Задаст пользователь числовой параметр в теге <string> и всё равно программе придётся обработать ошибку. И всё равно она будет использовать что-нибудь вроде read_config_int, read_config_string, read_config_binary и т. п., потому что переменная, куда в итоге поместится значение не любого типа, а вполне конкретного и нужно преобразование.

JSON отлично подходит, когда структура конфига и типы данных известны. Конечно, для каких-нибудь конфигов с полностью неизвестной структурой, лучше XML, но они уже будут ближе к некому языку программирования или документу (вроде HTML), чем к нормальному конфигу.

Удаляюсь, сражённый вашей аргументацией.

Чем ваша аргументация в этом топике была лучше?
Вот мой аргумент:
Зачем хранить конф файлы в XML ?! (комментарий)

Есть: отсутствие избыточной информации.

{
        "objects": [
                {
                        "x": "10",
                        "y": "5",
                        "z": "7"
                },
                {
                        "x": "4",
                        "y": "6",
                        "z": "8"
                }
        ]
}

приятнее, чем:

<config>
        <objects>
                <object>
                        <x>10</x>
                        <y>5</y>
                        <z>7</z>
                </object>
                <object>
                        <x>4</x>
                        <y>6</y>
                        <z>8</z>
                </object>
        </object>
</config>

JSON отлично подходит для конфигов, потому что их структура всегда заранее известна (что «count» это именно число, что «object_list» это именно массив, а любые отклонения - ошибочной конфиг).

XML для документов, чья структура заранее неизвестна (допустим, всякие HTML, SVG и т. д.).

Спасибо, разжевал. Даже добавить нечего

Вы сказали, что xml говно, есть решения лучше - yaml и json.

Тут верно.

Но json лучше yaml, поскольку последний нечем парсить.

А вот такого я не говорил. Я упомянул это как объяснение того, почему я привёл сразу два варианта. YAML более читаемый, но JSON иногда более удобен для разработчика, вот и всё.

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

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

Специально для вас повторю - в ini (а мы говорим о нем) порядок следования пары ключ=значение внутри секции не имеет значения для парсера, но имеет значение для diff. Вы настолько тупы, что не можете это осознать?

Что за бред? В XML это дело можно представить гораздо прощще:

<config>
 <objects>
  <object x="1" y="2" z="3"/>
  <object x="7" y="8" z="9"/>
 </objects>
</config>

Правда, когда захочется добавить объекту свойство в виде массива придётся переписывать весь код.

Ну и ненужные закрывающие теги остаются всё равно.

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

Кто тебе такое сказал?

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

Кто тебе такое сказал?

Вот же идиот. Проверьте сами на примере любого своего конфига.

Ты готов подписаться за все конфигурационные файлы всех варинтов ini-формата? А ты смелый.

Правда, когда захочется добавить объекту свойство в виде массива придётся переписывать весь код.

Почему? Ну добавил в тег подтег с массивом и все. Так же как и в JSON.

ослушайте... по поводу реализации Property List - негодуйте в Apple Developer Forum или Support Communities,

Это что они сюда пришли? Неа, это Вы вытащили их поделие на обсуждение, вот Вам и ответ держать. Я просто сказал, что они долбодятлы, Вы же рьяно ринулись их защищать. А проблемы маководов использующих «оригинальные инженерные решения» меня не волнуют.

вы меня просите строку из плист в хпатч перевести?

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

Это что они сюда пришли? Неа, это Вы вытащили их поделие на обсуждение, вот Вам и ответ держать. Я просто сказал, что они долбодятлы

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

Вы же рьяно ринулись их защищать. А проблемы маководов использующих «оригинальные инженерные решения» меня не волнуют.

ну уж не надо - где я яблов защищал? мне говорят что «это не правильно» и «так нельзя», резонно задаюсь вопросом «почему», на что мне отвечают что это отход от правил и спецификации..

ну так елки-палки - у них все подругому, и Objective-C/C++ не С/С++ и планировщик у них не такой, и графика работает не так, и компьютеры у них странные - ThinkDifferent же...

XPath это такой язык запросов к элементам xml-документа.
т.е. мне например надо выбрать пару ключ-значение, что бы удалить из словаря.

ну тоесть это для встраивания в приложения работающие с xml ?

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

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

да есть у них наверное под это дело PlistPatch какой нибудь (как пить дать), как то же нативные игры/приложения юзают .plist для конфигов.., таже трансмиссия например - можно заглянуть..

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

В случае с JSON всё проще - каждый объект имеет атрибуты. Любой атрибут может оказаться массивом или другим объектом. Красивая простота.

Второй платиновый тред про XML? Первый был не помню про что но на 40 страниц вроде разросся

ну так елки-палки - у них все подругому, и Objective-C/C++ не С/С++ и планировщик у них не такой, и графика работает не так, и компьютеры у них странные - ThinkDifferent же...

Так я и говорю - доверили дураку стеклянный хер.

ну тоесть это для встраивания в приложения работающие с xml ?

В том числе и для этого. Что так трудно зайти на ту же педивикию и прочитать что такое XPath?

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

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

«Эта музыка будет вечной»

Ты готов подписаться за все конфигурационные файлы всех варинтов ini-формата? А ты смелый.

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

В случае с JSON всё проще - каждый объект имеет атрибуты. Любой атрибут может оказаться массивом или другим объектом. Красивая простота.

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

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

Угу. Я подписался, что ini-файлы бывают разные. Готов отстаивать это убеждение.

И да, я смелый и очень крепкий.

А я умный. Очень приятно.

Угу. Я подписался, что ini-файлы бывают разные. Готов отстаивать это убеждение.

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

А я умный. Очень приятно.

Ваши посты доказывают обратное.

Но вы упорно не хотели видеть неугодные для вас варианты.

Детка, не фантазируй.

Ваши посты доказывают обратное.

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

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

Да-да, вы все такие идиоты, только я один Дартаньян.

Детка, не фантазируй.

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

Зачем так выпендриваться, когда можно просто

objects={
{x=1, y=2, z=3},
{x=7, y=8, z=9}
}

А дебильный XML понятен только компьютеру.

вы все такие идиоты,

Не все, но ты из их числа.

XML --- это сделанный неправильно лисп. Так что

(defvar *objects*
        (list (list :x 1 : y 2 :z 3)
              (list :x 7 :y 8 :z 9)))

Не все, но ты из их числа.

Надеюсь ваша самооценка после этого выросла?

Интересуешься психологией?

Зачем так выпендриваться, когда можно просто

Потому что это стандарт, и появился ранше JSON.

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