Здравствуйте, SV., Вы писали:
SV.>Можете ли вы привести пример, когда булевский параметр метода вам действительно необходим?
Курить термин: "дизъюнктивная когерентность".
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, 0x7be, Вы писали:
0>Здравствуйте, SV., Вы писали:
SV.>>Можете ли вы привести пример, когда булевский параметр метода вам действительно необходим? 0>Таких ситуаций нет, хотя бы потому, что любую ситуацию, где используется булева переменная, модно переписать на использование какого-нибудь enum`а или int`a. Предлагаю изменить постановку вопроса на: "когда применение булевого параметра было бы оптимальным".
Возьмем С++:
Было :
void DoSomething(bool flag)
{
if (flag)
DoSomethingNow();
else
DoSomethingLater();
}
Стало:
enum DoFlag
{
DO_FLAG_NOW,
DO_FLAG_LATER,
}
void DoSomething(DoFlag flag)
{
switch (flag)
{
case DO_FLAG_NOW:
DoSomethingNow();
break;
case DO_FLAG_LATER:
DoSomethingLater();
break;
default:
// Must never get here
assert(false);
break;
}
}
Здравствуйте, _NN_, Вы писали:
_NN>Нет, конечно. _NN>Ведь enum DoFlag когда-то может быть изменен.
Значит это уже не аналог bool => в первом варианте использовать bool нельзя.
при этом для понимания из какого enum-а брать Italic достаточно вывести тип выражения на основе типа параметра функции MergeFont (что, кстати, уже делает intellisence, но не делает компилятор)
А что значит "действительно необходим"? В любом случае можно обойтись без него, используия целые числа 0 и 1, или содержательные енумы из двух элементов (Для первого примера — WAIT_UNTIL_DONE и DONT_WAIT_UNTIL_DONE). Но не проще ли использовать бул?
DG>при этом для понимания из какого enum-а брать Italic достаточно вывести тип выражения на основе типа параметра функции MergeFont (что, кстати, уже делает intellisence, но не делает компилятор)
Или так:
font += Font.Italic;
font -= Font.Italic;
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
24>А что значит "действительно необходим"? В любом случае можно обойтись без него, используия целые числа 0 и 1, или содержательные енумы из двух элементов (Для первого примера — WAIT_UNTIL_DONE и DONT_WAIT_UNTIL_DONE). Но не проще ли использовать бул?
Проще, без сомнения. Enum сложнее — программа становится на 1 элемент больше. Но это простота, которая хуже воровства. Все, почему-то, приводят декларации: waitUntilDone, repeats, isFirstRun... А вы вызовы приведите:
Так вот. Очевидно, что авторы таких методов делают что — используют (reuse) не по делу встроенный в язык универсальный нетипизированный enum (true, false), лишь бы свой не объявлять. Популярные языки не позволяют писать так:
Вот людям и не хочется заводить отдельные сущности. Это относится к половине приведенных примеров. Другая половина лечится (действительно, лечится, то есть, становится лучше) путем введения дополнительного класса с булевскими свойствами. Ах, да. Есть еще ответ про когерентность — он некогерентен, и про абсолютную обходимость — он непрагматичен и потому легко обходим.
Теперь к вашему вопросу про "необходимо". Необходимо, это когда необходимо. Когда нужен именно универсальный нетипизированный enum в параметрах, и любая попытка обойти делает код очевидно хуже.
Я пока вижу только работу с флагами, в сугубо закрытых методах реализаций. Неужели больше никто ничего придумать не может? Если так, то давно следует если не ошибку компиляции давать на bool в публичных методах, то уж warning точно. Не знаю, не ломлюсь ли я в открытую дверь — идея весьма очевидна.
Здравствуйте, SV., Вы писали:
SV.>Вот людям и не хочется заводить отдельные сущности. Это относится к половине приведенных примеров.
я думал, что к этому ведёт вопрос, поэтому добавлю, что при вызовах методов с булевскими флагами практикую одно из двух:
1) либо объявляю для общего пользования в том же классе, где и метод с булевским параметром, две булевских константы с говорящими именами
2) либо пишу при вызове true /* isFirstRun */, false /* don't wait until done */
Здравствуйте, SV., Вы писали:
SV.>Все, почему-то, приводят декларации: waitUntilDone, repeats, isFirstRun... А вы вызовы приведите:
Вот вызов на Objective-C:
в идеале слово Font здесь лишнее (однозначно восстанавливаемое из контекста) S>
S>font += Italic;
S>font -= Italic;
S>
зы
вот этот метод мне не очень нравится, он создает неоднозначности при дальнейших расширениях
font -= Font.Italic;
одно из желаемых расширений — это чтобы можно было наложить сразу группу "эффектов" (это в частности необходимо, когда эффекты возвращаются внешней функций):
var effects = Italic + !Bold + 24px; //var effects = GetEffects();
font += effects;
если же есть функция -=, то необходимо разбираться что дает минус группа: эффект пропадает только при строгом сравнении, при нестрогом, как-то еще.
Здравствуйте, SV., Вы писали:
SV.>Можете ли вы привести пример, когда булевский параметр метода вам действительно необходим?
Конечно.
database.AllowSnapshotIsolation(true);
во первых это нетривиальная операция и пропертей ей быть не следует
во вторых переход выглядит как disabled -> enabling -> enabled и булом его описать нельзя
Здравствуйте, rm822, Вы писали:
SV.>>Можете ли вы привести пример, когда булевский параметр метода вам действительно необходим? R>Конечно. R>
R>database.AllowSnapshotIsolation(true);
R>
R>во первых это нетривиальная операция и пропертей ей быть не следует R>во вторых переход выглядит как disabled -> enabling -> enabled и булом его описать нельзя
Здесь вообще никакие параметры не нужны, IMHO. Ни булевы, ни не булевы.
enum State
{
Disabling,
Disabled,
Enabling,
Enabled,
}
class Database
{
State GetState();
void EnableSnapshotIsolation();
void DisableSnapshotIsolation();
}
R>Интерфейс определяется решаемыми задачами, а не твоими фантазиями R>привычный синтаксис таков R>
R>ALTER DATABASE <dbname> SET ALLOW_SNAPSHOT_ISOLATION <ON|OFF>;
R>
Я не в курсе про SQL-ный интерфейс к этому классу.
R>и методы должны по возможности близки к нему
AllowSnapshotIsolation(true); -- вот это вы называете "по возможности близки"? Если уж задаваться такой целью, нужен enum { ON, OFF }.
R>State же просто никому не нужен, это твои фантазии
Извините, вот это кто написал? "во вторых переход выглядит как disabled -> enabling -> enabled и булом его описать нельзя". Если вы не читаете из этого свойства (оно write-only), то его МОЖНО описать булом. А если читаете, то читать надо отдельным методом GetSatate(), поскольку такие свойства, в которых кладешь одно, а они возвращают другое, делать Заратустра не позволяет.
R>ну и в конце концов батарея из 30 методов начинающихся на Enable\Disable это просто нечитаемый отстой, колторый к тому же и не комплитится нормально
Здравствуйте, SV., Вы писали:
R>>и методы должны по возможности близки к нему SV.>AllowSnapshotIsolation(true); -- вот это вы называете "по возможности близки"? Если уж задаваться такой целью, нужен enum { ON, OFF }.
Я не силен в сиквелах, но: а это не случай ли с классом-конфигурацией? В SQL Server Management Studio я смутно припоминаю несколько диалогов с PropertyBrowser'ами, что и навело меня на такое подозрение. AllowSnapshotIsolation не одно ли из этих свойств, которые пачками устанавливаются?
