Цитата:
Обманка-то работает. Разговор о том, чтобы все-таки была воэможность включать\отключать методы (флаг ст.обработки).
А дальше - больше. Есть класс:

Class НовыйКласс = НовыйКласс@MD: ТаблицаЗначений
{
};
 

Модуль класса:

Перем Сам;
//_____________________________________________________________________________
Функция Сам(Конт) Возврат Конт КонецФункции
//_____________________________________________________________________________
Процедура Конструктор()
	Сам = Сам(Контекст);
КонецПроцедуры //Конструктор
//_____________________________________________________________________________
Функция _ПриЧтенииСвойства(ИмяАтрибута)
	Если ИмяАтрибута = "Сам"
	Тогда
	    Возврат Сам;
	ИначеЕсли ИмяАтрибута = "НомерКолонки"
	Тогда
	    Возврат Сам.НомерКолонки;
	КонецЕсли;
КонецФункции //_ПриЧтенииСвойства
//_____________________________________________________________________________
Процедура _ПриЗаписиСвойства(ИмяАтрибута,Значение)

КонецПроцедуры //_ПриЗаписиСвойства 

И есть обработка

Перем ТЗ;
//*******************************************
Процедура Сформировать()
	ТЗ.НоваяКолонка();
	Сообщить(ТЗ.НомерКолонки);
КонецПроцедуры
//_____________________________________________________________________________
Процедура ПриОткрытии() //предопределенная
	ТЗ = СоздатьОбъект("НовыйКласс");
КонецПроцедуры //ПриОткрытии
 

1С падает. Интересно, а здесь-то в чем дело?

Arta писал(а) 25. Мая 2007 :: 15:44:

Да, читал я это. А теперь попробуй извне получить/установить значение твоей Перем Конт. А лучше в моем примере убери из ф-ции _ПриЧтенииСвойства все "Если"

Цитата:
Ну нельзя, так нельзя.
А все-таки методы _ПриЗаписиСвойства и _ПриЧтенииСвойства должны работать четко и применяться только к ДИНАМИЧЕСКИМ атрибутам без дополнительных уловок и не трогать переменные контекста. Так-же четко, как ПриПолучении_ХХХ и ПриЗаписи_ХХХ.
Тема динамических реквизитов на этом форуме еще не обсуждалась, так что время для раздумий еще есть.

Подниму тему.

Итак, сейчас, согласно history.txt, для добавления в класс динамического атрибута, это надо сделать явно, с помощью метода ДобавитьДинамическоеСвойство().
Причем вызов этого метода не рекомендуется делать на клиенте.

У меня три вопроса.
1. Какое же это тогда будет динамическое свойство, если клиенту не рекомендуется добавлять эти самые свойства?
2. В багзилле, [Bug 3606] есть сноска, что это сделано "для нормального ООП". Нельзя ли развернуть это утверждение поподробнее? Что было ненормального в предыдущей реализации и почему предложенная реализация более нормальная?
3. Зачем делать обратно несовместимые изменения в рамках minor версий?
Да еще и без возможности сначала изменить клиентский код, и только потом - версию компоненты...

P.S. Если я где-то пропустил обсуждение данного вопроса - ткните меня носом, плиз.

fez писал(а) 12. Августа 2008 :: 14:41:


Смешно. Сам же и создавал. Как теперь выяснилось, на свою голову http://www.1cpp.ru/forum/YaBB.pl?num=1204205191/0

Но вопрос о глубоком смысле несовместимых изменений в рамках minor-версий остался.

kms писал(а) 12. Августа 2008 :: 17:51:

Я ждал примерно такой реакции. И даже уже посыпал голову пеплом. Если кто не заметил - могу сделать это еще раз.

Вопрос не в этом. Для чего вообще у нас ЧЕТЫРЕ разряда в номере версии? Чтобы как минимум один разряд вообще никогда не использовать?

Я не против обратнонесовместимых изменений. Мне просто непонятно, зачем это делать в рамках минорной версии? Чтобы пользователю, который "редко встречается", бяку подложить? Чтобы "чаще встречался"?

kms писал(а) 12. Августа 2008 :: 17:51:

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