Uzhast писал(а) 24. Сентября 2007 :: 06:32:

Этот метод и его поведение для совместимости соответствуют штатному от ТаблицаЗначений.ВыбратьСтроку, там нет параметров по умолчанию вообще !

Да, это баг, но мелкий.
Поправлю, это не проблема.
ЗЫ у родного метода ИТЗ.Показать этого недостатка нет

С тем кодом, на который еще жаловались, уже также разобрались

Uzhast писал(а) 24. Сентября 2007 :: 06:32:

-1
Лукавишь, ты не все варианты показал.
Стандартное поведение 1С очень и очень далеко от идеала и очень непонятно.
Я для проверки написал пару тестов.
1. в Глобальнике определил метод

Функция глШтатныеПараметрыПоУмолчанию_Сложение(А = 2, Б = 3) Экспорт
	Возврат А + Б;
КонецФункции
 

Вот его тест

Процедура Тест_ГлобальнаяФункция_ШтатныеПараметрыПоУмолчанию() Экспорт
	Сам=Сам();

	Значение = глШтатныеПараметрыПоУмолчанию_Сложение(4);
	Сам.ПроверитьРавенство(Значение, 7); // 1

	Значение = глШтатныеПараметрыПоУмолчанию_Сложение(,4);
	Сам.ПроверитьРавенство(Значение, 6); // 2

	Значение = глШтатныеПараметрыПоУмолчанию_Сложение(4,);

	Сам.ПропуститьТест(0, "Штатные параметры по умолчанию неверно работают !!"+РазделительСтрок+
		"       Например, глоб. функция глШтатныеПараметрыПоУмолчанию_Сложение(4,) должна вернуть 7, "+РазделительСтрок+
		"       но 1С возвращает 4 :("+РазделительСтрок);
	// а вот и БАГ 1С - система возвращает 4, а нужно 7
	Сам.ПроверитьРавенство(Значение, 7); // 3
КонецПроцедуры
 

Т.е. получается, что 1С использует параметры по умолчанию для тех параметров, которые пропущены в начале списка параметров - 2 проверка теста
но не использует их для тех параметров, которые находятся в конце списка параметров - 3 проверка теста.

ИМХО очередное неявное и корявое поведение 1С , на которое никак нельзя полагаться

2. 1С++ этого недостатка лишен
Полностью аналогичный тест для метода класса прекрасно проходит.
Кстати, в 1С++ проходит как ХитроеСложение (3), так и ХитроеСложение (3, )

JohnyDeath писал(а) 24. Сентября 2007 :: 11:58:

Да, перепутал со СпискомЗначений.
Значит, просто баг
Исправлю.

А что скажете по основной теме ветке, т.е. по неоднозначному поведению 1С?

fez писал(а) 24. Сентября 2007 :: 13:07:

глШтатныеПараметрыПоУмолчанию_Сложение(,4);
А здесь - первый параметр как бы работает по умолчанию.
и где логика?

trad писал(а) 24. Сентября 2007 :: 13:13:


Здесь параметр по умолчанию указан перед параметром, в который передается значение. Поскольку это единственный способ - очевидно, что он работает так, как ожидалось.
Тогда как параметр по умолчанию ПОСЛЕ параметра, в который значение передано, можно описать двумя способами. С запятой и без. В 1С решили, что вариант с запятой не имеет права на тщательное тестирование. Поэтому-то он работает так, как работает.

Мне даже интересно. Если определить вот такую функцию:

Функция МножественноеСложение(_1 = 1, _2 = 2, _3 = 4, _4=8, _5 = 16)
  Возврат _1+_2+_3+_4+_5;
КонецФункции 

И вызвать ее

Значение = МножественноеСложение(0,,);
То в Значение окажется 24?

Отсюда следует вывод: не ходите дети в Африку гулять.

Поэтому, мне кажется, что в 1С++ лучше сделать также, как в 1С. (Помните, винду сделали совместимой с СимСити?) Потому что иначе один и тот же код будет работать по-разному (что и наблюдалось раньше, стало чуть получше).

Или оставить так, как есть. Как ни сделай - все равно будет плохо.  

Не, я лично против подобной совместимости методов 1С++ с 1С.

Если у метода нет параметров по-умолчанию и если разработчик хочет передать в метод пустое/неопределенное значение, пусть делает это явно, Тест("", "") .

Если параметры по умолчанию есть, при пропущенном параметре должны использоваться именно указанные параметры по умолчанию, а не так, как выберет 1С - нафига я должен помнить, что в разных случаях могут быть разные значения!

artbear писал(а) 24. Сентября 2007 :: 13:51:


Ну почему непонятно. Как раз понятно. Во втором параметре - пустое значение. Третий параметр берется из умолчания. 4+5 = 9

artbear писал(а) 24. Сентября 2007 :: 13:54:

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

Артур, ну мы опять возвращаемся к вопросу: "как будет лучше: исправить глюк, или оставить для совместимости?"

И, повторюсь, правильный ответ уже придуман.
Цитата:

fez писал(а) 24. Сентября 2007 :: 14:09:

1) Я лично не знаю, как сделать вот этот режим совместимости с 1С
Т.е. непонятно, как отличить передачу пустого значения от параметра по умолчанию

2) это не правильный ответ.
Настройкой нельзя делать, только полной совместимостью с 1С.
Если делать настройку, кто-то ее может отключить (я ), сделать класс, который работает правильно при другой настройке, и неправильно с 1С-совместимой настройкой, и выложить в общий доступ. И будет баг.

Давно статью читал, умные вещи говорит, согласен.
НО не в данном случае - см. выше про незнание.

artbear писал(а) 24. Сентября 2007 :: 14:26:

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

sedmin писал(а) 24. Сентября 2007 :: 15:04:

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

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

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

Uzhast писал(а) 24. Сентября 2007 :: 15:12:

Кстати, про тесты. Ощущение того, что "на каждый чих тест есть. А то и два." - оно, сцуко, усыпляет.

Не далее, как на прошлой неделе отловил баг.
Мне казалось, я в этом куске все, что можно протестировал. Года три или четыре любое изменение программы в этом месте сопровождалось тестами. Хрен на блюде.
Так обидно было. Уже и не помню, когда последний раз ломал существующий функционал в проводках. Только если что-то новенькое бухи выкапывали. А тут на тебе.

И кстати, вот эта хрень с параметрами по умолчанию, это как раз тот самый тонкий момент, который может быть закопан где-то ОЧЕНЬ глубоко. И даже на покрытом тестами продукте может вылезти БАГ. Просто потому что никому в голову не придет тестировать значения по умолчанию.

sedmin писал(а) 24. Сентября 2007 :: 19:41:

Не совсем верно - я лично сделал настройки только для кода, который меняет поведение 1С и может сказаться на работе системы в целом - например, ТурбоБЛ или Перехватчик ставят свои перехваты на общесистемные методы и соответственно могут повлиять на работу любых других методов!

По теме
fez писал(а) 24. Сентября 2007 :: 15:30:

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

Я лично за
1) общепринятое поведение, не как у 1С
2) поведение должно соответствовать документации.

artbear писал(а) 25. Сентября 2007 :: 04:46:

Ну а почему бы тогда перехваты не накладывать вызовом какого-нибудь метода? Все равно же код надо писать на проверку перехватов?

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

Переносить ли изменения по параметрам по умолчанию в ветку 2.0.3?

У меня принципиальных возражений нет, надо только прогнать тесты.
Какое ваше мнение? Будем голосовать?

Uzhast писал(а) 25. Сентября 2007 :: 06:37:

Это огромнейший объем работы.
Вот вкратце.
Цитата:

artbear писал(а) 25. Сентября 2007 :: 07:05:


artbear писал(а) 25. Сентября 2007 :: 07:10:


Ну, вроде тогда все нормально. Меня просто насторожило изменение в поведении ИндексированнаяТаблица.ВыбратьСтроку () и твоя реакцию на подобную же проблему у кого-то еще (блин, где ж это было, никак найти не могу...). Раз это были просто баги, то никаких претензий тогда нет.

sedmin писал(а) 25. Сентября 2007 :: 07:38:

1. Long - не знаю, автор в тестах использует вызов с дефолтным значением, я сделал как у него написано

2. Так в консерватории поправлено
И теперь, если у метода не задана дефолтная функция, при вызове с дефолтным значение будет выдаваться ошибка "не хватает параметров".

3. А ошибка была в ТП - SetTextMargins - Arta писал об этом

spock писал(а) 25. Сентября 2007 :: 08:06:

щас сам заценю

artbear писал(а) 25. Сентября 2007 :: 08:14:

туплю, это же из темы "Баг с дефолтными параметрами".

sedmin писал(а) 25. Сентября 2007 :: 05:49:

Будем исправлять или все-таки нет?
В 2.5, как многие уже убедились, все ок!