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

Эта ветка напоминает мне старый выпуск Ералаша, где мальчуган объясняет приятелю почему не пересекаются параллельные линии.

artbear
Цитата:

1. Никто и не отвергает существующих способов подключения классов. Конечно, для внешней обработки удобнее на лету подключить нужные классы. Более того, если нужны классы, специфичные для конкретного прикладного решения, их и не следует сделать доступными всем базам.
Непонятно, только, почему не ты хочешь "складывать файлы в каталог"? Одно другому, ведь, не мешает.

2. Цитата:

Да уж, проблема... 

Цитата:

Ну и нормально, чего зря голову-то ломать.
Это, кстати, следствие, вовсе, не моего предложения.

artbear писал(а) 02. Марта 2007 :: 03:54:

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

Понимаешь, ИМХО в этом случае станет довольно сложно следить за классами.
Т.к. будет возможно на лету заменять класс, у которого, возможно, есть уже созданные экземпляры.
А это может привести к большой неразберихе при одновременной работе нескольких пользователей.

Хотя, возможно, все-таки нужно добавить спец.метод типа ДобавитьКлассыСЗаменойСуществующих

Так... путаница продолжается.

artbear
Цитата:


Что за прм-файл? Дефцлс? Если да, то классы, описаные в нем, подключаются автоматически при старте. Т.о., конфликт, [довольно редкий?] может возникнуть только при запуске внешней обработки. Генерация исключения - нормальное решение. Но, если не лень, можно дать приоритет классу, загружаемому динамически. На мой взгляд, это не принципиально.

зы: Еще раз призываю взглянуть на вопрос с другой стороны. Само понятие "подключение класса" морально устарело. Оно избыточно и не является самоцелью. На сегодняшний день,
палатформе достаточно иметь класс в своем распоряжении только в момент создания его экземпляра.

Ничего не понимаю, чего вы тут трете. На лету - не на лету, из папки - не из папки, через ПРМ - без ПРМ.

Вам не кажется, что надо реализовать атомарную операцию ЗагрузитьКлассИзФайла("ИмяФайла")? И на основе ее дальше городить огород.

Вот пример файла класса:

//#класс ТестовыйСлучай: ВыполняемыйМодуль

//#void AssertEquals(Неопределенный Значение1, Неопределенный Значение2, Строка стрСообщение="");
Процедура AssertEquals(Значение1, Значение2, стрСообщение="") Экспорт
	  Если Значение1 = Значение2 Тогда Возврат; КонецЕсли;
	  Если ПустоеЗначение(стрСообщение)=1 Тогда
		    стрИсключение="<"+Значение1+"> не равно <"+Значение2+">, а хотели, чтоб было равно.";
	  Иначе
		    стрИсключение=стрСообщение+": <"+Значение1+"> не равно <"+Значение2+">.";
	  КонецЕсли;
	  Сам()._ВыброситьИскл(стрИсключение);
КонецПроцедуры
 

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

Arta
+100 

sedmin
Лично я тру о том, чтобы вообще исключить из прикладного решения информацию о файлах классов. В МД и так черт ногу сломит, а ты еще предлагаешь захардкодить имена файлов!

Цитата:

Я специально не написал дефцлс.прм, чтобы вы не запутались, а вы все-таки спутали
Речь идет именно о динамически подключаемом прм-файле через мой новый метод.
Народ, хоть кто-нибудь посмотрел мой новый метод, а ?