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

O>>3. Перегрузка оператора new совместно с аттрибутами типа могла бы серьезно улучшить управление памятью.
O>>Можно было бы использовать паттерны Singleton, Flyweight и т.п. естественным образом, без специального синтаксиса фабрики.
AVK>Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.
Намекни куда покопать? Всмысле с чего ты взял что это так?

ЗЫ: Очень мне хочется почитать что-нибудь типа Design & Evolution of .NET Может кто ссылочками поделится? Интересуют только откровения создателей. Слов "фиг пойми почему MS сделала так, а не эдак" и так полно в сети...

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

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

O>>>3. Перегрузка оператора new совместно с аттрибутами типа могла бы серьезно улучшить управление памятью.
O>>>Можно было бы использовать паттерны Singleton, Flyweight и т.п. естественным образом, без специального синтаксиса фабрики.
AVK>>Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.
O>Намекни куда покопать? Всмысле с чего ты взял что это так?

Копать в сторону rotor.

O>ЗЫ: Очень мне хочется почитать что-нибудь типа Design & Evolution of .NET :) Может кто ссылочками поделится? Интересуют только откровения создателей. Слов "фиг пойми почему MS сделала так, а не эдак" и так полно в сети...

А что непонятного? Вроде как все логично :)

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

AVK>>Самое неприятное что эти жулики в родной библиотеке таки new как то для себя переопределяют, а вот ты сделать подобное не можешь.
O>Намекни куда покопать? Всмысле с чего ты взял что это так?

Remoting. Посмотри RemotingConfiguration.RegisterXXXType() и к чему он приводит. Я так тоже хочу

O>ЗЫ: Очень мне хочется почитать что-нибудь типа Design & Evolution of .NET Может кто ссылочками поделится? Интересуют только откровения создателей. Слов "фиг пойми почему MS сделала так, а не эдак" и так полно в сети...

Есть кой чего на .NET Architecture Center, но там мало. Есть кое что на www.gotdotnet.com. А так чтобы было много и в одном месте не видел.

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

[skip]

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

Да нет скорее я неправильно объясняю своё мнение.
Мне не нравится способ описания аттрибутов как непременных сущностей объектов класса.
Рассматривать это нужно как то, что объектам присущим конкретной программе и объектам проектирования не могут быть присущи одни и те же аттрибуты. То есть при проектировании объекта (утрируя представим его как один класс), я не могу утверждать, что у этого объекта вот эти поля можно игнорировать кому-либо, а кому либо нельзя. То есть правильно спроектированный и реализованный объект не должен знать о некоторых мелочах, которые будут возникать впоследствии при разработке приложения.
То есть, некоторый класс реализует всю функциональность объекта и допустим понадобилось его там сериализовать, что я делаю ... лезу в исходники объекта и проставляю нужным полям нужные аттрибуты ... понадобилось сделать ещё и некоторым статическим переменным синхронизацию по потокам, опять лезу в исходники. В конце концов образуется монстр, который очень сильно привязан именно к конкретной программе и используется структурами этой программы. Вытащить оттуда этого монстра практически невозможно без коренной переделки всей программы.
Аналог я усматриваю например в проставлении дефолтовых значений внутренним полям объекта, которые без коренной переделки объекта исправить нельзя.
Один из способов это обходить я называл, делать некоторые внешние сущности (обёртки), с которыми и будет работать сама программа, а в них уже указывать аттрибуты не присущие самому объекту (но это не есть гуд, так как объект то всё равно тот же). Та же синхронизация статических переменных по потокам (ThreadStaticAttribute) является сущностью присущей не объекту, а программе, однако с успехом применяется для синхронизации по нескольким потокам переменных этого класса.

Так как аттрибуты применяются всё равно только в рантайме, то почему нельзя придумать механизм накручивания их именно в рантайме. То есть существует некая статическая сущность = объект класса, а мы неким образом накручиваем ей аттрибуты присущие этому (текущему) рантайму. Существующий способ предполагает, что если я использую один и тот же объект в нескольких программах (одна dll), то путём наворотов аттрибутов для одной программы и для другой в этот объект, я могу получить нечто, которое можно обозвать Attribute Hell по аналогии с ... А иначе для каждой программы придётся делать либо свою библиотеку, либо в каждой делать обёртки и аттрибуты наворачивать уже для них, хотя принципиально объект один и тот же.

С Уважением, Andir!

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

[skip]

AVK>>>Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.
A>>А почему собственно нет,
AVK>Потому что это противоречит базовым принципам ООП.

Нисколько. Мне объект всё что нужно сообщил, а остальное я волен решать сам. Читая например те же аттрибуты.

A>>я знаю об объекте всё что он мне может сообщить
AVK>А если он не хочет персонально тебе о чем то сообщать?

Так я этого в принципе и хотел бы. Одни аттрибуты видны одному типу, другие -> другому, некоторые -> всем. Но всё это описывалось бы немного другим способом, а не существующим. Существующий не обеспечивает гибкости для объектов в различных рантаймах.

A>>а далее я отбираю то, что мне нужно и иду курить с этим самым и всё.
AVK>А если то, что ты отбираешь сериализовывать нельзя?

Ещё быстрее иду курить, значит мне ничего сериализовывать и не придётся.

A>>То есть, чтобы он мне отдал только именно то, что мне нужно, но не больше и только мне. (под объектом подразумеваю объект класса).
AVK>Это намного сложнее чем разметить объект атрибутами.

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

С Уважением, Andir!

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

[skip]
A>>Неудачный пример, но сойдёт для демонстрации, в конечном итоге хотелось бы с помощью аттрибутов это и делать. Факт, что об этом должны знать дороги (или те кто ими управляет RoadManager), а не сам объект.

AVK>То есть дорога должна знать о всех типах автомобилей, которые по ней ездят? А если новый автомобиль появился — все дороги переделывать надо?
А нет не должна, пущай по обыкновенному асфальту гоняют 30 тонные Белазы ...

P.S. Пример неудачный.

С Уважением, Andir!

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

A>Мне не нравится способ описания аттрибутов как непременных сущностей объектов класса.

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

A>То есть при проектировании объекта (утрируя представим его как один класс), я не могу утверждать, что у этого объекта вот эти поля можно игнорировать кому-либо, а кому либо нельзя.

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

A>То есть, некоторый класс реализует всю функциональность объекта и допустим понадобилось его там сериализовать, что я делаю ... лезу в исходники объекта и проставляю нужным полям нужные аттрибуты ... понадобилось сделать ещё и некоторым статическим переменным синхронизацию по потокам, опять лезу в исходники.

Ты по моему чего то не понял. XmlSerializer не предназначен для полной сериализации объекта, не взирая на то что он собой представляет. Это сериализатор со строго контролируемым выходным форматом. Для сериализации всего подряд есть форматтеры.

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

Монстр, которого нельзя вытащить образуется только при неправильном проектировании. Атрибуты к этому не имеют ровно никакого отношения.

A>Так как аттрибуты применяются всё равно только в рантайме,

Кто тебе это сказал? Не только. Атрибуты могут использоваться и при инспектировании сборки, некоторые атрибуты используются компилятором.

A>то почему нельзя придумать механизм накручивания их именно в рантайме.

Потому что атрибуты для этого не предназначены. Для изменения свойств объектов в рантайме нужен другой механизм.

A>То есть существует некая статическая сущность = объект класса,

Так статическая сущность или все таки экземпляр класса?

A>а мы неким образом накручиваем ей аттрибуты присущие этому (текущему) рантайму.

Непонятно одно — зачем здесь атрибуты?

A>Существующий способ предполагает, что если я использую один и тот же объект в нескольких программах (одна dll), то путём наворотов аттрибутов для одной программы и для другой в этот объект, я могу получить нечто, которое можно обозвать Attribute Hell по аналогии с ...

Существующий способ вобще не предполагает использование атрибутов для изменяемых данных. Если используются атрибуты значит данные в рантайме менять не надо.

A>А иначе для каждой программы придётся делать либо свою библиотеку, либо в каждой делать обёртки и аттрибуты наворачивать уже для них, хотя принципиально объект один и тот же.

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

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

AVK>>Потому что это противоречит базовым принципам ООП.

A>Нисколько. Мне объект всё что нужно сообщил, а остальное я волен решать сам. Читая например те же аттрибуты.

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

AVK>>А если он не хочет персонально тебе о чем то сообщать?

AVK>>Это намного сложнее чем разметить объект атрибутами.

A>Вряд ли, скорее это немного более расширенные аттрибуты.

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

A>В рантайме через рефлекшон, очень легко реализуется,

Вот им и пользуйся. Зачем тебе атрибуты?

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

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

A>[skip]

AVK>>>>Если честно, то с точки зрения ООП непонятны твои желания извне вмешиваться в функционирование объекта.
A>>>А почему собственно нет,
AVK>>Потому что это противоречит базовым принципам ООП.

A>Нисколько. Мне объект всё что нужно сообщил, а остальное я волен решать сам. Читая например те же аттрибуты.

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

Object.PutYourStupidStateInfo( StateInfoBag )
Storage.Save( StateInfoBag )
or
Network.Send( StateInfoBag )


A>>>я знаю об объекте всё что он мне может сообщить
AVK>>А если он не хочет персонально тебе о чем то сообщать?

A>Так я этого в принципе и хотел бы. Одни аттрибуты видны одному типу, другие -> другому, некоторые -> всем. Но всё это описывалось бы немного другим способом, а не существующим. Существующий не обеспечивает гибкости для объектов в различных рантаймах.

A>>>а далее я отбираю то, что мне нужно и иду курить с этим самым и всё.
AVK>>А если то, что ты отбираешь сериализовывать нельзя?

A>Ещё быстрее иду курить, значит мне ничего сериализовывать и не придётся.

A>>>То есть, чтобы он мне отдал только именно то, что мне нужно, но не больше и только мне. (под объектом подразумеваю объект класса).
AVK>>Это намного сложнее чем разметить объект атрибутами.

A>Вряд ли, скорее это немного более расширенные аттрибуты. В рантайме через рефлекшон, очень легко реализуется, но никак не реализуется через "настоящие" аттрибуты описываемые в программе.

A>С Уважением, Andir!

A>

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

abstract class Транспорт
{
    //Возвращает количество полей, помеченных как "Колесо", или ещё что-нибудь
    КоличествоКолёс();
    ...
}
class Велосипед : Транспорт
{
    [Колесо]
    ПереднееКолесо;
    [Колесо]
    ЗаднееКолесо;

    [Рама]
    Звонок;
    [Рама]
    Сиденье;
}
class Машина : Транспорт
{
    [Колесо]
    ПравоеКолесо;
    [Колесо]
    ЛевоеКолесо;

    [Корпус]
    Фары;
    [Корпус]
    Двери;
}

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

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

А кто тебе сказал, что атрибуты это ОО-парадигма? Атрибуты это декларативное программирование. К ОО особого отношения не имеет, но замечательно с ним сочетается.

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

O>Использование аттрибутов с методами также даёт очень много.
O>

O>class Foo
O>{
O>    [Verb("File","Open")]
O>    void OpenFile(object sender, EventArgs e)
O>    {
O>        ...
O>    }
O>}
O>

O>Некоторый код может пробежаться по методам и, используя аттрибуты, создать элементы меню и сразу привязать соответствующие делегаты.
O>Здесь важно, что меню и описание Verb — локальны и не нужно носиться по всему коду при изменении Verbs. Хотя с culture здесь придётся повозиться.

О! AVK, видишь? Примерно то о чем я тебе говорю. Только эти "object sender, EventArgs e" долой. И общий механизм экспорта из сервиса прикрутить. Ни и потом наваять возможность редизайна меню и тулбаров.

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

AVK>Твое желание менять атрибуты в рантайме равносильно желанию в рантайме добавить поле или метод.

А что? Было бы очень удобно. Ну по крайней мере помечтать можно.

AVK>Вместо этого можно, к примеру, применить статические эвенты, размеченые теми же атрибутами.

Да вообще-то статические свойства здесь в самый раз. Лезишь и узнаешь рантаймную информацию.

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

AVK>То есть дорога должна знать о всех типах автомобилей, которые по ней ездят? А если новый автомобиль появился — все дороги переделывать надо?

Пометить дорогу как деприкейтед, а рядом проложить новую.

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

AVK>>Твое желание менять атрибуты в рантайме равносильно желанию в рантайме добавить поле или метод.

VD>А что? Было бы очень удобно. Ну по крайней мере помечтать можно.

Ну так можно. Тока гиморойно и медленно. Не напрямую добавить конечно, а отнаследоваться в рантайме.

AVK>>Вместо этого можно, к примеру, применить статические эвенты, размеченые теми же атрибутами.

VD>Да вообще-то статические свойства здесь в самый раз. Лезишь и узнаешь рантаймную информацию.

Можно и свойства, на делегатах просто можно реализовать более навороченую и гибкую логику.

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


VD>О! AVK, видишь? Примерно то о чем я тебе говорю.

Так я вроде бы на счет этого и не возражал.

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

AVK>Так я вроде бы на счет этого и не возражал.

Ты их че-то суешь в хмл.

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

AVK>Ну так можно. Тока гиморойно и медленно. Не напрямую добавить конечно, а отнаследоваться в рантайме.

Во-во. А хотель бы шоб просто добавить... и все пучечком.

AVK>Можно и свойства, на делегатах просто можно реализовать более навороченую и гибкую логику.

Да вроде все тоже самое.

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

AVK>>Ну так можно. Тока гиморойно и медленно. Не напрямую добавить конечно, а отнаследоваться в рантайме.

VD>Во-во. А хотель бы шоб просто добавить... и все пучечком.

Это приведет к таким логическим глюкам что мама дорогая.

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

AVK>>Так я вроде бы на счет этого и не возражал.

VD>Ты их че-то суешь в хмл.

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