Сообщение Re[9]: Как изменить имя в объекте типа XmlAttribute от 26.01.2017 0:27
Изменено 26.01.2017 0:29 Mystic Artifact
Re[9]: Как изменить имя в объекте типа XmlAttribute
Здравствуйте, AndrewVK, Вы писали:
F>> Ну прям значительнее... не знаю.
AVK>Можешь сам померять.
Могу конечно. А смысл? Это даже тебе не интересно.
Я хорошо знаю код из System.Xml и Xml.Linq — мне нужно его мерять, что бы сказать что приблизительно оно будет одинаково.
F>> Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.
AVK>Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.
Х.з. И там и там тупые связные списки. В System.Xml вроде есть какие-то события — не могу вспомнить есть ли они в Xml.Linq. Может потому. Чисто обход дерева — должен быть +/- одинаков. Xml.Linq — просто экономичнее по памяти — и тут тоже может сказываться на некоторых системах. Но, моему i7 (как и твоему не знаю что там у тебя) — глубоко похеру на эти отличия. Поэтому проверить я никак не могу. Я лишь могу сказать, что:
а) поддержка хорошо известного API — это плюс
б) поддержка человеко-адаптированного API — это плюс
Дотнет тут покрывает оба пункта и спорить тут реально не о чем. Никто сейчас в здравом уме без реальных на то причин не возьмется юзать System.Xml. Имхо, это и так должно быть понятно. Но, если тебе нужно спортировать код с w3c api (из питона, или из JS) — проще взять System.Xml для начала. Правда у меня с "портами" кода не получалось вообще никогда — переписывал в итоге всё совсем подругому. Так что тут ничего "авторитетного" заявить не могу.
Ещё раз — мой был поинт в том, что если есть стандарт — это хорошо когда платформа поддерживает API по стандарту. Именно это и делает System.Xml и то — в разумных рамках (на самом деле нужно взять DOMImplementation и от него скакать, как и создавать элементы через document.CreateElement -> но это контрпродуктивно в 99.9% случаях — это нужно в наше время исключительно для UA и только). Поэтому и первый вариант был компромисом. XLinq — же пошел ещё дальше, и как API для работы с XML — стал очень хорошей альтернативой. Но это не значит, что старые методы работы с ним вдруг стали плохими — наоборот — старые методы работы с ним — совершенно никак не поменялись. Ну для тривиальных задач — оно конечно да. Особенно для людей кто не парится с разницей между Children и Descendants... но, мне даже стыдно это упоминать, особенно в разговоре с тобой.
Забей короче.
TL;DR:
System.Xml.Linq — первое что должно приходить в голову.
System.Xml — для тех, кто знает толк в извращениях и legacy кода.
Справедливо, как считаешь?
F>> Ну прям значительнее... не знаю.
AVK>Можешь сам померять.
Могу конечно. А смысл? Это даже тебе не интересно.
Я хорошо знаю код из System.Xml и Xml.Linq — мне нужно его мерять, что бы сказать что приблизительно оно будет одинаково.
F>> Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.
AVK>Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.
Х.з. И там и там тупые связные списки. В System.Xml вроде есть какие-то события — не могу вспомнить есть ли они в Xml.Linq. Может потому. Чисто обход дерева — должен быть +/- одинаков. Xml.Linq — просто экономичнее по памяти — и тут тоже может сказываться на некоторых системах. Но, моему i7 (как и твоему не знаю что там у тебя) — глубоко похеру на эти отличия. Поэтому проверить я никак не могу. Я лишь могу сказать, что:
а) поддержка хорошо известного API — это плюс
б) поддержка человеко-адаптированного API — это плюс
Дотнет тут покрывает оба пункта и спорить тут реально не о чем. Никто сейчас в здравом уме без реальных на то причин не возьмется юзать System.Xml. Имхо, это и так должно быть понятно. Но, если тебе нужно спортировать код с w3c api (из питона, или из JS) — проще взять System.Xml для начала. Правда у меня с "портами" кода не получалось вообще никогда — переписывал в итоге всё совсем подругому. Так что тут ничего "авторитетного" заявить не могу.
Ещё раз — мой был поинт в том, что если есть стандарт — это хорошо когда платформа поддерживает API по стандарту. Именно это и делает System.Xml и то — в разумных рамках (на самом деле нужно взять DOMImplementation и от него скакать, как и создавать элементы через document.CreateElement -> но это контрпродуктивно в 99.9% случаях — это нужно в наше время исключительно для UA и только). Поэтому и первый вариант был компромисом. XLinq — же пошел ещё дальше, и как API для работы с XML — стал очень хорошей альтернативой. Но это не значит, что старые методы работы с ним вдруг стали плохими — наоборот — старые методы работы с ним — совершенно никак не поменялись. Ну для тривиальных задач — оно конечно да. Особенно для людей кто не парится с разницей между Children и Descendants... но, мне даже стыдно это упоминать, особенно в разговоре с тобой.
Забей короче.
TL;DR:
System.Xml.Linq — первое что должно приходить в голову.
System.Xml — для тех, кто знает толк в извращениях и legacy кода.
Справедливо, как считаешь?
Re[9]: Как изменить имя в объекте типа XmlAttribute
Здравствуйте, AndrewVK, Вы писали:
F>> Ну прям значительнее... не знаю.
AVK>Можешь сам померять.
Могу конечно. А смысл? Это даже тебе не интересно.
Я хорошо знаю код из System.Xml и Xml.Linq — мне не нужно его мерять, что бы сказать что приблизительно оно будет одинаково.
F>> Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.
AVK>Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.
Х.з. И там и там тупые связные списки. В System.Xml вроде есть какие-то события — не могу вспомнить есть ли они в Xml.Linq. Может потому. Чисто обход дерева — должен быть +/- одинаков. Xml.Linq — просто экономичнее по памяти — и тут тоже может сказываться на некоторых системах. Но, моему i7 (как и твоему не знаю что там у тебя) — глубоко похеру на эти отличия. Поэтому проверить я никак не могу. Я лишь могу сказать, что:
а) поддержка хорошо известного API — это плюс
б) поддержка человеко-адаптированного API — это плюс
Дотнет тут покрывает оба пункта и спорить тут реально не о чем. Никто сейчас в здравом уме без реальных на то причин не возьмется юзать System.Xml. Имхо, это и так должно быть понятно. Но, если тебе нужно спортировать код с w3c api (из питона, или из JS) — проще взять System.Xml для начала. Правда у меня с "портами" кода не получалось вообще никогда — переписывал в итоге всё совсем подругому. Так что тут ничего "авторитетного" заявить не могу.
Ещё раз — мой был поинт в том, что если есть стандарт — это хорошо когда платформа поддерживает API по стандарту. Именно это и делает System.Xml и то — в разумных рамках (на самом деле нужно взять DOMImplementation и от него скакать, как и создавать элементы через document.CreateElement -> но это контрпродуктивно в 99.9% случаях — это нужно в наше время исключительно для UA и только). Поэтому и первый вариант был компромисом. XLinq — же пошел ещё дальше, и как API для работы с XML — стал очень хорошей альтернативой. Но это не значит, что старые методы работы с ним вдруг стали плохими — наоборот — старые методы работы с ним — совершенно никак не поменялись. Ну для тривиальных задач — оно конечно да. Особенно для людей кто не парится с разницей между Children и Descendants... но, мне даже стыдно это упоминать, особенно в разговоре с тобой.
Забей короче.
TL;DR:
System.Xml.Linq — первое что должно приходить в голову.
System.Xml — для тех, кто знает толк в извращениях и legacy кода.
Справедливо, как считаешь?
UPD: жирным добавлено обновление. опечатка.
F>> Ну прям значительнее... не знаю.
AVK>Можешь сам померять.
Могу конечно. А смысл? Это даже тебе не интересно.
Я хорошо знаю код из System.Xml и Xml.Linq — мне не нужно его мерять, что бы сказать что приблизительно оно будет одинаково.
F>> Парсер же — один и тот же и очень неплохой. Селекция — одинакова по скорости в любом случае — односвязные списки и там и там. Удобство — это совсем другой мотив, но это же не то о чём мы говорим.
AVK>Я не про парсер, а про работу с DOM. Там даже простейшие вещи типа итерации по коллекции элементов почему то тормозят.
Х.з. И там и там тупые связные списки. В System.Xml вроде есть какие-то события — не могу вспомнить есть ли они в Xml.Linq. Может потому. Чисто обход дерева — должен быть +/- одинаков. Xml.Linq — просто экономичнее по памяти — и тут тоже может сказываться на некоторых системах. Но, моему i7 (как и твоему не знаю что там у тебя) — глубоко похеру на эти отличия. Поэтому проверить я никак не могу. Я лишь могу сказать, что:
а) поддержка хорошо известного API — это плюс
б) поддержка человеко-адаптированного API — это плюс
Дотнет тут покрывает оба пункта и спорить тут реально не о чем. Никто сейчас в здравом уме без реальных на то причин не возьмется юзать System.Xml. Имхо, это и так должно быть понятно. Но, если тебе нужно спортировать код с w3c api (из питона, или из JS) — проще взять System.Xml для начала. Правда у меня с "портами" кода не получалось вообще никогда — переписывал в итоге всё совсем подругому. Так что тут ничего "авторитетного" заявить не могу.
Ещё раз — мой был поинт в том, что если есть стандарт — это хорошо когда платформа поддерживает API по стандарту. Именно это и делает System.Xml и то — в разумных рамках (на самом деле нужно взять DOMImplementation и от него скакать, как и создавать элементы через document.CreateElement -> но это контрпродуктивно в 99.9% случаях — это нужно в наше время исключительно для UA и только). Поэтому и первый вариант был компромисом. XLinq — же пошел ещё дальше, и как API для работы с XML — стал очень хорошей альтернативой. Но это не значит, что старые методы работы с ним вдруг стали плохими — наоборот — старые методы работы с ним — совершенно никак не поменялись. Ну для тривиальных задач — оно конечно да. Особенно для людей кто не парится с разницей между Children и Descendants... но, мне даже стыдно это упоминать, особенно в разговоре с тобой.
Забей короче.
TL;DR:
System.Xml.Linq — первое что должно приходить в голову.
System.Xml — для тех, кто знает толк в извращениях и legacy кода.
Справедливо, как считаешь?
UPD: жирным добавлено обновление. опечатка.