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


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

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

S>Здравствуйте, Serginio1, Вы писали:
S>> Можно сделать достаточно простой транзакционный механизм с версионностью на уровне страниц.
S>[пересказ механики ранних interbase поскипан]
Ну вот видишь как полезно изобретать велосипед
S>Фишка в том, что не вполне ясна методика коммита, а также действия СУБД при восстановлении после сбоя. То, что ты рассказываешь, пока относится только к одновременному использованию. Или ты, как обычно, на какую-то свою тему уже съехал?
Одновременной записи, но неограниченном чтении, (хотя и писателей можно сделать больше но проблем намнооого больше).
При комите идет корректировка ссылок на новые страницы и цепочку версионных страниц в таблице отвечающую за цепочку страниц.
С сохранением старых страниц для отката, при запуске.

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

VD>Говорить о том как это будет пока что не решается даже сам Хегельберг (или как там его?).
Судя по тому, что он дотчанин (не изучал оного) Но скандинавы ближе к немецкому то скрее Хэйлсберг или Хайлсберг

VladD2 пишет:

> C>Не знаю как вам, но для меня SQL в языке — бред.
> Ничего не слышал о ESQL? Он существет и для С и для С++.

Я слышал и об sqlj, даже работал с ним. Моего мнения это не меняет.

> Лично для меня разумным является любое повышение контроля и увеличение
> удобства если при этом оно не видет к потере универсальности и
> качества. Так что если ребята из МС сделают это безшевно и не
> напряжно, то я буду рад.

А мне вот хочется, чтобы еще и 3D графику в язык интегрировали. Чем она
хуже SQL?

> C> Так как это скорее всего будет сделано в виде железной привязки к
> MSSQL (знаем мы этих
> C>МСников...).
> Похоже "вы" их совсем не знаете. Они конечно интергрируют свои
> продукты, но при этом они всегда блюдут традиции универсальных АПИ.

POSIX они, например, очень классно поддерживают. С WS та же история.

> Думаю, что если поддержка БД будет встроена в Шарп, то она будет
> сделана на базе ADO.NET, а оный АПИ и сегодня неплохо поддерживает БД
> других производителей.

Но при этом это все будет заточено под MSSQL

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 пишет:

> C>Гадость. В язык тянут прикладные вещи типа XML, вместо того, чтобы
> C>добавить средства, позволяющие реализовать то же самое, но в виде
> библиотек.
> Э батенька. В иде библиотек это уже есть. Но тут возникает две проблемы:
> 1. С ними сложнее работать чем со встроенными возмжностями языка.

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

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

Это смотря какие библиотеки и смотря на каком языке. Да и generic'и уже
не за горами.

> В принципе есть один выход из положения (чтобы и язык не расширять и
> проблем не иметь). Нужно создать мета-фрэймворк которые позволит
> дописывать такие фичи в виде мета-библиотек. По сути это будет такое
> же расширение компилятора, но его сможет сделать каждый смертаный, так
> как это будет делаться через специальный АПИ.

Это пол-года назад в fido7.su.softw обсуждалось. Называется DSL (Domain
Specific Language), сейчас JetBrains (создатель IDEA) активно в этом
направлении копает. Мне эта идея не особо нравится (слишком много
возможностей для abuse), но я признаю, что иногда такой подход может
быть полезным.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 пишет:

> GZ>Не тем что он похож на SQL. Мне на это полностью начхать. XPath
> все-таки подразумевает дерево(для того и делался), а не произвольный граф.
> А ХМЛ и есть дерево. Граф объектов тоже в общем-то дерево. По крайней
> мере для нас деревянных.

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

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

E>А как будет выглядеть запрос в XPath, если XML выглядит так (идея в том, что b -- это ссылки на другие объекты):
E>

E><some-root>
E><a f="10">
E>    <b ref="#0001" />
E>    <b ref="#0002" />
E></a>
E><b id="0001" f="15" />
E><b id="0002" f="20" >
E>    <c f="25" />
E>    <c f="30" >
E>        <d f="40" /> <!-- значение атрибута f этого узла и надо получить -->
E>    </c>
E></b>
E></some-root>
E>

/b[ /a[@f=10]/b/@ref=@id and @f=20 ]/c[ f=30 ]/d/@f

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

E>Да я вообще-то о том, что это мне Perl напоминает. Сколько раз не пытался начать его использовать, все равно через три дня забывал, чем @ от $ отличается
E>Да и вообще, это типа шутка была.

Ну, в XPath "@"- это просто сокращенная форма записи от "attribute::". То есть b[@f=10] это всеравно, что b[attribute::f=10]. Так что, если не нравится символ "@", то его можно и не использовать

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ANS>Похожа, что будет слишком похоже на устаревший Smalltalk или поросший
ANS>мхом CLOS.

Не думаю, что это реальная причина. Они очень многое позаимствовали из "поросших мхом". Думаю, совесть — это единственно что их не беспокоит.

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

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

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

C>Это смотря какие библиотеки и смотря на каком языке. Да и generic'и уже
C>не за горами.

Дженерики тут к сожалению никак не помогу. Единственное что тут помогло бы — это средства метапрограммирования. Тут именно проблема динамического перехода между двумя системами типов.

>> В принципе есть один выход из положения (чтобы и язык не расширять и
>> проблем не иметь). Нужно создать мета-фрэймворк которые позволит
>> дописывать такие фичи в виде мета-библиотек. По сути это будет такое
>> же расширение компилятора, но его сможет сделать каждый смертаный, так
>> как это будет делаться через специальный АПИ.

C>Это пол-года назад в fido7.su.softw обсуждалось. Называется DSL (Domain
C>Specific Language), сейчас JetBrains (создатель IDEA) активно в этом
C>направлении копает. Мне эта идея не особо нравится (слишком много
C>возможностей для abuse), но я признаю, что иногда такой подход может
C>быть полезным.

Гы. Это лет 30 разад обсуждалось и к DSL — это никакого отношения не имеет. DSL тоже интересно решение, но оно как бы параллельно метапрограммированию. Метапрограммирование может оказаться хорошим средством реализации DSL-проектов. Но обратное не врено. Метапрограммирование расширяет возможности конкретного языка. А DSL создает новый язык который как не крути прийдется мапить на обычные языки программирования. Вот такой мап и можно упростить с помощью метапрограммирования.

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

C>А мне вот хочется, чтобы еще и 3D графику в язык интегрировали. Чем она
C>хуже SQL?

Тем что это не язык. А то что можно уже интегрировали. Про Cg слыхал?

C>Но при этом это все будет заточено под MSSQL

Это твои домыслы.

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

E>Да я вообще-то о том, что это мне Perl напоминает. Сколько раз не пытался начать его использовать, все равно через три дня забывал, чем @ от $ отличается
E>Да и вообще, это типа шутка была.

Вот так тебе понятнее:

//class[attribute::Name == 'MyClass']

?

Чтобы стало понятнее:
// — означает искать во всех подветках начиная от корня.
[] — задает фильтр.
attribute:: — (тоже самео что и @) говорит что просходит обращение к атрибуту (свойству), а не элементу (тегу, классу).

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

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

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

VladD2,

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

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

1) Дерево остовное. 2) Не всегда получится. И лесом не всегда выйдет, не только деревом. 3) Даже когда можно, это не всегда имеет смысл с точки зрения прикладной задачи.

> Такое представление для человеческого мозка более приемлемо.

Это сильно зависит от ТТХ.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>1) Дерево остовное. 2) Не всегда получится. И лесом не всегда выйдет, не только деревом. 3) Даже когда можно, это не всегда имеет смысл с точки зрения прикладной задачи.

Не всегда. Во только в то области где в основном применяются ХМЛ и БД древовидное представление всегда рулит. Да ООП тоже к деревья наовит строить. А раз мы пишем код на ООЯ, то и данные хорошо бы иметь ОО. Основаня проблема связи РСУБД с ООЯ — это как раз превращение реляции в деревья.

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

>> Такое представление для человеческого мозка более приемлемо.

ПК>Это сильно зависит от ТТХ.

Мозга?

VladD2,

>>> Такое представление для человеческого мозка более приемлемо.

> ПК> Это сильно зависит от ТТХ.

> Мозга?

Да!

VladD2 пишет:

> C>Не всегда. Кроме того, у этого подхода есть недостатки — библиотеку я
> C>могу расширить или выбросить и взять другую, а с языком такие штучки не
> C>получатся.
> Встраивая поддрежку паттерна в язык разработчики этого языка обычно
> довольно глубоко продумывают что и как делать. В противном случае они
> просто угробят язык. А необходимость обратной совместимости не даст
> исправить ошибку в дальнейшем. Все это праткически гарантирует высокое
> качество реализации. Ну, а то что появляется стандарт на реализацию и
> изображение паттерна — это очень хорошо. И людям будет проще код
> читать/писать и разным средсвам анализа кода.

Это мы уже проходили на примере С++. Там в язык добавили столько
средств, что сейчас в полной мере все возможности С++ не знает и
Страуструп, наверное. Причем обычно создателям не удается просмотреть
все взаимные влияния фич на этапе их добавления, и недостатки выявляются
уже во время использования. Так было с С++ным bool'ом, например.

> C>Это смотря какие библиотеки и смотря на каком языке. Да и generic'и уже
> C>не за горами.
> Дженерики тут к сожалению никак не помогу. Единственное что тут
> помогло бы — это средства метапрограммирования. Тут именно проблема
> динамического перехода между двумя системами типов.

НЕЛЬЗЯ сделать язык, система типов которого будет совместима со всем,
чем только можно. Лучше бы создателям С# это понять, а не пытаться
адаптировать систему типов под SQL, XML и т.п. А если завтра придет
кому-нибудь в голову поддержку ASN1 добавить?

> C>Это пол-года назад в fido7.su.softw обсуждалось. Называется DSL (Domain
> C>Specific Language), сейчас JetBrains (создатель IDEA) активно в этом
> C>направлении копает. Мне эта идея не особо нравится (слишком много
> C>возможностей для abuse), но я признаю, что иногда такой подход может
> C>быть полезным.
> Гы. Это лет 30 разад обсуждалось и к DSL — это никакого отношения не
> имеет. DSL тоже интересно решение, но оно как бы параллельно
> метапрограммированию.

Я считаю их практически очень близкими понятиями.

> Метапрограммирование может оказаться хорошим средством реализации
> DSL-проектов. Но обратное не врено. Метапрограммирование расширяет
> возможности конкретного языка. А DSL создает новый язык который как не
> крути прийдется мапить на обычные языки программирования. Вот такой
> мап и можно упростить с помощью метапрограммирования.

Как ни крути, а возможности для abuse'а у метапрограммирования слишком
большие.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 пишет:

> C>А мне вот хочется, чтобы еще и 3D графику в язык интегрировали. Чем она
> C>хуже SQL?
> Тем что это не язык.

Почему? Берем матрицы, векторы (можно еще и тензоры ), добавляем их в
язык. Затем добавляем в язык геометрические тела в виде примитивов и
операции над ними в виде примитивных операций.

> А то что можно уже интегрировали. Про Cg слыхал?

Ну так и sqlj тоже есть давно для SQL. А я вот хочу в 3D-графику в C#!

> C>Но при этом это все будет заточено под MSSQL
> Это твои домыслы.

Я помню что произошло с COM'ом (точнее с OLE). МС кричала, что это будет
кроссплатформенная кроссязыковая технология, для любого языка
программирования и т.п. А получилось, что OLE по странному совпадению
лучше подходит для VisualBasic'а.

--
С уважением,
Alex Besogonov (alexy@izh.com)

VladD2 пишет:

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

Это неинтересно и неудобно Я кстати, лично сравнивал оба подхода. Для
Java есть такие замечательные вещи: Object Graph Navigation Language
(http://www.ognl.org/) и JXPath
(http://jakarta.apache.org/commons/jxpath/).

OGNL — это специальный язык для работы с графами объектов, позволяет
удобно делать выборку объектов, манипуляцию с ними и т.п.

JXPath — это XPath, но работающий с графами Java-объектов (причем он
работает и с XML DOM-деревьями как с частным случаем ).

Через неделю тестов мне OGNL стал нравится намного больше, чем JXPath,
как раз из-за ориентации на _графы_ объектов без явной иерархии.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>Это мы уже проходили на примере С++. Там в язык добавили столько
C>средств, что сейчас в полной мере все возможности С++ не знает и
C>Страуструп, наверное.

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

C> Причем обычно создателям не удается просмотреть
C>все взаимные влияния фич на этапе их добавления, и недостатки выявляются
C>уже во время использования. Так было с С++ным bool'ом, например.

Полно те. Сколько тех изменений в нем было?

C>НЕЛЬЗЯ сделать язык, система типов которого будет совместима со всем,
C>чем только можно. Лучше бы создателям С# это понять, а не пытаться
C>адаптировать систему типов под SQL, XML и т.п.

Не боись. Они явно не тупее нас с тобой.

C> А если завтра придет
C>кому-нибудь в голову поддержку ASN1 добавить?

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

C>Я считаю их практически очень близкими понятиями.

И ошибашся. Подходы довольно разные.