Відображаючи назву параметра: зловживання C # лямбда-виразами або синтаксичну яскравість?

Я дивлюся на компонент Gv MvcContrib і мене захоплює, але в той же час відштовхується синтаксичним трюком, який використовується в синтаксисі Grid :

.Attributes(style => "width:100%")

Синтаксис вище встановлює атрибут стилю створеного HTML width:100%. Тепер, якщо ви звернете увагу, "стиль" ніде не вказаний, виводиться з назви параметра в виразі! Мені довелося розібратися в цьому і виявив, де відбувається "чарівництво":

Hash(params Func<object, TValue>[] hash)
{
    foreach (var func in hash)
    {
        Add(func.Method.GetParameters()[0].Name, func(null));
    }
}

Таким чином, код використовує формальний час компіляції та ім’я параметрів для створення словника пар атрибутів імен-значень. Отримана синтаксична конструкція справді дуже виразна, але в той же час дуже небезпечна. Загальне використання лямбда-виразів дозволяє замінити імена, що вживаються без побічного ефекту. Я бачу приклад у книзі, в якій сказано, що collection.ForEach(book => Fire.Burn(book))я знаю, що можу написати у своєму коді, collection.ForEach(log => Fire.Burn(log))і це означає те саме . Але з раптовим синтаксисом MvcContrib Grid я знаходжу код, який активно виглядає і приймає рішення на основі імен, які я обираю для своїх змінних!

Так це звичайна практика для спільноти C # 3.5 / 4.0 та любителів лямбдаських виразів? Або це шахрай, який не повинен хвилюватися?

Це поганий інтероп. Наприклад, розглянемо цей приклад C # - F #

C #:

public class Class1
{
    public static void Foo(Func<object, string> f)
    {
        Console.WriteLine(f.Method.GetParameters()[0].Name);
    }
}

F #:

Class1.Foo(fun yadda -> "hello")

Результат:

"arg" друкується (не "yadda").

Як результат, дизайнерам бібліотеки слід або уникати подібних "зловживань", або, принаймні, забезпечувати "стандартне" перевантаження (наприклад, що приймає ім'я рядка як додатковий параметр), якщо вони хочуть мати хороший інтероп для всіх мов .Net.

Я вважаю це дивним не стільки через назву , скільки через те, що лямбда непотрібна ; він може використовувати анонімний тип і бути більш гнучким:

.Attributes(new { style = "width:100%", @class="foo", blip=123 });

Це шаблон, який використовується в більшості ASP.NET MVC (наприклад), і має інші можливості ( застереження , зауважте також думки Айенда, якщо ім'я є магічним значенням, а не конкретним для абонента)

Просто хотів кинути свою думку (я автор компонента сітки MvcContrib).

Це, безумовно, зловживання мовою - в цьому немає сумнівів. Однак я б не вважав це протилежним до інтуїтивного - коли ви дивитесь на дзвінокAttributes(style => "width:100%", @class => "foo")
я думаю, що це досить очевидно, що відбувається (це, звичайно, не гірше, ніж підхід анонімного типу). З точки зору інтелігенції, я згоден, це досить непрозоро.

Для тих, хто цікавиться, деяка довідкова інформація про його використання у MvcContrib ...

Я додав це до сітки як особисте вподобання - мені не подобається використання анонімних типів як словників (наявність параметра, який приймає "об'єкт", так само непрозора, як та, яка приймає парами Func []), а ініціалізатор колекції словників - це швидше багатослівний (я також не є прихильником багатослівних інтерфейсів, наприклад, зв'язати декілька викликів на атрибут ("стиль", "дисплей: жоден"). Атрибут ("клас", "foo") тощо)

Якби C # мав менш довершений синтаксис для словникових літералів, я б не заважав включати цей синтаксис у компонент сітки :)

Я також хочу зазначити, що використання цього в MvcContrib є абсолютно необов’язковим - це методи розширення, які обтягують перевантаження, які замість нього беруть ідентифікатор. Я думаю, що важливо, що якщо ви надаєте такий метод, ви також повинні підтримувати більш "звичайний" підхід, наприклад, для взаємодії з іншими мовами.

Крім того, хтось згадав про "відображення накладних витрат", і я просто хотів зазначити, що насправді не так багато витрат на цей підхід - немає жодної рефлексії виконання або компіляції виразів (див. Http://blog.bittercoder.com /PermaLink,guid,206e64d1-29ae-4362-874b-83f5b103727f.aspx ).

я волів би

Attributes.Add(string name, string value);

Це набагато чіткіше і стандартніше, і нічого не можна отримати, використовуючи лямбда.

Ласкаво просимо в Rails Land :)

З цим насправді немає нічого поганого, доки ви знаєте, що відбувається. (Саме тоді, коли подібні речі недостатньо задокументовані, виникає проблема).

Вся рамка Rails побудована на ідеї конвенції щодо конфігурації. Позначаючи речі певним чином, клює вас до конвенції, яку вони використовують, і ви отримуєте безліч функцій безкоштовно. Дотримуючись конвенції про іменування, ви перейдете куди швидше. Вся справа працює блискуче.

Ще одне місце, де я бачив такий трюк, - це у твердженнях викликів методів у Moq. Ви переходите в лямбду, але лямбда ніколи не виконується. Вони просто використовують вираз, щоб переконатися, що виклик методу стався, і викинули виняток, якщо ні.

Це жахливо на більш ніж одному рівні. І ні, це не що інше, як Рубі. Це зловживання C # і .Net.

Було багато пропозицій, як це зробити більш прямолінійним способом: кортежі, анонімні типи, вільний інтерфейс тощо.

Що робить це так погано, що це його справедливий шлях до власного блага:

• Що станеться, коли вам потрібно зателефонувати на це від VB?

  .Attributes(Function(style) "width:100%")

• Його повністю протилежний інтуїтивно зрозумілий інтеліссенс мало допоможе з’ясувати, як передавати речі.

• Це зайво неефективне.

• Ніхто не матиме поняття, як її підтримувати.

• Який тип аргументу надходить до атрибутів Func<object,string>? Яким є такий намір розкрити. Що стосується вашої інтелігенційної документації: "Будь ласка, ігноруйте всі значення об'єкта"

Я думаю, ви цілком виправдані, що маєте почуття відрази.

Я перебуваю в таборі "синтаксичної яскравості", якщо вони це чітко документують, і це виглядає це чудово круто, з цим іммо майже немає проблем!

Обидва. Це зловживання ламбда-виразами та синтаксичною яскравістю.

Я навряд чи коли-небудь стикався з таким використанням. Я думаю, що це "недоречно" :)

Це не звичайний спосіб використання, він суперечить загальним умовам. Цей синтаксис має свої плюси і мінуси, звичайно:

Мінуси

• Код не інтуїтивно зрозумілий (звичайні умовні умови різні)
• Вона, як правило, неміцна (перейменування параметра порушить функціональність).
• Тестувати трохи складніше (підробка API вимагатиме використання відображення в тестах).
• Якщо вираз використовується інтенсивно, воно буде повільніше через необхідність аналізу параметра, а не лише значення (вартість відображення)

Плюси

• Це читабельніше після того, як розробник налаштувався на цей синтаксис.

Підсумок - в публічному дизайні API я вибрав би більш чіткий спосіб.

Ні, це звичайно не звичайна практика. Це контр-інтуїтивно зрозуміло, немає ніякого способу просто подивитися на код, щоб зрозуміти, що він робить. Ви повинні знати, як це використовується, щоб зрозуміти, як воно використовується.

Замість надання атрибутів, використовуючи масив делегатів, методи ланцюжка були б зрозумілішими та ефективнішими:

.Attribute("style", "width:100%;").Attribute("class", "test")

Хоча це трохи більше набирати, це зрозуміло та інтуїтивно.

Чи можу я скористатися цією фразою?

магічна лямбда (n): функція лямбда, яка використовується виключно для заміни магічної струни.

Що не так у наступному:

html.Attributes["style"] = "width:100%";

Вся ця скандальність про "жахливість" - це купа давніх c # хлопців, які перебільшують реакцію (і я давній програміст C # і все ще дуже великий фанат мови). У цьому синтаксисі немає нічого страшного. Це просто спроба зробити синтаксис більш схожим на те, що ви намагаєтеся висловити. Чим менше "шуму" в чомусь синтаксисі, тим легше програміст може це зрозуміти. Зменшення шуму в одному рядку коду лише трохи допомагає, але нехай це накопичується через усе більше коду, і це виявляється суттєвою користю.

Це спроба автора прагнути до тих самих переваг, які дає вам DSL - коли код просто "схожий" на те, що ви намагаєтесь сказати, ви дійшли до магічного місця. Ви можете обговорити, чи добре це для інтеропу, чи достатньо приємно, ніж анонімні методи, щоб виправдати деякі «складності» вартості. Досить справедливо ... тому у своєму проекті ви повинні зробити правильний вибір, чи використовувати цей вид синтаксису. Але все-таки ... це розумна спроба програміста зробити те, що, врешті-решт, ми всі намагаємось зробити (чи усвідомлюємо ми це чи ні). І те, що ми всі намагаємось зробити, це таке: "Скажіть комп’ютеру, що ми хочемо, щоб він робив мовою, якомога ближчою до того, як ми думаємо про те, що хочемо робити."

Наблизившись до викладу наших інструкцій на комп’ютерах тим самим способом, який, як ми вважаємо, є ключовим фактором для того, щоб зробити програмне забезпечення більш доступним та точним.

EDIT: Я сказав, що "ключ до того, щоб зробити програмне забезпечення більш ретельним і точнішим", що є шалено наївною завищеною частиною єдиноборства. Я змінив його на "ключ".

Це одна з переваг дерев виразів - для додаткової інформації можна вивчити сам код. Ось як .Where(e => e.Name == "Jamie")можна перетворити в еквівалентний пункт SQL Where. Це розумне використання дерев виразів, хоча я б сподівався, що воно не піде далі від цього. Що-небудь більш складне, ймовірно, буде складніше, ніж код, який він сподівається замінити, тому я підозрюю, що це буде обмежувати себе.

Це цікавий підхід. Якщо ви обмежили праву частину виразу лише константами, тоді ви могли б застосувати використання

Expression<Func<object, string>>

Я вважаю, що ви дійсно хочете замість делегата (ви використовуєте лямбда для отримання імен обох сторін) Дивіться наївну реалізацію нижче:

public static IDictionary<string, string> Hash(params Expression<Func<object, string>>[] hash) {
    Dictionary<string, string> values = new Dictionary<string,string>();
    foreach (var func in hash) {
        values[func.Parameters[0].Name] = ((ConstantExpression)func.Body).Value.ToString();
    }
    return values;
}

Це може навіть вирішити проблему інтероп-перехресних мов, про яку було сказано раніше в потоці.

Код дуже розумний, але потенційно може викликати більше проблем, які він вирішує.

Як ви вже зазначали, тепер існує неясна залежність між назвою параметра (стилем) та атрибутом HTML. Перевірка часу компіляції не проводиться. Якщо ім'я параметра введено неправильно, на сторінці, ймовірно, не буде повідомлення про помилку виконання, але набагато складніше знайти логічну помилку (немає помилки, але неправильна поведінка).

Кращим рішенням буде мати член даних, який можна перевірити під час компіляції. Тож замість цього:

.Attributes(style => "width:100%");

код із властивістю Style може перевірити компілятор:

.Attributes.Style = "width:100%";

або навіть:

.Attributes.Style.Width.Percent = 100;

Це більше роботи для авторів коду, але цей підхід використовує перевагу сильної перевірки типу C #, що допомагає в першу чергу запобігти потраплянню помилок у код.

насправді це здається Ruby =), принаймні для мене використання статичного ресурсу для подальшого динамічного "пошуку" не підходить для міркувань дизайну api, сподіваюся, що цей розумний трюк не є обов'язковим у цьому api.

Ми можемо успадкувати від IDictionary (чи ні) та надати індексатор, який веде себе як масив php, коли вам не потрібно додавати ключ для встановлення значення. Це буде коректним використанням .net семантики не просто c #, а ще потрібна документація.

сподіваюся, що це допомагає

На мою думку, це зловживання лямбдами.

Щодо яскравості синтаксису, я вважаю style=>"width:100%"просто заплутаною. Особливо через =>замість=

ІМХО, це класний спосіб зробити це. Всі ми любимо той факт, що називання контролера класу зробить його контролером в MVC? Тож бувають випадки, коли називання має значення.

Також намір тут дуже зрозумілий. Дуже легко зрозуміти, що .Attribute( book => "something")призведе до book="something"і .Attribute( log => "something")призведе доlog="something"

Я думаю, це не повинно бути проблемою, якщо ставитися до цього як до конвенції. Я вважаю, що те, що змушує вас писати менше коду і робить намір очевидним, - це добре.

Якщо імена методу (func) вдало обрані, то це геніальний спосіб уникнути головних болів у підтримці (тобто: додати новий функцію, але забув додати його до списку відображення функцій-параметрів). Звичайно, вам потрібно сильно документувати це, і вам краще буде автоматично генерувати документацію для параметрів з документації для функцій цього класу ...

Я думаю, що це не краще, ніж "магічні струни". Я не дуже прихильник анонімних типів, або для цього. Він потребує кращого та сильно типізованого підходу.