to KMS - целиком поддерживаю.

Кроме того - а как этой ИТ пользоваться, и главное зачем? 
Вот не вижу необходимости, учитывая что любые данные могу получить с SQL запросом...

А еще раньше помню ваще книг не было. Читали чужие сорцы.
Декомпилировали и читали. Как же еще )

Kostya писал(а) 22. Января 2007 :: 19:56:

У меня был турбодебаггер.
А систему команд К1801ВМ1 я знал наизусть и писал в машинных кодах.
Мне как-то никто сразу не сказал, что так не принято.

Короче я понял, Костя, ты по жизни юниксоид.
Но если ты не заметил, популяризацией ты _уже_ активно занимаешься

Костя, знаешь, я не буду использовать твои классы, так же, как не использую классы Артура и прочие. Также, как не использую классы из FuncTest'а, хотя я же в них участвовал. И знаешь в чем причина?

Есть такой мужик, Фредерик Брукс. Он написал книжку "Мифический человеко-месяц". В ней много вещей, с которыми я согласен и не согласен. Но есть у него такой момент: он оценивает стоимость компонентов (тогда классов не было).

Так вот, стоимость их соотносится так: начальная заготовка оценится в единицу, тогда отлаженный класс, который соответствует спецификациям (вычищена начинка) стоит в три раза дороже. А класс, который уже отработан во взаимодействии с другими классами (у которого вычищена не только начинка, но и интерфейсы, он выполняет все, для чего он предназначен) стоит еще в три раза дороже.

То есть отлаженный и готовый к интеграции класс стоит в 9 (девять!) раз дороже, чем исходный. Я смотрю на твои классы (впрочем, как и на классы Артура), и понимаю, что для полноценного использования мне надо затратить от двух до девяти раз больше усилий, чем вложил ты (то есть то, что я получаю условно-бесплатно).

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

Но, естественно, это оценка для моего использования твоих классов. Так как я представляю именно высокие требования к классам. Наверное, найдутся люди, кому твои классы подойдут. Но если я за них буду отвечать перед 300 клиентами (1500 рабочих мест), то я лучше напишу свои такие же классы. И напишу их через тестирование для того, чтобы быть в них уверенным.

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

Могу привести еще один пример - внешняя компонента работы со сканером. Нам тоже захотелось халявы, мы нашли такую компоненту и встроили к себе. В результате оказалось, что она не работает со сканером на принтере HP-1200. Автор, конечно, поковырялся-поковырялся, да и сказал, что не знает в чем дело. А что нам ответить клиенту? Вот тебе и халява. И даже если бы у нее бы у нее были открытые коды, думаешь нам было бы намного легче?

Я также не использую ИндексированнуюТаблицу, хотя считаю, что ее стоимость составляет 80-90% от желаемой. Не использую по простой причине, что для меня ее функционал не востребован, просто другие задачи. В одном месте попытался ее применить, но в результате рефакторинга ее использование выродилось до простой ТаблицыЗначений.  Пришлось выборосить.

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

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

Да что там ИндексированнаяТаблица, если стандартная 1С-овская ТаблицаЗначений преподносит сюрпризы при сортировках и свертках. Ну не верю я, что ИндексированнаяТаблица лучше протестирована, чем ТаблицаЗначений!

Вот я могу, например, опубликовать (после согласованя со своими) класс ХранилищеОбъектов, который позволяет хранить в базе данных 1С произвольные объекты. Он по уровню проработки близок к ИндексированнойТаблице. Знаешь сколько времени ушло на то, чтобы проработать хранение пустых списков и строк различной длины. Знаешь, сколько времени вычищались интерфейсы под разные нужды? Так до сих пор подправляем его, не смотря на то, что писался он через тестирование. И до сих пор в нем есть ограничения, о которых я знаю.

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

(sedmin) Вообще то есть классы которыми можно пользоваться не заботясь об их рефаторинге, возьмем к примеру класс "Общие.Форма.Привязка.ert" - пользуюсь им полгода и даже не заглядывал как он написан - работает вроде как безнареканий - так зачем мне свое писать если добрый человек подобное уже сделал
Частью классов можно пользоваться как примерами для создания своих собственных - никто же не мещает сделать лучше и выложить свое.

Kostya писал(а) 22. Января 2007 :: 22:02:

Тестов не будет. Просто скажу, что ситуации возникают, когда элементы справочника имеют одинаковое наименование.

И если ты знаешь, что лежит в колонке таблицы, то ты напишешь разные варианты кода, который правильно выполняет сортировку/свертку, а если не знаешь - то хрен.

sedmin писал(а) 22. Января 2007 :: 22:11:



Попытка найти искомое:

    ТЗ=СоздатьОбъект("ТаблицаЗначений");
	ТЗ.НоваяКолонка("ЭлементСправочника");
	ТЗ.НоваяКолонка("ЧисловоеЗначение");

	Спр=СоздатьОбъект("Справочник.Тестовый");
	Спр.ВыбратьЭлементы();
	Пока Спр.ПолучитьЭлемент()=1 Цикл
		Сообщить("["+Спр.ПолныйКод()+"::"+Спр.ТекущийЭлемент()+"]");
		ТЗ.НоваяСтрока();
		ТЗ.ЭлементСправочника=Спр.ТекущийЭлемент();
		ТЗ.ЧисловоеЗначение=1;
	КонецЦикла;

	Сообщить("строк="+ТЗ.КоличествоСтрок());
	ТЗ.ВыбратьСтроку();
	ТЗ.Свернуть("ЭлементСправочника","ЧисловоеЗначение");
	Сообщить("строк="+ТЗ.КоличествоСтрок());
    ТЗ.ВыбратьСтроку();

КонецПроцедуры

 

результат исполнения.

[3::второй]
[5::второй]
[1::первый]
[2::первый]
[4::третий]
строк=5
строк=5
 

Визуальная проверка на ВыбратьСтроку() обнаруживает две идентичные ТЗ.
То есть ничего не свернулось, даже несмотря на одиннаковые названия Наименований.

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


ИМХО моя позиция и позиция Кости во многом близки