Здравствуйте, Константин Л., Вы писали:
КЛ>>>1. Вынужденное зло — это что-то из серии личной неприязни.
AVK>>Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.
КЛ>Какие личности? О чем ты?
Ключевое слово я жирным выделил.
КЛ> Да и нет у меня неприязни к var.
Вот и не надо заниматься демагогией.
AVK>>С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.
КЛ>Ога. У нас уже не просто код, а "абстрактный псевдокод". Разницу м/у абстрактным псевдокодом и обычным кодом ты знаешь.
Хм, думал ты поймешь. Поясняю логическую цепочку: для записи сути алгоритма, если нам не нужно получить компилируемый код, обычно стараются придумать более простую как для формулирования, так и для чтения форму. Обычно в этой роли выступает псевдокод либо даже просто описание на естествененом языке. Так вот — в этих описаниях никто не аннотирует конкретные типы. Потому что это не требуется для описания сути.
Вот, например:
Получаем объект автоматизации студии DTE.
Сканируем все активные проекты в открытом солюшене и выбираем те из них, которые являются проектами C#.
Находим среди них тот, output assembly которого совпадает с именем сборки.
Рекурсивно обходим все элементы проекта и находим среди них те, расширение файлов которых соответствует заданному.
Находим элемент проекта, соответствующий codebehind.
Находим имя первого типа в файле codebehind (стандартное поведение дизайнеров студии).
Сравниваем его с заданным.
Если совпало — возвращаемся к айтему-владельцу и открываем его в редакторе.
Это абсолютно исчерпывающее для понимания сути кода описание алгоритма. При этом ни одного типа в этом описании нет. Так вот, в идеале и код должен быть точно такой же.
КЛ>попозже
Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.
КЛ>восприятие кода и экспертная оценка — разные вещи.
Возможно. Но то, что ты назвал демагогией, как раз таки экспертная оценка и есть. Опирающаяся, разумеется, на мой опыт.
КЛ> Вот попытка собсвенное восприятие подогнать под экспертную оценку
Аргументы, на основании которых ты заключил, что это так.
КЛ>, да еще и восприятие других людей под нее подогнать — демагогия.
Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.
AVK>>А я и не собираюсь переубеждать того, кто переубеждаться не хочет.
КЛ>аналогично
Ну и к чему тогда тут обсуждение личностей?
AVK>>С моей стороны никакой демагогии пока нет.
КЛ>ну я другого мнения и не ожидал
По делу есть что сказать?
AVK>>А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?
КЛ>и тебе можно, и мне можно. дело только в категоричности высказываний.
Категоричность высказываний — не повод называть эти высказывания демагогией.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>1. Вынужденное зло — это что-то из серии личной неприязни.
AVK>>>Все подобные домыслы идут в лес, бо неумелая демагогия (переход на личности). Почему? Потому что я точно так же могу начать рассуждать о твоей личной неприязни к var.
КЛ>>Какие личности? О чем ты?
AVK>Ключевое слово я жирным выделил.
Допустим, тогда ты должен доказать, что это не личная неприязнь, а общеизвестный факт
КЛ>> Да и нет у меня неприязни к var.
AVK>Вот и не надо заниматься демагогией.
AVK>>>С таких. Видел хоть в одном абстрактном псевдокоде типы? Вот то то и оно.
КЛ>>Ога. У нас уже не просто код, а "абстрактный псевдокод". Разницу м/у абстрактным псевдокодом и обычным кодом ты знаешь.
AVK>Хм, думал ты поймешь. Поясняю логическую цепочку: для записи сути алгоритма, если нам не нужно получить компилируемый код, обычно стараются придумать более простую как для формулирования, так и для чтения форму. Обычно в этой роли выступает псевдокод либо даже просто описание на естествененом языке. Так вот — в этих описаниях никто не аннотирует конкретные типы. Потому что это не требуется для описания сути. AVK>Вот, например: AVK>
AVK>
AVK>Получаем объект автоматизации студии DTE.
AVK>Сканируем все активные проекты в открытом солюшене и выбираем те из них, которые являются проектами C#.
AVK>Находим среди них тот, output assembly которого совпадает с именем сборки.
AVK>Рекурсивно обходим все элементы проекта и находим среди них те, расширение файлов которых соответствует заданному.
AVK>Находим элемент проекта, соответствующий codebehind.
AVK>Находим имя первого типа в файле codebehind (стандартное поведение дизайнеров студии).
AVK>Сравниваем его с заданным.
AVK>Если совпало — возвращаемся к айтему-владельцу и открываем его в редакторе.
AVK>
AVK>Это абсолютно исчерпывающее для понимания сути кода описание алгоритма. При этом ни одного типа в этом описании нет. Так вот, в идеале и код должен быть точно такой же.
Отлично. Это все понятно. Имеем один пример. Слава богу ты не привел описание алгоритма для вычисления максимума, или алгоритма бинарного поиска
КЛ>>попозже
AVK>Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.
. Обрати внимание на закомментированные строки с явной аннотацией типов.
1. Поддержка студии была тогда почти никакой.
2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию
3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие
Вот, например, тебе файлик. Разберешься сходу с foreach?
КЛ>>восприятие кода и экспертная оценка — разные вещи.
AVK>Возможно. Но то, что ты назвал демагогией, как раз таки экспертная оценка и есть. Опирающаяся, разумеется, на мой опыт.
То, что я назвал демагогией, это попытка выдать личные предпочтения и личное восприятие за очевидные вещи, используя такую риторику —
Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.
Не слишком ли загнул, м?
КЛ>> Вот попытка собсвенное восприятие подогнать под экспертную оценку
AVK>Аргументы, на основании которых ты заключил, что это так.
выше
КЛ>>, да еще и восприятие других людей под нее подогнать — демагогия.
AVK>Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.
получается как умею. Однако ты свою правду объявил общей. Вот где подгон.
AVK>>>А я и не собираюсь переубеждать того, кто переубеждаться не хочет.
КЛ>>аналогично
AVK>Ну и к чему тогда тут обсуждение личностей?
нету тут обсуждения личностей. тут обсуждение высказываний.
AVK>>>С моей стороны никакой демагогии пока нет.
КЛ>>ну я другого мнения и не ожидал
AVK>По делу есть что сказать?
по делу выше.
AVK>>>А чего ты тогда сюда ввязался? Или тебе можно, а у меня сразу же демагогия?
КЛ>>и тебе можно, и мне можно. дело только в категоричности высказываний.
AVK>Категоричность высказываний — не повод называть эти высказывания демагогией.
Re[16]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, _FRED_, Вы писали:
_FR>Приведи пример кода, в котором из-за замены имени типа переменной на var ты не смог бы разобраться?
Это не совсем про читабельность, но все-таки.
В некоторых проектах ведется такая шняга, как tracability matrix. Суть ее в том, что каждый участок кода так или иначе связан с реализаций некоторых требований. Если в код были внесены какие-либо изменения, то тестеры могут отследить, какие требования могло затронуть это изменение и перетестировать, не сломалось ли чего.
Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать.
Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[19]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
КЛ>Допустим, тогда ты должен доказать, что это не личная неприязнь, а общеизвестный факт
Это ты должен доказывать. Ты же меня в личной неприязни обвинил.
КЛ>Отлично. Это все понятно. Имеем один пример. Слава богу ты не привел описание алгоритма для вычисления максимума, или алгоритма бинарного поиска
Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.
AVK>>Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.
КЛ>здесь
. Обрати внимание на закомментированные строки с явной аннотацией типов.
КЛ>1. Поддержка студии была тогда почти никакой. КЛ>2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию КЛ>3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие
КЛ>Вот, например, тебе файлик. Разберешься сходу с foreach?
Можно вместо двух экранов кода конкретный кусок прямо сюда привести?
КЛ>
КЛ>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.
КЛ>Не слишком ли загнул, м?
Фигурная резьба по цитатам? Смайлик ты зачем отрезал? Это во-первых. А во-вторых это совсем не из того сообщения цитата, где ты демагогией обозвал. Из этого делаю вывод — аргументов у тебя нет, одни домыслы. Что и следовало ожидать.
AVK>>Аргументы, на основании которых ты заключил, что это так.
КЛ>выше
Нету выше аргументов. Опять бездоказательный наезд.
AVK>>Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.
КЛ>получается как умею.
Лучше тогда не стоит.
КЛ> Однако ты свою правду объявил общей. Вот где подгон.
И опять бездоказательный наезд.
AVK>>Ну и к чему тогда тут обсуждение личностей?
КЛ>нету тут обсуждения личностей.
А это просто вранье.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
КЛ>>Допустим, тогда ты должен доказать, что это не личная неприязнь, а общеизвестный факт
AVK>Это ты должен доказывать. Ты же меня в личной неприязни обвинил.
Что я тебе должен доказывать? Что твое личное мнение это твое личное мнение?
КЛ>>Отлично. Это все понятно. Имеем один пример. Слава богу ты не привел описание алгоритма для вычисления максимума, или алгоритма бинарного поиска
AVK>Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.
по делу ты ничего не ответил, выделю специально жирным чуть ниже
AVK>>>Вот плохо, что рассуждения о личной неприязни, это у тебя сейчас, а то что действительно интересно обсудить — попозже.
. Обрати внимание на закомментированные строки с явной аннотацией типов.
КЛ>>1. Поддержка студии была тогда почти никакой. КЛ>>2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию КЛ>>3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие
КЛ>>Вот, например, тебе файлик. Разберешься сходу с foreach?
AVK>Можно вместо двух экранов кода конкретный кусок прямо сюда привести?
конечно конечно
macro @foreach (inexpr, body)
syntax ("foreach", "(", inexpr, ")", body)
{
match (ListComprehensionHelper.ExpandRange (inexpr, body)) {
| Some (expr) => Nemerle.Imperative.Return (expr)
| None => {}
}
def (iter, collection) =
match (inexpr) {
| <[ $i in $c ]> => (i, c)
| e =>
Message.FatalError ($ "the syntax is 'foreach (x in collection)', "
"got $e");
}
def typer = Macros.ImplicitCTX ();
def tcollection = typer.TypeExpr (collection);
// build the body of loop (may contain additional matching)
def build_definition (val) {
match (body) {
| <[ match ($(null)) { ..$cases } ]> =>
match (iter) {
| <[ $(x : name) ]> when char.IsLower (x.Id[0]) | <[ (..$_) ]> => ()
| _ => Message.FatalError ("only simple names available in pattern"
" of foreach with direct matching")
}
<[ def $iter = $val;
match ($iter) { ..$cases }
]>
| _ =>
def mat =
match (iter) {
| <[ $pat :> $ty ]> =>
<[ match ($val :> $ty) { | $pat => $body; () | _ => () } ]>
| _ =>
<[ match ($val) { | $iter => $body; () | _ => () } ]>
}
mat.cases.Iter (fun (x : PT.MatchCase) { x.disable_warnings = true });
mat
}
}
// here we choose if we want to use enumerator pattern
// of access GetEnumerator through IEnumarable
// http://www.jaggersoft.com/csharp_standard/15.8.4.htm
def decide_enumerator_pattern (tyinfo) {
def all = tyinfo.LookupMember ("GetEnumerator");
def choosen = List.Exists (all, fun (mem : IMember) {
| meth is IMethod when !meth.IsStatic && meth.GetParameters ().IsEmpty =>
match (meth.ReturnType.Fix ()) {
// FIXME: do additional conservative checks
| MType.Class (tc, _) when
!tc.LookupMember ("MoveNext").IsEmpty &&
!tc.LookupMember ("Current").IsEmpty => true
| _ => false
}
| _ => false
});
if (choosen)
<[ $(tcollection : typed).GetEnumerator () ]>
else
<[ ($(tcollection : typed) : System.Collections.IEnumerable).GetEnumerator () ]>
}
typer.DelayMacro (fun (fail_loudly) {
match (tcollection.Type.Hint) {
| Some (MType.Class (tc, args)) =>
if (tc.InternalType.Nemerle_list_tc != null
&& tc.SuperType (tc.InternalType.Nemerle_list_tc).IsSome)
{
def arg = List.Head (args);
def definition = build_definition (<[ x ]>);
Some (<[
// we explicitly set parameter type to list, because collection's type
// can be more specific (list.Cons, etc.)
($("_N_break" : global) : {
def foreach_loop (_ : list [$(arg : typed)]) {
| x :: xs =>
$("_N_continue" : global) : {
$definition;
}
foreach_loop (xs)
| _ => ()
}
foreach_loop ($(tcollection : typed))
})
]>)
}
else {
def init_body = decide_enumerator_pattern (tc);
def is_disposable =
typer.JustTry (fun () {
def expr = typer.TypeExpr (init_body);
expr.Type.Require (<[ ttype: System.IDisposable ]>)
});
def finally_body =
if (is_disposable)
<[ (enumerator : System.IDisposable).Dispose () ]>
else
<[
match (enumerator) {
| x is System.IDisposable => x.Dispose ();
| _ => ()
}
]>;
def definition = build_definition (<[ enumerator.Current ]>);
Some (<[
def enumerator = $init_body;
$("_N_break" : global) : {
def loop () {
when (enumerator.MoveNext ()) {
$("_N_continue" : global) : {
$definition;
}
loop ();
}
}
try { loop () }
finally { $finally_body }
}
]>)
}
| Some (MType.Array (_ , rank)) =>
def indices = array (rank);
def lengths = array (rank);
for (mutable i = 0; i < rank; ++i) {
indices [i] = Macros.NewSymbol ();
lengths [i] = Macros.NewSymbol ();
}
def indices_list = List.RevMap (List.FromArray (indices), fun (x) {
<[ $(x : name) ]>
});
def build_loops (depth) {
/// build expression defining iteration symbols
| 0 => build_definition (<[ cached_collection [..$indices_list] ]>)
| n =>
def idx = indices [n - 1];
<[ for (mutable $(idx : name) = 0;
$(idx : name) < $(lengths [n - 1] : name);
++ $(idx : name))
$(build_loops (n - 1))
]>
}
mutable sequence = [ <[ $(build_loops (rank)) ]> ];
if (rank == 1)
sequence = <[ def $(lengths [0] : name) = cached_collection.Length ]> :: sequence;
else
for (mutable i = rank - 1; i >= 0; --i)
sequence = <[ def $(lengths [(rank - 1) - i] : name) = cached_collection.GetLength ($(i : int)) ]>
:: sequence;
sequence = <[ def cached_collection = $(tcollection : typed) ]> :: sequence;
Some (<[ { .. $sequence } ]>)
| t =>
when (fail_loudly) {
def guess =
match (t) {
| Some (t) => $ "current best guess about the type is $t"
| None => "the compiler has no idea what the type might be"
}
Message.Error ($ "collection in foreach must be an array or "
"type implementing enumerator pattern, $guess");
Message.Hint ("try specifing the type directly using 'expr : SomeType'");
}
None ()
}
})
}
КЛ>>
КЛ>>Правда состоит в том, что при чтении, а не написании, кода, знать точное имя типа просто не нужно.
КЛ>>Не слишком ли загнул, м?
AVK>Фигурная резьба по цитатам? Смайлик ты зачем отрезал? Это во-первых. А во-вторых это совсем не из того сообщения цитата, где ты демагогией обозвал. Из этого делаю вывод — аргументов у тебя нет, одни домыслы. Что и следовало ожидать.
Ок. В конце смайлик. Что это меняет, объясни?
А вот и то, на что я сказал "демагогия":
Потому что строгую типизацию придумали для того, чтобы компилятор мог автоматически проверять соответствие контрактов, и, как следствие, контроллировать до определенной степени корректность программы. Необходимость же явно аннотировать типы — вынужденное зло. И если компилятор умеет избавлять нас от этого зла, не снижая ни на йоту уровень контроля, от этого код становится только чище и меньше содержит не относящейся непосредственно к решаемой задаче информации.
AVK>>>Аргументы, на основании которых ты заключил, что это так.
КЛ>>выше
AVK>Нету выше аргументов. Опять бездоказательный наезд.
Твоя же цитата уже не твоя?
AVK>>>Опять мимо. Плохо у тебя получается, мастерства не хватает. Я ничье восприятие никуда подгонять не пытался.
КЛ>>получается как умею.
AVK>Лучше тогда не стоит.
спасибо, но еще попробую
КЛ>> Однако ты свою правду объявил общей. Вот где подгон.
AVK>И опять бездоказательный наезд.
Ну как же
Правда состоит в том[/b], что при чтении, а не написании, кода, знать точное имя типа просто не нужно.
AVK>>>Ну и к чему тогда тут обсуждение личностей?
КЛ>>нету тут обсуждения личностей.
AVK>А это просто вранье.
Не нервничай
Re[21]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
КЛ>Что я тебе должен доказывать? Что твое личное мнение это твое личное мнение?
Что тор, что я считаю экспертной оценкой на самом деле личная неприязнь.
AVK>>Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.
КЛ>по делу ты ничего не ответил
Ах вон оно как.
AVK>>Можно вместо двух экранов кода конкретный кусок прямо сюда привести?
КЛ>конечно конечно
Ха ха ха. Вобщем понятно, за душой у тебя ничего нет, флеймишь впустую. На сем и закончим.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Константин Л., Вы писали:
КЛ>>Что я тебе должен доказывать? Что твое личное мнение это твое личное мнение?
AVK>Что тор, что я считаю экспертной оценкой на самом деле личная неприязнь.
На самом деле личные предпочтения, не более.
AVK>>>Не понимаю причины сарказма. И еще не понимаю, почему опять по делу ни-че-го.
КЛ>>по делу ты ничего не ответил
AVK>Ах вон оно как.
Именно так.
AVK>>>Можно вместо двух экранов кода конкретный кусок прямо сюда привести?
КЛ>>конечно конечно
AVK>Ха ха ха. Вобщем понятно, за душой у тебя ничего нет, флеймишь впустую. На сем и закончим.
Еще раз повторяю, может ты перестанешь игнорировать и ответишь на это что-нибудь:
здесь. Обрати внимание на закомментированные строки с явной аннотацией типов.
1. Поддержка студии была тогда почти никакой.
2. Типы, возвращаемые всякими Typer.ImplicitCtx() — загадка, ибо никаких хинтов. А типы нужны, тк только зная типы, можно было выуживать необходимую информацию
3. Чтение core.n вне IDE (которая и так давала мало информации) — еще то занятие
2 раза просил. На третий соизволишь? Спасибо.
Re[17]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Lloyd, Вы писали:
_FR>>Приведи пример кода, в котором из-за замены имени типа переменной на var ты не смог бы разобраться?
L>Это не совсем про читабельность, но все-таки.
L>В некоторых проектах ведется такая шняга, как tracability matrix. Суть ее в том, что каждый участок кода так или иначе связан с реализаций некоторых требований. Если в код были внесены какие-либо изменения, то тестеры могут отследить, какие требования могло затронуть это изменение и перетестировать, не сломалось ли чего.
Да, вопрос хороший и по делу.
L>Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать. L>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.
Я вот наоборот, считаю данный эффект положительным и даже наоборот — если при изменении типа, например, возвращаемого методом значения, можно не делать чекаут\чекин файлам, которые эти изменения затрагивают, то значит неплохо был продуман открытый контракт типов, между которыми произошла замена. Это лишь моё мнение.
По сути: не верю я, что если "по tracability matrix будет отслежено", то это принесёт хоть какую-то пользу. Посуди сам: равноправно замена может произвестись на полиморфный тип (что частенько случается, например, вместо Class1 метод стал возвращать более конкретный наследник Class1Derived), и тогда указанный тобой подход работать не будет: список изменённых файлов ничего не покажет.
Если уж опираться на tracability matrix (кстати, именно tracability или traceability matrix?), то получать её надо не "набором файлов, которые пришлось поменять что бы компилятор смог скомпилировать", а умной туловиной навроде решарпера, которая покажет, в каких файлах использовались изменённые члены класса. Туловина, кстати, смогла бы и рассчитать важность изменения для тестирования.
Help will always be given at Hogwarts to those who ask for it.
Re[18]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, _FRED_, Вы писали:
L>>Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать. L>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.
_FR>Я вот наоборот, считаю данный эффект положительным и даже наоборот — если при изменении типа, например, возвращаемого методом значения, можно не делать чекаут\чекин файлам, которые эти изменения затрагивают, то значит неплохо был продуман открытый контракт типов, между которыми произошла замена. Это лишь моё мнение.
Результатом продуманного открытого контракта типа должен быть интерфейс, который этот контракт реализует. И в этом случае лучше явно работать через интерфейс, а не надеяться на var. Это тоже лишь моё мнение.
Re[17]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Lloyd, Вы писали:
L>Если мы не используем var в конструкциях типа var x = someObject.GetSomething(), то, если поменяется тип значения, возвращаемого методом GetSomething, то нам придется явно поменять тип переменной везде, где делается вызов этого метода. По tracability matrix будет отслежено, какие требования это изменение затронуло и соответственно их смогут перетестировать. L>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.
Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, AndrewVK, Вы писали:
L>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.
AVK>Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать?
Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован.
В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[19]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Lloyd, Вы писали:
L>Здравствуйте, AndrewVK, Вы писали:
L>>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить.
AVK>>Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать?
L>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован. L>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.
Вообще, несколько необычная практика. У вас автоматический тул, который строит зависимости и показывает что-то типа code coverage как unit tests? По-моему так сходу сложно оценить риски и необходимый охват.
Re[19]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Lloyd, Вы писали:
L>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.
Все равно не очень понятно. var имеет отношение только к изменению контрактов, а контракты у нас проверяет компилятор, так что ничего перетестировать не надо. Если же поменялось внутреннее поведение метода, то оно и без var может повлиять на кучу нетронутых кусков кода.
А вот то, что при рефакторинге окажется затронуто изменениями меньшее количество файлов — это безусловно положительный момент.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Lloyd, Вы писали:
_FR>>Я вот наоборот, считаю данный эффект положительным и даже наоборот — если при изменении типа, например, возвращаемого методом значения, можно не делать чекаут\чекин файлам, которые эти изменения затрагивают, то значит неплохо был продуман открытый контракт типов, между которыми произошла замена. Это лишь моё мнение.
L>Результатом продуманного открытого контракта типа должен быть интерфейс, который этот контракт реализует. И в этом случае лучше явно работать через интерфейс, а не надеяться на var.
А почему "интерфейс" — это именно некий тип? Это лишь ограничение конкретного компилятора. Интерфейсы служат для уменьшения зависимости между частями кода, в частности, для того, что бы метод, возвращающий некое значение мог начать возвращать другое значение (другого конкретного типа), а код "снаружи" об этом бы не узнал. В таком случае указанная тобой метрика становится бесполезной, ибо код стал работать по другому, а тект-то не поменялся, а перетестирование может потребоваться.
"var" — это ещё один шаг, после абстрактных классов и интерфейсов, позволяющий уменьшить связанность кода. Duck-нотация с самого начала использовалась в c#, и никому не мешала. Применение "var" позволяет шире внедрить её использование, что, повторюсь, ещё более снизит зависимость кусков кода друг от друга.
Help will always be given at Hogwarts to those who ask for it.
Re[19]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Lloyd, Вы писали:
L>>>Если же использовался var, то эту информацию будет уже гораздо сложнее восстановить. AVK>>Вобщем то, так и есть. Но есть другой вопрос — а зачем такие ситуации отслеживать? L>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован. L>В случае использования var-ов, формально код не поменялся, но де-факто он изменился.
Не забывай, что при использовании интерфейсов или абстрактный классов вызывающий код так же не меняется, но перетестировать его нужно (например, если вместо MemoryStream метод стал возвращать реально NetworkStream, тогда как в контракте метода указано Stream, грабли ещё какие могут вылезти). В этом подходе вне зависимости от частоты использования var ничего нельзя будет увидеть.
L>Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.
Не более чем другие, используемые уже вовсю средства. Точно так же любое разделение (логики от представления, контракта от реализации) "усложняет трассировку" и, может показаться (пока не привыкнешь) что и разработку.
Help will always be given at Hogwarts to those who ask for it.
Re[20]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, _FRED_, Вы писали:
L>>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован. L>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился.
_FR>Не забывай, что при использовании интерфейсов или абстрактный классов вызывающий код так же не меняется, но перетестировать его нужно (например, если вместо MemoryStream метод стал возвращать реально NetworkStream, тогда как в контракте метода указано Stream, грабли ещё какие могут вылезти). В этом подходе вне зависимости от частоты использования var ничего нельзя будет увидеть.
Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[20]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Константин Л., Вы писали:
L>>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован. L>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.
КЛ>Вообще, несколько необычная практика. У вас автоматический тул, который строит зависимости и показывает что-то типа code coverage как unit tests? По-моему так сходу сложно оценить риски и необходимый охват.
Лично мы, это не используем. Но я учавствовал в проекте, в котором заказчик хотел видеть в рамках какой user story был изменен файл. Эта информация бралась из Perforce-а.
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[20]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, AndrewVK, Вы писали:
L>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился. Т.е. использование var-ов скрывает от нас факт изменения кода и тем самым усложняет трассировку требований.
AVK>Все равно не очень понятно. var имеет отношение только к изменению контрактов, а контракты у нас проверяет компилятор, так что ничего перетестировать не надо. Если же поменялось внутреннее поведение метода, то оно и без var может повлиять на кучу нетронутых кусков кода.
Я не против var-а, я и сам его местами использую. Я против неявного изменения кода. Если код изменился — это должно быть отражено явно.
AVK>А вот то, что при рефакторинге окажется затронуто изменениями меньшее количество файлов — это безусловно положительный момент.
Почему? В чем такой уж плюс? Или вы все под SourceSafe-ом сидите?
... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>
Re[21]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, Lloyd, Вы писали:
L>>>Я же написал об этом. Если код поменялся, он по-хорошему должен быть перетестирован. L>>>В случае использования var-ов, формально код не поменялся, но де-факто он изменился.
_FR>>Не забывай, что при использовании интерфейсов или абстрактный классов вызывающий код так же не меняется, но перетестировать его нужно (например, если вместо MemoryStream метод стал возвращать реально NetworkStream, тогда как в контракте метода указано Stream, грабли ещё какие могут вылезти). В этом подходе вне зависимости от частоты использования var ничего нельзя будет увидеть.
L>Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.
Формулировки не понял, можешь конкретнее написать?
Help will always be given at Hogwarts to those who ask for it.
Re[22]: FileIOPermission, доступ к файлам в каталоге
Здравствуйте, _FRED_, Вы писали:
_FR>>>Не забывай, что при использовании интерфейсов или абстрактный классов вызывающий код так же не меняется, но перетестировать его нужно (например, если вместо MemoryStream метод стал возвращать реально NetworkStream, тогда как в контракте метода указано Stream, грабли ещё какие могут вылезти). В этом подходе вне зависимости от частоты использования var ничего нельзя будет увидеть.
L>>Как это, нельзя ничего увидеть?! Не используешь var — сломается утиная типизация. То есть как минимум ты увидишь эти случаи.
_FR>Формулировки не понял, можешь конкретнее написать?
string test() {
return"";
}
void use1() {
var t = test();
}
void use2() {
string t = test();
}
Меняем тип возвращаемого значения test на int.
use1 — не сломался. use2 — сломался.
Итого: когда не использовали var — изменение увидели, что опровергает выделенное выше.
