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


AVK>На событие XmlSerializer.UnknownNode глядел?

А с индексами референсов что делать? Нумерация-то объектов ведь сквозная.

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

vdimas wrote:
> C>Писал в свое время такое "чудо" для Java. Всего-то надо написать
> C>реализацию обхода по графу объектов
> Э-э нет, мне подавай готовое решение ср-вами дотнет. Это нужно писать
> собственные форматтеры на каждый из вариантов — бинарный и XML, которые,
> встретив неразрешимый референс, будут десериализовать его в некий
> "черный ящик", который сумеет сериализовать свое содержимое обратно.
У меня все проще было — я обходил по графу объектов, записывал
содержимое объектов в "словарь", затем отдельно записывал ссылки между
объектами.

С форматтерами не заморачивался (их в Java нет ), а просто писал
сразу в поток.

> если учесть, что предлагается сохранение произвольного графа объектов,
> вместо четкого разделения на однонаправленный граф вложенных элементов,
> то этот упомянутый "черный ящик" должен будет уметь корректировать
> индексы референсов на объекты во время последующего сохранения (во время
> сериализации те объекты, на которые есть референсы, нумеруются). В
> общем, для реализации даже этой этой мини-задачи "в духе дотнет"
> придется малость попотеть.
Я за день написал

Хотя да, если все делать аккуратно, то потребуется немного больше
времени. Да и сериализовать .NET-объекты немного сложнее.

> C>Больше бери. Тем более, что если делать — то надо некоторые недоработки
> C>в OLE будет исправлять.
> Ну там рефакторинг небольшой, и надо закрыть пару хаков в нем, когда он
> сообщения виндов в окошки других процессов посылает. Надо все явно на
> интерфейсы перевести.
Ага, еще хотелось бы уметь делать объекты, состоящие не только из одного
прямоугольника.

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

AVK>>На событие XmlSerializer.UnknownNode глядел?

V>А с индексами референсов что делать? Нумерация-то объектов ведь сквозная.

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

V>Я не говорю, что нерешаемо, понятное дело, что потратив энное кол-во человеко-дней можно будет сделать в чистом виде. Речь все это время шла о том, что без написания специализированного фреймворка вот так "в лоб" эта задача сложновата даже на дотнет.

Не надо никакого фреймворка. Эта задача уже решена. См. surrogate selector.

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

V>>А с индексами референсов что делать? Нумерация-то объектов ведь сквозная.

AVK>А зачем в хранилище референсы?

Ну, поступило предложение "просто сериализовать". Если "просто сериализовать", то 3 св-ва, скажем, в объекте верхнего уровня, ссылающиеся на экземпляр одного и того же большого объекта, приведут к тому, что будет сериализовано в 3 раза больше данных. После десериализации восстановится 3 экземпляра, что может вообще нарушить логику объекта. Поэтому мне кажется приемлимой лишь сериализация типа SOAP-сериализации. Иначе мы рискуем "хотеть как лучше, а получить как всегда" — то бишь сделать просто, но наложить серьезные ограничения на использование. Т.к. ограничения не контролируемые ни компилятором ни чем иным, то это все будет заявкой на очередное глюкалово.

AVK>Впрочем если так захотелось, то без проблем, только вместо XmlSerializer придется использовать какой нибудь форматтер.

Речь о том, что "захотелось" использовать имеющиеся ср-ва, то бишь задействовать готовый фреймворк сериализации вместо пихания в иерархические стримы. Хотя, само требование пихания в иерархические стримы организует информацию "однонаправленно", в отличие от "обычных объектов".


V>>Я не говорю, что нерешаемо, понятное дело, что потратив энное кол-во человеко-дней можно будет сделать в чистом виде. Речь все это время шла о том, что без написания специализированного фреймворка вот так "в лоб" эта задача сложновата даже на дотнет.

AVK>Не надо никакого фреймворка. Эта задача уже решена. См. surrogate selector.

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

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

V>Ну, поступило предложение "просто сериализовать". Если "просто сериализовать", то 3 св-ва, скажем, в объекте верхнего уровня, ссылающиеся на экземпляр одного и того же большого объекта, приведут к тому, что будет сериализовано в 3 раза больше данных.

Граф надо грамотно проектировать.

AVK>>Впрочем если так захотелось, то без проблем, только вместо XmlSerializer придется использовать какой нибудь форматтер.

V>Речь о том, что "захотелось" использовать имеющиеся ср-ва, то бишь задействовать готовый фреймворк сериализации вместо пихания в иерархические стримы.

А ворматтеры это не имеющиеся средства?

AVK>>Не надо никакого фреймворка. Эта задача уже решена. См. surrogate selector.

V>Он не для того.

Для того. В частности этим пользуется ремоутинг для сериализации ссылок.

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

А это и не нужно.

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

V>>Ну, поступило предложение "просто сериализовать". Если "просто сериализовать", то 3 св-ва, скажем, в объекте верхнего уровня, ссылающиеся на экземпляр одного и того же большого объекта, приведут к тому, что будет сериализовано в 3 раза больше данных.

AVK>Граф надо грамотно проектировать.

Дык... здравствуй ограничение раз.

AVK>>>Впрочем если так захотелось, то без проблем, только вместо XmlSerializer придется использовать какой нибудь форматтер.

V>>Речь о том, что "захотелось" использовать имеющиеся ср-ва, то бишь задействовать готовый фреймворк сериализации вместо пихания в иерархические стримы.

AVK>А ворматтеры это не имеющиеся средства?

Ну дык, побежали по кругу, что ли? Я же и говорил, что в большинстве форматтеров (в 2-х из 3-х) есть сквозная нумерация ссылок. При восстановлении отсутствующего на машине объекта (частая ситуация в ОЛЕ) и последующем сохранении надо будет грамотно эти ссылки корректировать. Если не обеспечить все это каким-нибудь строгим непробиваемым ограничением (а не "граф надо грамотно проектировать"), и позволить ссылки из объекта "наверх" по графу, то задача кажется вообще неразрешимой на имеющихся ср-вах даже с подпорками.

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

AVK>>>Не надо никакого фреймворка. Эта задача уже решена. См. surrogate selector.

V>>Он не для того.

AVK>Для того. В частности этим пользуется ремоутинг для сериализации ссылок.

Они используются для любых случаев, где нам надо вмешиваться в сериализацию. Ты, по сути, пытаешься натолкнуть меня на мысль, как реализовать процесс вмешательства в стандартную сериализацию — десериализацию. Но это не проблема — вклинюсь. Вклиниться можно даже без суррогат-селекторов, если самим граф перебирать (несложно, ИМХО). Можно тогда понасоздавать своих интерфейсов-аналогов этим селекторам и юзать вовсю совместно с уже имеющимися кусками фреймворка относительно сериализации. Т.е. это все не проблема. Проблема в самих данных, кои в общем случае частенько рекурсивные без четко выраженной однонаправленности. Количество побочных эффектов от "частичной" десериализации такой каши способно превзойти все ождания.

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

AVK>А это и не нужно.

Наверно у меня плохо получается выражать свои мысли. Ну представь, что у тебя есть некий объект А, который умеет сериализоваться. Мы его "редактируем", и присваиваем одному из его св-в ссылку на другой объект B. Потом пытаемся восстановить это все из потока на другой машине. Часть А не работает — нету сборки на машине, например (это был вложенный документ со ссылкой на стиль из отцовского док-та). В процессе редактирования мы убили "соседний" объект B, на который ссылалось поле из А. Наши действия при обратном сохранении всего док-та?

Все-таки, однонаправленный граф без рекурсий ОЧЧЕНЬ удобная и надежная штука. Каждая ветка такого графа независима от вышестоящих и может рассматриваться как отдельный жизнеспособный элемент.

В принципе, я тут оговорился насчет ручной беготни по графу... Может сойти на первое время, если в процессе сериализации выстраивается тот самый граф, и проверяется на рекурсивность (при проходе). Запросто можно использовать весь имеющийся фрейморк сериализации (всякие BinaryReader-ы и ObjectManager-ы).

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

V>Ну дык, побежали по кругу, что ли? Я же и говорил, что в большинстве форматтеров (в 2-х из 3-х) есть сквозная нумерация ссылок. При восстановлении отсутствующего на машине объекта (частая ситуация в ОЛЕ) и последующем сохранении надо будет грамотно эти ссылки корректировать.

Ну и в чем проблема?

V> Если не обеспечить все это каким-нибудь строгим непробиваемым ограничением (а не "граф надо грамотно проектировать"), и позволить ссылки из объекта "наверх" по графу, то задача кажется вообще неразрешимой на имеющихся ср-вах даже с подпорками.

Она уже разрешена в ремоутинге.

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


AVK>Она уже разрешена в ремоутинге.

Кстати да, похожая задача. Будет работать для MBR. Я только не помню навскидку, можно ли генерировать URI без поднятия каналов, а самое главное — можно ли потом эти URI насильно присваивать и заставлять ресолвить при десериализации?

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

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

V>Кстати да, похожая задача. Будет работать для MBR. Я только не помню навскидку, можно ли генерировать URI без поднятия каналов,

А зачем? Канал это абстракция, вполне подходящая и в обсуждаемом случае.

V> а самое главное — можно ли потом эти URI насильно присваивать и заставлять ресолвить при десериализации?

Зачем?

V>Похоже, там пахнет разработкой своего канала/синка.

Канального синка достаточно.

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

Надо смотреть на рынок. Сейчас это C#, C++ — для них работу найти элементарно.
Загружать всякой академической муднёй типа пролога и рефала — категорически не нужно, кому надо — разберутся сами.
В том, что они изучили "просто процедурные языки" нет ничего плохого — будут лучше понимать машину.
Настоятельно рекомендую немного пройтись по прикладным отраслям — Базы данных (соединился, выполнил пару команд, отсоединился), сеть (всё про сокеты), threads. Ну а реальные навыки они всё равно получат на работе. Главное — не перегнуть палку с теорией — чем больше вы даёте информации, тем она скучнее (лучше меньше, да лучше).
Не помешают основы Web — сам HTML, XML, принцип работы сервера, ASP. Компьютерная графика — про неё стоит упомянуть, но без особой размазни — уж больно сложная/примитивная на данном этапе технология.

Если хотите, найдите одного хорошего человека: Подбельский Вадим Валерьевич (преподаватель в МГИЭМ). Он владеет и программированием, и преподаванием — найдёте что подчерпнуть.

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

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

T>Надо смотреть на рынок. Сейчас это C#, C++ — для них работу найти элементарно.

Ну этому в бурсах должны учить. Но мы же вроде о ВУЗах?

T>>Надо смотреть на рынок. Сейчас это C#, C++ — для них работу найти элементарно.

ANS>Ну этому в бурсах должны учить. Но мы же вроде о ВУЗах?

Э-э-э... не понимаю вашего жаргона. "Бурсы" — это... "курсы"?

Неважно, о чём мы. Выходя из ВУЗа программист просто ОБЯЗАН знать хотя бы один ООП язык. Лучше, если он ещё к тому же будет коммерчески востребованным. Безусловно, Smalltalk — лучший представитель ООП, но работу проще найти именно по Ц++ и Це-четыре-плюса.

Thornik wrote:

> Неважно, о чём мы. Выходя из ВУЗа программист просто ОБЯЗАН знать хотя
> бы один ООП язык. Лучше, если он ещё к тому же будет коммерчески
> востребованным. Безусловно, Smalltalk — лучший представитель ООП, но
> работу проще найти именно по Ц++ и Це-четыре-плюса.
Выпускник ВУЗа не обязан знать язык, он обязан знать ООП.

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

Кё> А вот многие ли сделали из всего этого вывод, что принцип, заложенный в систему образования (учись так, чтобы получать одни пятерки, и все у тебя потом будет хорошо) — не работает? Если кто-то считает, что тот мизерный процент действительно наученных людей — это и есть успех В/О... удачи. По мне, так это полный провал. Да и эти люди как раз не отличники!

А Вам никто и не говорил, что: "получай одни пятерки, а за это все у тебя будет потом хорошо". Я говорил об ином: "почему бы тебе не получать пятёрки если ты не дурак и не из америки приехал?".

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

Вспомнил себя (два красных диплома, все пятёрки, + кандидатский диплом) и своих бывших одногрупников. Все получили по своим творческим способностям... Кто вечно прогуливал, списывал, пил и курил, тот и сейчас работает на дурацкой работе, пьёт и курит; а кто проявлял творческие способности — сейчас работает в нормальных компаниях. Вчера шел по улице и встретил одного бывшего сокурсника, которому на экзамене помогал решить задачу. Да он от пива круглый стал. Продавцом компьютерной техники работает.

_>Выпускник ВУЗа не обязан знать язык, он обязан знать ООП.

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

Thornik wrote:

> _>Выпускник ВУЗа не обязан знать язык, он обязан знать ООП.
>
> гыыы А деньги ему за что платить будут? За умничанье на форумах? Вы хоть
> прежде чем писать, посмотрите на буржуев: может они и не столь сильны в
> полит-истории и убирании картошки, но зато каждый из них, выходя во
> "взрослый мир", способен уже ОТДАВАТЬ, а не нудить перед коллегами
> "научите меня плюсам".
Если ты считаешь, что выпускнику сразу обязаны давать крутую работу, да крутую зарплату — ну-ну...
Обычно человек должен как минимум пол года "поработать за еду", чтобы понять, что такое "работать". ВУЗ никогда не давал
такой опыт, и не должен давать. А за пол года при хорошем образовании можно и яву, и шарпы, и плюсы освоить.
Если студент толковый, то он уже пытается куда-нидь пристроится на 4-5 курсе, дабы получить опыт работы, чтобы
выпустившись из ВУЗа уже "иметь лицо".

По используемым технологиям ВУЗ всегда отстаёт на несколько лет, ибо нужно писать программу курса, да потом несколько
семестров отлаживать. Поэтому если сейчас пытаться вводить, например, C#, то только через года 3-4 когда наконец
появятся более менее эффективные, отработанные методы преподавания, а скорее всего через эти 3-4 года С# умрёт, появится
какой-нибудь C#++ и всё, опять мимо тазика.

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

T>>>Надо смотреть на рынок. Сейчас это C#, C++ — для них работу найти элементарно.

ANS>>Ну этому в бурсах должны учить. Но мы же вроде о ВУЗах?

T>Э-э-э... не понимаю вашего жаргона. "Бурсы" — это... "курсы"?

ПТУ.

T>Неважно, о чём мы. Выходя из ВУЗа программист просто ОБЯЗАН знать хотя бы один ООП язык. Лучше, если он ещё к тому же будет коммерчески востребованным. Безусловно, Smalltalk — лучший представитель ООП, но работу проще найти именно по Ц++ и Це-четыре-плюса.

Еще раз — рабочие (а именно ими являются кодеры со знанием одного языка) свои знания для работы всегда получали в профессиональных технических училищах. Кстати, не знаю как сейчас, но раньше там учились сразу после 8 класса (при 10 летнем обучении). А значит и бабло можно раньше начать загребать раньше, чем после 2 лишних лет школы и 5 института.

_>Если ты считаешь, что выпускнику сразу обязаны давать крутую работу, да крутую зарплату — ну-ну...

Это твои слова. Хочешь сам с собой поспорить? Дурная привычка. Вернись к исходному сообщению и ещё раз перечитай.


_>Обычно человек должен как минимум пол года "поработать за еду", чтобы понять, что такое "работать".

) А в монахи ему не постричься? Я считаю, что в 24 года надо уже кое-что из себя представлять.
Разумеется, практика работы в проф.коллективе для него — новое, но сам процесс программирования должен быть не сложнее завязывания шнурков.


_> ВУЗ никогда не давал такой опыт, и не должен давать.

Это ваше личное мнение. Возможно, ошибочное.


_> А за пол года при хорошем образовании можно и яву, и шарпы, и плюсы освоить.

Не вопрос. А кто за это ПЛАТИТЬ будет?


_>Если студент толковый, то он уже пытается куда-нидь пристроится на 4-5 курсе, дабы получить опыт работы

Увы, именно порочная практика СССР по выпуску <...> (извините, "инженеров") и породила такое недоразумение.


Студент, как ОБУЧАЕМЫЙ, должен тратить время не в шарашках "на-пол-дня", а семинарах и лабораторках.


_>По используемым технологиям ВУЗ всегда отстаёт на несколько лет

Не ВУЗ, а старые пердуны без желания обучаться. Я лично обучался у человека (ему за 60), который осваивал HTML и сам же его преподавал.
А благодаря хорошей преподавательской подготовке и компьютерным навыкам сделал это ПОНИМАЕМЫМ для студентов.


_> Поэтому если сейчас пытаться вводить, например, C#, то только через года 3-4 когда наконец
_>появятся более менее эффективные, отработанные методы преподавания, а скорее всего через эти 3-4 года С# умрёт, появится
_>какой-нибудь C#++ и всё, опять мимо тазика.

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

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

_>Выпускник ВУЗа не обязан знать язык, он обязан знать ООП.

Извините, но кому тогда будет нужен этот недоделанный теоретик? Ведь он ни в науке ничего сделать не сможет, ни работать.

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

T>>Э-э-э... не понимаю вашего жаргона. "Бурсы" — это... "курсы"?

ANS>ПТУ.

Предлагаю закочить говорить о псевдонаучной фантастике. В ПТУ программистов не готовят. Вот когда начнут, тогда и поговорим. А пока что программистов готовят в ВУЗ-ах и т.п.