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

VD>А узнать эти значения проще простого. Например, для первого параметра метода Test класса Class1:
VD>

VD>typeof(Class1).GetMethod("Test").GetParameters()[0].DefaultValue
VD>

M>Какой-никакой вариант. Хотя, тоже капризный (нужно правильно задать индекс параметра), да и тормозной.

Ну, это если на рантайме делать. Если же встраивать поддержку в компилятор, то вместо этого наварота будет константа. Попробуй сам сделать сбору на ВБ и из него же ее использовать (не задавая значения параметра). Потом погляди Анакриной и увидишь что там константа.

Так что это всего лишь блаж МС. Кму-то там не нравятся бефолтные параметры.

Может быть они мешали построению сериализации в код. Ведь если есть перегружаенные методы и дефолтные параметры не равен час получить баку. Правда С++ это дело ловит влет. Так что...

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

VD>А ты видел как обычно реализовывются методы имеющие большое количество перегрузок? Уж лучше бы были дефолтные параметры.

M>Хм, чем лучше?

Тем, что не нужно писать гуру никому не нужного кода. Ты погляди классы с большим количеством перегруженных методов. Там то и дело вызов более длинного/короткого метода (чтобы код не дублировать). И получается что 90% перегруженных методов пустышки.

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

Рек>1. Тем, что интерфейс содержит магические числа (дефортные значения параметров).
Рек>Врядли это хороший стиль определения интерфейса.

Ну, давай так. Это приимущество! Так как это позволяет видеть умолчальные значения параметров прямо в интерфейсе!

Короче, это удобная возможность. И ситилю она отношение тоже не имеет.

Рек>2. Если надо задать в перемешку дефолтные и не дефолтные значения,
Рек>то придётся выучить наизусть эти магические числа и программа будет ими пестреть,
Рек>этими NULLами, 0ями и -1цами, ... И т.д. и т.п.

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

Рек>3. Эффективность срадает(см. ниже)

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

Рек>>Кроме того они снижают эффективность кода: часто параметр просто не нужен —
Рек>>но он гоняется (в том числе по сети!) из-за того, что программист поленился
Рек>>написать пяток лишних методов.

Глупость какя-то. Кто-то что-то поленился, а мы будем пенять на некую возможноть. Это всего лишь возможность. Одна "из". Ну, и уж точно не нужно пенять на сеть. Ремоутинг в дотнете дико избыточен. Если бы кто-то заботился об эффективности, то стоило бы направить свои усилия в более подходящее русло.

VD>А ты видел как обычно реализовывются методы имеющие большое количество перегрузок? Уж лучше бы были дефолтные параметры.

Рек>Если делo совсем швах, и колво перегрузок (комбинаций параметров) очень велико,
Рек>то можно попробовать использовать передачу параметров в спец структуре.
Рек>Заполняешь в стукруре только нужные поля (остальные остаются дефлотными)
Рек>и переадёшь это хозяйство методу. (пример — ProcessStartInfo).

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

VD>Ноль. Параметр просто будет иметь некое начальное значение. Иначе проще сделать перегруженную функцию.

Рек>Вот я про это "иначе" и говорю.

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

Отсуствие возможности задавать дефолтные значения параметрам — это дурь. Разумных аргументов я пока, что для этого не вижу.

VD>Тем, что не нужно писать гуру никому не нужного кода. Ты погляди классы с большим количеством перегруженных методов. Там то и дело вызов более длинного/короткого метода (чтобы код не дублировать). И получается что 90% перегруженных методов пустышки.

Ага, значит лучше в плане удобства кодирования. И то только для поставщика библиотеки — клиентам это по барабану.

Но хуже в других аспектах, явного преимущества нет.

VD> Если же встраивать поддержку в компилятор, то вместо этого наварота будет константа.

<skip>

VD>Так что это всего лишь блаж МС. Кму-то там не нравятся бефолтные параметры.

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

Рек>>3. Эффективность срадает(см. ниже)

VD>Полная ерунда. Еще раз говорю. Погляди как сейчас в том же МС делают эти тысячи перегрузок. Попросту делают пустышки вызывая один-два реальных метода. А ведь при этом делаются лишние вызовы. Так что как раз дефолтные параметры позволили бы делать более эффектиный код. А главное, более короткий.

Параметры по умолчанию тоже не бесплатно нам даны.

VD>Отсуствие возможности задавать дефолтные значения параметрам — это дурь. Разумных аргументов я пока, что для этого не вижу.

Те же аргументы, что и против констант — ухудшается поддержка версионности сборок. Для "подхватывания" изменившегося параметра по умолчанию нужно перекомпилировать зависимую сборку.

VD>Тем, что не нужно писать гуру никому не нужного кода. Ты погляди классы с большим количеством перегруженных методов. Там то и дело вызов более длинного/короткого метода (чтобы код не дублировать). И получается что 90% перегруженных методов пустышки.

Ага, значит лучше в плане удобства кодирования. И то только для поставщика библиотеки — клиентам это по барабану.

Но хуже в других аспектах, явного преимущества нет.

VD> Если же встраивать поддержку в компилятор, то вместо этого наварота будет константа.

<skip>

VD>Так что это всего лишь блаж МС. Кму-то там не нравятся бефолтные параметры.

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

Рек>>3. Эффективность срадает(см. ниже)

VD>Полная ерунда. Еще раз говорю. Погляди как сейчас в том же МС делают эти тысячи перегрузок. Попросту делают пустышки вызывая один-два реальных метода. А ведь при этом делаются лишние вызовы. Так что как раз дефолтные параметры позволили бы делать более эффектиный код. А главное, более короткий.

Параметры по умолчанию тоже не бесплатно нам даны.

VD>Отсуствие возможности задавать дефолтные значения параметрам — это дурь. Разумных аргументов я пока, что для этого не вижу.

Те же аргументы, что и против констант — ухудшается поддержка версионности сборок. Для "подхватывания" изменившегося параметра по умолчанию нужно перекомпилировать зависимую сборку.

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

VD>Полная ерунда. Еще раз говорю. Погляди как сейчас в том же МС делают эти тысячи перегрузок. Попросту делают пустышки вызывая один-два реальных метода. А ведь при этом делаются лишние вызовы. Так что как раз дефолтные параметры позволили бы делать более эффектиный код. А главное, более короткий.

M>Параметры по умолчанию тоже не бесплатно нам даны.

Что значит бесплатны? Это средство избавить человека от многократного введения одних и тех же параметров. И другого программиста от создания десятков перегруженных методов бесполезно вызывающих друг-друга.

VD>Отсуствие возможности задавать дефолтные значения параметрам — это дурь. Разумных аргументов я пока, что для этого не вижу.

M>Те же аргументы, что и против констант — ухудшается поддержка версионности сборок. Для "подхватывания" изменившегося параметра по умолчанию нужно перекомпилировать зависимую сборку.

Честно говря я не очень то понимаю аргументы проив констант. Да и аргументов не вижу. Версии обеспечиваются на уровне сборок. И перекомпиляция будет нужна при любом изменении публичного интерфейса.

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

VD>Тем, что не нужно писать гуру никому не нужного кода. Ты погляди классы с большим количеством перегруженных методов. Там то и дело вызов более длинного/короткого метода (чтобы код не дублировать). И получается что 90% перегруженных методов пустышки.

M>Ага, значит лучше в плане удобства кодирования.

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

M>И то только для поставщика библиотеки — клиентам это по барабану.

Ну, это уже демагогия.

M>Но хуже в других аспектах, явного преимущества нет.

Явные преимущества перед чем? Перед отсуствием возможности?

Это удобно во многих случаях. И вроде бы ничему не мешает. Ты вот сначала дакажи что дефолтные параметры чему нибудь мешают. А то кроме частного мнения никаких разумных аргументов небыло.

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

VD> Если же встраивать поддержку в компилятор, то вместо этого наварота будет константа.

<skip>

VD>Так что это всего лишь блаж МС. Кму-то там не нравятся бефолтные параметры.

M>Ну, уже приводились аргументы против констант.

Извени не видел.

M>Совместимость между версиями не поддерживается. Так что не блажь.

Как это? А если я параметр добавлю или удалю в методе, то совместимость будет поддерживаться? Ты хоть пример какой приведи...

M>Ну, уже приводились аргументы против констант.

VD>Извени не видел.

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

То же самое и с умолчаниями. А не то же самое — с static readonly fields, например.

P.S. Они там всё время прокручивают варианты с зависимыми сборками. Стремятся, чтобы если зависимость есть — пусть она будет явной и видимой. Возьми, например, ключевое слово new при скрытии методов.

M>И то только для поставщика библиотеки — клиентам это по барабану.

VD>Ну, это уже демагогия.

Ну, и это уже демагогия.

VD>Это удобно во многих случаях. И вроде бы ничему не мешает. Ты вот сначала дакажи что дефолтные параметры чему нибудь мешают. А то кроме частного мнения никаких разумных аргументов небыло.

Были.

Вообще, дурной спор. У параметров по умолчанию есть свои плюсы и минусы, и они уже достаточно обмусолены.

И в рамках концепции C# разработчики, а также ECMA и ISO сочли их ненужными. Есть исходники компилятора C#, даже не один вариант. Каждый может параметры по умолчанию реализовать.

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

M>И то только для поставщика библиотеки — клиентам это по барабану.

VD>Ну, это уже демагогия.

M>Ну, и это уже демагогия.

На демагогию принципяльно отвечать не будут. Не нужно додумывать за меня и уж темболее строить какие-то предположения на этом.

VD>Это удобно во многих случаях. И вроде бы ничему не мешает. Ты вот сначала дакажи что дефолтные параметры чему нибудь мешают. А то кроме частного мнения никаких разумных аргументов небыло.

M>Были.

Небло. Дальше что? Били покажи.

M>Вообще, дурной спор. У параметров по умолчанию есть свои плюсы и минусы, и они уже достаточно обмусолены.

Так не спорь. А споришь приводи аргументы.

M>И в рамках концепции C# разработчики, а также ECMA и ISO сочли их ненужными. Есть исходники компилятора C#, даже не один вариант. Каждый может параметры по умолчанию реализовать.

Я незнаю что ты там про ISO говоришь. Но ECMA привняла то что еей подсунул МС. И он отличается от рельного дотнета. В дотнете есть тот же ВБ в котором дефолтные параметры прекрасно работают. И никаких пролблем нет. Проблема только в том, что их нет в шарпе и МС++, а ведь дефолтные параметры для С++ как раз действительно входят в стандарты ANSI и ISO. Так что из-за этой глупости МС++ никогда не сможет быть совместимым со стандартом С++.

PS

Еще раз повторюсь. Разумных аргументов против дефолтных параетров я не услышал.

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

M>Зависимая сборка без перекомпиляции не "чувствует", что значения константы изменилось.

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

M>То же самое и с умолчаниями. А не то же самое — с static readonly fields, например.

Ты вдумайся что ты сравниваешь! Ты сравниваешь переменные с константами. То что переменные могу изменяться это не приемущетсво и не недостаток. Это данность. Так же как и то, что константы имеют неизменные значения.

M>P.S. Они там всё время прокручивают варианты с зависимыми сборками. Стремятся, чтобы если зависимость есть — пусть она будет явной и видимой. Возьми, например, ключевое слово new при скрытии методов.

Если публичный интерфейс сбокри изменился, то сборка зависящая от нее нужнается в перекомпиляции. Константы и описание методов явлются частью публичного интерфеса. Как в прочем и декларация любых (нет только static readonly) свойств и полей. К примеру, при изменении типа поля ты обязан будет перекомпилировать сборку. Если же изменяется только занчение (которое, как известно, для readonly-полей заполняется исключительно в конструкторе), то и публичный интерфейс не изменяется.

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

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

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

M>Зависимая сборка без перекомпиляции не "чувствует", что значения константы изменилось.

VD>Зависимая сборка должна основывать свое мнение о версиях исключительно на версии сборки от которой она зависит. И чувствовать ничего не должна.

Вопрос не в мнении сборки о версиях. Вопрос в мнении сборки о значениях константы.

M>P.S. Они там всё время прокручивают варианты с зависимыми сборками. Стремятся, чтобы если зависимость есть — пусть она будет явной и видимой. Возьми, например, ключевое слово new при скрытии методов.

VD>Если публичный интерфейс сбокри изменился, то сборка зависящая от нее нужнается в перекомпиляции.

Да. Только при изменении синатуры мы явно увидим эту нужду в перекомпиляции.

Это похоже на ситуацию с несовмесимостью разъёмов. Ты не вставишь USB-проводок в клавиатурный разъём. Или антенный кабель в электрическую розетку. Это сделано специально, чтобы несовместимость интерфейсов была как можно более явной, физической.

Так же и с сигнатурами методов. Если сигнатура у метода изменилась — дотнет не даст вызвать этот метод. То есть здесь он отсекает и обеспечивает несовместимость по интерфейсу. Старый штепсель не лезет в новую розетку.

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

VD>В общем, попробуй придумать более разумные аргументы против значений по умолчанию для параметров.

Других аргументов вроде не существует.

VD>Это удобно во многих случаях. И вроде бы ничему не мешает. Ты вот сначала дакажи что дефолтные параметры чему нибудь мешают. А то кроме частного мнения никаких разумных аргументов небыло.

M>Были.

VD>Небло. Дальше что? Били покажи.

Никого ещё не били

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


M>И в рамках концепции C# разработчики, а также ECMA и ISO сочли их ненужными. Есть исходники компилятора C#, даже не один вариант. Каждый может параметры по умолчанию реализовать.

VD> Я незнаю что ты там про ISO говоришь.

Я читал в новостях, что микрософт уже и в ISO "подсунул" этот стандарт.

VD> Но ECMA привняла то что еей подсунул МС.

Другими словами, мнение ECMA для тебя не авторитет? Марионеточная организация, управляемая из Редмонда?

VD> И он отличается от рельного дотнета. В дотнете есть тот же ВБ в котором дефолтные параметры прекрасно работают.

В VB работают. А в C# — запрещены стандартом. Каждому своё.

VD> И никаких пролблем нет. Проблема только в том, что их нет в шарпе и МС++, а ведь дефолтные параметры для С++ как раз действительно входят в стандарты ANSI и ISO. Так что из-за этой глупости МС++ никогда не сможет быть совместимым со стандартом С++.

Думаешь, из-за этой глупости? По моему, он хоть с этой глупостью, хоть без неё не будет совместим со стандартом C++. Разве что микрософт "подсунет" кому следует новый стандарт C++.

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

M>Ветка чуть повыше этой. Давай технический спор там вести, раз уж он там пошёл. А флеймить будем в этой ветке, раз уж здесь пошёл разговорный жанр

Блин, их тут тысячи. Тяжело ссылку дать?

M>Я читал в новостях, что микрософт уже и в ISO "подсунул" этот стандарт.

Подсунуть ISO можно все что угодно. Вот только это ничего не говорит. ISO годами на SQL и C++ стандарты принимает. А уж левый корпоротивный стандарт вообще засушат скорее всего. И вообще, обычно стандарты в ИТ-области проходящие через ISO сначала проходят через ANSI.

А .NET несовместма даже с SS CLI. У них форматы фалов в CLI описаны не полностью. Так что это все чтобы на МС не лили грязь по поводу неприятия ими стандартов.

M>Другими словами, мнение ECMA для тебя не авторитет? Марионеточная организация, управляемая из Редмонда?

Это в формум по С++ там тебе радужно опишут значимость этой виликой стандартизирующей ораганизации. Ты лучше скази, до того как МС подал в ЕСМА дотнет ты сам то слышал о ЕСМА?

VD> И он отличается от рельного дотнета. В дотнете есть тот же ВБ в котором дефолтные параметры прекрасно работают.

M>В VB работают. А в C# — запрещены стандартом. Каждому своё.

Ну, кто стандарт изобрел мы думаю помнишь. К тому же это не правда. Ничего там не запрещено. Там просто нет такого пункта. Да и Шарп — это не дотнет.

VD> И никаких пролблем нет. Проблема только в том, что их нет в шарпе и МС++, а ведь дефолтные параметры для С++ как раз действительно входят в стандарты ANSI и ISO. Так что из-за этой глупости МС++ никогда не сможет быть совместимым со стандартом С++.

M>Думаешь, из-за этой глупости? По моему, он хоть с этой глупостью, хоть без неё не будет совместим со стандартом C++. Разве что микрософт "подсунет" кому следует новый стандарт C++.

VC 7.1 совместмо со стандартом на 98%.

Ты кое-чего не допонимаешь. Стандарты бывают корпоративными и открытыми. Как бы не пыжилась МС, но ее стандарты всегда будут коропоративными, так как им просто плювать на других. Так что ВБ не менее стандартен, чем Шарпм. А стандартизация С++ просто не в их власти.

МС, кстати, подал заявку на стандартизацию МС++-расширений С++. Но речь идет именно о расширениях. И забитие на часть стандарта является очень серьезной ошибкой. Этво вообще смешно. Сделать в МС++ такие сложнейшие вещи как множественное наследование и шаблоны, а мелочевку похерили. И все это на пустом месте.

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

M>Вопрос не в мнении сборки о версиях. Вопрос в мнении сборки о значениях константы.

Ожегов:

KOHCTAHTA, -ы, ж. (спец.). Постоянная величина. II прил. константный, -ая, -ое.

Лингво:

constant константа, постоянная величина; постоянный коэффициент || постоянный; неизменный

Значения констант не могут изменяться. Это их суть. Изменение константы является фактическим изменением версии сборки. Точно так же как изменение публичного интерфейса (врочем, константа и является частью этого интерфейса).

M>Да. Только при изменении синатуры мы явно увидим эту нужду в перекомпиляции.

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

M>Это похоже на ситуацию с несовмесимостью разъёмов. Ты не вставишь USB-проводок в клавиатурный разъём. Или антенный кабель в электрическую розетку. Это сделано специально, чтобы несовместимость интерфейсов была как можно более явной, физической. Так же и с сигнатурами методов.

Это похоже на обратную аналогию. Обяснить почему такие аргументы не могут восприниматься серьезно?

M>Если сигнатура у метода изменилась — дотнет не даст вызвать этот метод. То есть здесь он отсекает и обеспечивает несовместимость по интерфейсу. Старый штепсель не лезет в новую розетку.

Еще раз повторяю, константа — это именованное неизменное значение. И оно (значение) является частью публичного интерфейса.

M>В случае с константами и параметрами по умолчанию дотнет уже ничего не обеспечивает.

Ты просто не понимешь чем константа отличается от переменной. Вот и все. Дотнет довольно гибкая вещь. Он одновеременно предоставляет и средства контроля версий, и позволяет на них забить (считая, что человек уменне железки). И дефолтные значения ничему тут не мешают. ВБ работает ничем не хуже чем Шрп. И в КОМ-е (КОМ, между прочим, тоже компонентная технология) долгие годы были параметры по умолчанию. И в С++. И никаких проблем небыло.

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

Ну, это я тоже оставлю без коментариев. Так как к делу это отношение не имеет.

VD>В общем, попробуй придумать более разумные аргументы против значений по умолчанию для параметров.

M>Других аргументов вроде не существует.

Т.е. реально аргументов нет. Есть просто не любовь. Ну, что же. Можешь класно развлечсь подняв это вопрос в форуме по С++. М не же разговоры про штепсили не интересны.