Здравствуйте, Ikemefula, Вы писали:
WH>>Паттерн это повторяющейся код. WH>>Повторяющегося кода больше нет. WH>>Паттерна больше нет. I>На вызывающей стороне всего лишь стало меньше кода. Ни одна из проблем майнтенанса не решена.
Копипаста исчезла?
Да.
Проблемы связанные с копипастой исчезли?
Да.
I>Это если целенаправленно копипастить, при чем буквально — копировал в клипборд, копировал из клипборда
I>Кроме того, любой паттерн можно локально оптимизировать десятком вариантов. В твоем случае это реализуемо только теоретически, за счет усложнения мета-кода.
Оптимизируй это
// This is a simple customer class that
// implements the IPropertyChange interface.public class DemoCustomer : INotifyPropertyChanged
{
// These fields hold the values for the public properties.private Guid idValue = Guid.NewGuid();
private string customerNameValue = String.Empty;
private string phoneNumberValue = String.Empty;
public event PropertyChangedEventHandler PropertyChanged;
// This method is called by the Set accessor of each property.
// The CallerMemberName attribute that is applied to the optional propertyName
// parameter causes the property name of the caller to be substituted as an argument.private void NotifyPropertyChanged([CallerMemberName] String propertyName = "")
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
// The constructor is private to enforce the factory pattern.private DemoCustomer()
{
customerNameValue = "Customer";
phoneNumberValue = "(312)555-0100";
}
// This is the public factory method.public static DemoCustomer CreateNewCustomer()
{
return new DemoCustomer();
}
// This property represents an ID, suitable
// for use as a primary key in a database.public Guid ID
{
get
{
return this.idValue;
}
}
public string CustomerName
{
get
{
return this.customerNameValue;
}
set
{
if (value != this.customerNameValue)
{
this.customerNameValue = value;
NotifyPropertyChanged("CustomerName");
}
}
}
public string PhoneNumber
{
get
{
return this.phoneNumberValue;
}
set
{
if (value != this.phoneNumberValue)
{
this.phoneNumberValue = value;
NotifyPropertyChanged("PhoneNumber");
}
}
}
}
С макросами это будет так
// This is a simple customer class that
// implements the IPropertyChange interface.
[ImplementNotifyPropertyChanged]
public class DemoCustomer : INotifyPropertyChanged
{
// These fields hold the values for the public properties.private Guid idValue = Guid.NewGuid();
// The constructor is private to enforce the factory pattern.private DemoCustomer()
{
CustomerNameValue = "Customer";
PhoneNumberValue = "(312)555-0100";
}
// This is the public factory method.public static DemoCustomer CreateNewCustomer()
{
return new DemoCustomer();
}
// This property represents an ID, suitable
// for use as a primary key in a database.public Guid ID
{
get
{
return this.idValue;
}
}
public string CustomerName { get; set; default String.Empty; }
public string PhoneNumber { get; set; default String.Empty; }
}
Теперь добавь ещё десяток свойств. Помножь на пару десятков классов.
Потом порефакторь.
Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства.
I>В репе ровно обратное, скажем полно вот таких вещей I>
I>Почему это не паттерн, не ясно
Этого наезда вообще не понял.
Что ты тут хочешь сэкономить?
I>Правильно, в том то и дело. Единственный способ полностью убрать паттер это изменение языка, которое, внезапно, большей частью никогда и не наступит.
Макросы меняют язык.
I>В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи.
С метакодом ты на этой задаче упаришься гоняться.
I>Выносить всю такую логику в мета-код и терять гибкость по моему как то странно
Ты метакод вообще писал?
Ибо с точки зрения человека, который его действительно писал, ты несёшь полный бред.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[16]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>На вызывающей стороне всего лишь стало меньше кода. Ни одна из проблем майнтенанса не решена. WH>Копипаста исчезла? WH>Да. WH>Проблемы связанные с копипастой исчезли? WH>Да.
Ты наверное сравниваешь копипасту с её отсутствием А я вообще говорю про внятный дизайн vs макры.
Если, скажем, ты заюзал паттерн Синглтон и упрятал внутренности поглубже, основная проблема с Синглтоном в том, что это фактически глобальная переменная, доступная из разных мест.
Независимо от того, где находятся внутренности, проблема глобальной переменной остаётся чего бы ты не делал.
I>>Кроме того, любой паттерн можно локально оптимизировать десятком вариантов. В твоем случае это реализуемо только теоретически, за счет усложнения мета-кода. WH>Теперь добавь ещё десяток свойств. Помножь на пару десятков классов. WH>Потом порефакторь.
см пример ниже.
WH>Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства.
Это давно уже решено
I>>В репе ровно обратное, скажем полно вот таких вещей I>>
I>>Почему это не паттерн, не ясно WH>Этого наезда вообще не понял. WH>Что ты тут хочешь сэкономить?
Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити.
I>>Правильно, в том то и дело. Единственный способ полностью убрать паттер это изменение языка, которое, внезапно, большей частью никогда и не наступит. WH>Макросы меняют язык.
Linq уже внятно поддерживается или как ?
I>>В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи. WH>С метакодом ты на этой задаче упаришься гоняться.
Ога. Вот представь у тебя есть некоторый АПИ. Ну хоть и та моделька, что ты показал.
И ты его заюзал во всем приложении. Само собой, все это упрятано в макросы всех сортов — ты же именно этот подход проповедуешь ?
Теперь фокус — этот апи в силу требований становится асинхронным. Твоя задача — переписать весь код, который завязан на эту хрень, вплоть до самого верхнего уровня.
I>>Выносить всю такую логику в мета-код и терять гибкость по моему как то странно WH>Ты метакод вообще писал?
Разумеется.
WH>Ибо с точки зрения человека, который его действительно писал, ты несёшь полный бред.
Ты уже в который раз за два дня переходишь на личности и пытаешься обсуждать квалификацию. За последние лет 8 я уже привык
Re[16]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>Структурировать приходится не потому, что язык не тот, а потому, что информации слишком много. Небольшие изменения часто приводят к тому, что структура решения меняется очень сильно. WH>И для этого метакод идеален.
Покажи как синхронную модель превратить в асинхронную, и весь вызывающий код независимо от глубины вложенности и тд и тд так же превратить в асинхронный.
I>>Например код, внезапно, который был серверным, должен стать клиентским. Или наоборот — часть кода клиента должна мигрировать на сервер или вовсе въехать в БД. WH>Подпилить метакод в таких случаях очень просто.
Не ясно, что такое "просто", в каких единицах это мерять ?
I>>В обмен на усложение за счет мета-кода, отсутствия рефакторинга и, как следствие, запрета регулярных, постоянных изменений в требованиях ? WH>Метакод даёт прямо противоположный эффект.
Покажи пример, как провести рефакторинг по превращения синхронного кода в асинхронный. Более того, что бы это свойство менялось вызывающим кодом.
WH>Ты разговариваешь с человеком, который последние 2 года пишет в основном метакод.
А ты знаешь, что такие фразы это ни разу не аргумент ? Сам подумай — такое может написать практически любой.
Re[6]: Суть паттернов и других подходов в программировании
Ops>>>Когда я первый раз почитал про паттерны, оказалось, что я большую часть из того же ГоФ знаю и вовсю применяю PD>>Когда я первый раз прочитал про паттерны, я понял, что о них я знал еще тогда, когда не было паттернов G>Господа, вы же профессионалы, просто достаньте линейки и померяйтесь.
Профессионалы пользуюся рулетками.
Как много веселых ребят, и все делают велосипед...
Re[7]: Суть паттернов и других подходов в программировании
Здравствуйте, Ikemefula, Вы писали:
I>Ты наверное сравниваешь копипасту с её отсутствием А я вообще говорю про внятный дизайн vs макры.
INotifyPropertyChanged это невнятный дизацн?
I>Если, скажем, ты заюзал паттерн Синглтон и упрятал внутренности поглубже, основная проблема с Синглтоном в том, что это фактически глобальная переменная, доступная из разных мест. I>Независимо от того, где находятся внутренности, проблема глобальной переменной остаётся чего бы ты не делал.
Опять с темы съезжаешь.
Причём тут вообще глобальные переменные?
WH>>Теперь добавь ещё десяток свойств. Помножь на пару десятков классов. WH>>Потом порефакторь. I>см пример ниже.
Что смотреть?
WH>>Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства. I>Это давно уже решено
Как?
I>Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити.
Я утверждаю, что ты утверждаешь бред.
На весь репозиторий я насчитал аж 4 применения этого паттерна.
Причем что тут можно сократить вообще не ясно.
I>Linq уже внятно поддерживается или как ?
Не знаю. Я им не пользуюсь.
I>Теперь фокус — этот апи в силу требований становится асинхронным. Твоя задача — переписать весь код, который завязан на эту хрень, вплоть до самого верхнего уровня.
Я регулярно подобным занимаюсь.
Но из-за того что у меня всё на ДСЛях никаких проблем не возникает.
В любом случае тебе придётся проделать минимум на порядок больше работы чем мне.
I>>>Выносить всю такую логику в мета-код и терять гибкость по моему как то странно WH>>Ты метакод вообще писал? I>Разумеется.
Не верю. Ибо иначе не нёс бы бред.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[17]: Суть паттернов и других подходов в программировании
Здравствуйте, Ikemefula, Вы писали:
I>Покажи как синхронную модель превратить в асинхронную, и весь вызывающий код независимо от глубины вложенности и тд и тд так же превратить в асинхронный.
У меня изначально ничего на это завязано не будет.
И клиенты ДСЛя просто ничего не заметят.
С парсером я такое уже не один раз проделывал.
I>Не ясно, что такое "просто", в каких единицах это мерять ?
В строчках кода.
WH>>Ты разговариваешь с человеком, который последние 2 года пишет в основном метакод. I>А ты знаешь, что такие фразы это ни разу не аргумент ? Сам подумай — такое может написать практически любой.
Не соврав мало кто может.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[18]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>Покажи как синхронную модель превратить в асинхронную, и весь вызывающий код независимо от глубины вложенности и тд и тд так же превратить в асинхронный. WH>У меня изначально ничего на это завязано не будет.
Это не аргумент. Выдай формулу с помощью которой любой девелопер, даже студент сможет повторить такой вот фокус.
Вот у меня есть код
return x.f();
Внезапно, он становится асинхронным. Теперь любая функция, которая его вызывает, становится асинхронной и так до самого верха.
I>>Не ясно, что такое "просто", в каких единицах это мерять ? WH>В строчках кода.
Строчки кода к простоте не имеют отношения. Если ты не согласен, то без труда скажешь, что это за алгоритм
f =: (] #~ [: +/ =/) i.@(>./)
Я вот думаю, что простоту надо мерять по целевой аудитории. Если большинству понятно, значит это действительно просто.
Re[18]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>Ты наверное сравниваешь копипасту с её отсутствием А я вообще говорю про внятный дизайн vs макры. WH>INotifyPropertyChanged это невнятный дизацн?
У меня без макров кода примерно столько, как у тебя с макрами. Мне, скажем, незачем выжимать такты процессора для интерактивных сцериев. Оптимизирую я для своих конкретных случаев и очевидно это не такты процессора.
I>>Независимо от того, где находятся внутренности, проблема глобальной переменной остаётся чего бы ты не делал. WH>Опять с темы съезжаешь. WH>Причём тут вообще глобальные переменные?
На примере макры Синглтон. Независимо от размера кода самого синглтона, 10 строчек кода на реализацию или 20, проблемы находятся в вызывающем коде.
Ты предлагаешь забить на эти проблемы и сделать код синглтона короче. У меня вот некоторые синглтоны вызываются по 1000 и более раз (>50мб кода). Это значит, что количеством кода самого класса, какой бы вариант для синглтона не был выбран, можно тупо пренебречь.
Зато имеет значение, как избавляться от этих синглтонов. И здесь это не так просто, как кажется. Каждый случай использования нужно обрабатывать руками, общего решения нет и быть не может.
WH>>>Не забудь отследить, что в NotifyPropertyChanged всегда передаётся строка, соответствующая имени свойства. I>>Это давно уже решено WH>Как?
Имя свойства в C# уже "само" приходит. Ты же сам вроде показал.
I>>Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити. WH>Я утверждаю, что ты утверждаешь бред. WH>На весь репозиторий я насчитал аж 4 применения этого паттерна.
Копипаста !!!
WH>Причем что тут можно сократить вообще не ясно.
Ты же сам сказал, что копипасту надо прятать.
I>>Linq уже внятно поддерживается или как ? WH>Не знаю. Я им не пользуюсь.
linq <# код запроса #>
вот от этого в немерле уже избавились или как ?
I>>Теперь фокус — этот апи в силу требований становится асинхронным. Твоя задача — переписать весь код, который завязан на эту хрень, вплоть до самого верхнего уровня. WH>Я регулярно подобным занимаюсь. WH>Но из-за того что у меня всё на ДСЛях никаких проблем не возникает. WH>В любом случае тебе придётся проделать минимум на порядок больше работы чем мне.
То есть, ничего кроме общих слов.
I>>Разумеется. WH>Не верю. Ибо иначе не нёс бы бред.
см выше
Re[15]: Суть паттернов и других подходов в программировании
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, WolfHound, Вы писали:
I>В реальности надо вводить согласованые изменения в разные участки кода, которые, внезапно, могут сворачиваться в более общие структуры. После изменения требований, что происходит постоянно, эти структуры трансформируются в совершенно разные вещи.
Вы так написали что чувствуется системный подход. Вы случайно не знакомы с какими-любо средствами разработки, которые такие согласованные изменения могут наглядно представлять и контролировать?
Re[16]: Суть паттернов и других подходов в программировании
Здравствуйте, Vaako, Вы писали:
V>Вы так написали что чувствуется системный подход. Вы случайно не знакомы с какими-любо средствами разработки, которые такие согласованные изменения могут наглядно представлять и контролировать?
Более менее внятные вещи есть только для статически типизированых языков. Например http://www.ndepend.com/, но этого мало, обязательно нужен внятный инструмент для рефакторинга и внятный декомпилер. Скажем, большую часть информации проще и эффективнее искать прямо в бинарниках.
Проблема возникает с проектами, которые состоят из нескольких солюшнов или же написаны на разных языках или есть злоупотребление разными динамическими фичами, тайп-касты, виртуальные методы или вовсе оголтелая динамика.
Чем больше такого разнообразия, тем сложнее контролировать зависимости.
Re[19]: Суть паттернов и других подходов в программировании
Здравствуйте, Ikemefula, Вы писали:
I>У меня без макров кода примерно столько, как у тебя с макрами. Мне, скажем, незачем выжимать такты процессора для интерактивных сцериев. Оптимизирую я для своих конкретных случаев и очевидно это не такты процессора.
Ты код то покажи. Вот мой если выкинуть всё что к делу не относится.
[ImplementNotifyPropertyChanged]
public class DemoCustomer : INotifyPropertyChanged
{
public string CustomerName { get; set; default String.Empty; }
public string PhoneNumber { get; set; default String.Empty; }
}
I>На примере макры Синглтон. Независимо от размера кода самого синглтона, 10 строчек кода на реализацию или 20, проблемы находятся в вызывающем коде.
А у меня синглитонов нет совсем.
Ни одного.
Все статические переменные содержат исключительно неизменяемые данные, определяемые на этапе компиляции.
I>Ты предлагаешь забить на эти проблемы и сделать код синглтона короче. У меня вот некоторые синглтоны вызываются по 1000 и более раз (>50мб кода). Это значит, что количеством кода самого класса, какой бы вариант для синглтона не был выбран, можно тупо пренебречь.
Когда все на ДСЛях то обе стороны генерируется.
И мне нужно поправить код в двух метах.
I>Зато имеет значение, как избавляться от этих синглтонов. И здесь это не так просто, как кажется. Каждый случай использования нужно обрабатывать руками, общего решения нет и быть не может.
Их изначально не должно быть.
I>Имя свойства в C# уже "само" приходит. Ты же сам вроде показал.
Где?
I>>>Я утверждаю, что это паттерн мета-кода, которому пока что еще не дали названия за немногочисленностью коммюнити. WH>>Я утверждаю, что ты утверждаешь бред. WH>>На весь репозиторий я насчитал аж 4 применения этого паттерна. I>Копипаста !!!
Посчитай количество кода типа в своём проекте.
foreach (xxx in yyy)
{
zzz
}
WH>>Причем что тут можно сократить вообще не ясно. I>Ты же сам сказал, что копипасту надо прятать.
Ну, так ты и показал код, который затащил всю копипасту в себя.
I>
I> linq <# код запроса #>
I>
I>вот от этого в немерле уже избавились или как ?
А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.
I>То есть, ничего кроме общих слов.
Есть. А вот у тебя только бла-бла-бла. https://github.com/JetBrains/Nitra
I>>>Разумеется. WH>>Не верю. Ибо иначе не нёс бы бред. I>см выше
Что выше? Ты ни одного примера своей работы с метапрограммированием не привёл.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[19]: Суть паттернов и других подходов в программировании
Здравствуйте, Ikemefula, Вы писали:
I>Внезапно, он становится асинхронным. Теперь любая функция, которая его вызывает, становится асинхронной и так до самого верха.
Я вежливо попрошу компилятор сделать все, что нужно асинхронным.
А ты посадишь десяток студентов превращать 10 метров кода в 100.
I>>>Не ясно, что такое "просто", в каких единицах это мерять ? WH>>В строчках кода. I>Строчки кода к простоте не имеют отношения. Если ты не согласен, то без труда скажешь, что это за алгоритм
Ты ещё предложи код заархивировать. И на основе того что сжатый код вообще читать нельзя попробуй доказать свою правоту.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[20]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>Внезапно, он становится асинхронным. Теперь любая функция, которая его вызывает, становится асинхронной и так до самого верха. WH>Я вежливо попрошу компилятор сделать все, что нужно асинхронным. WH>А ты посадишь десяток студентов превращать 10 метров кода в 100.
То есть, никаких подробностей от тебя нет. Непонятно, кто будет патчить вызывающий код. И кстати говоря, асинхронный код может быть таким же на вид как и синхронный, более того, часто он бывает еще и короче. Парадокс, да ?
I>>>>Не ясно, что такое "просто", в каких единицах это мерять ? WH>>>В строчках кода. I>>Строчки кода к простоте не имеют отношения. Если ты не согласен, то без труда скажешь, что это за алгоритм WH>Ты ещё предложи код заархивировать. И на основе того что сжатый код вообще читать нельзя попробуй доказать свою правоту.
Итого твоя трактовка простоты снова сломалась
Re[21]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>То есть, никаких подробностей от тебя нет. WH>Есть. Просто ты читать не умеешь.
"вежливо попрошу компилятор"
Это оно ?
WH>А вообще нужно перестать с тобой разговаривать, ибо ничего интересного я от тебя ни разу не услышал. WH>Один трёп про то, что ты в глаза не видел.
см выше
Re[22]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>То есть, никаких подробностей от тебя нет. WH>Есть. Просто ты читать не умеешь.
На всякий, еще раз про асинхронщину
public GenerateMigration(path : string, ns : string) : void
{
def date = DateTime.Now.ToString("yyyyMMddhhmmss");
def migrationName = $"M$(date).n";
def text = ClassGenerator().GenerateMigration(ns, migrationName, migrationUsingsList);
File.WriteAllText(Path.Combine(path, migrationName), text);
}
Насколько понимаю, там где $ это интерполяция через макрос. Нет возможности пример получше подобрать. Что делать, если подобный код должен стать асинхронным, скажем, надо что бы унутре строки была функция, которая возвращает асинхронный результат.
Мне очень интересно посмотреть, как твои макросы помогут забороть вызывающий код.
Если имеем дело с чистым ДСЛ, то нет никаких проблем. А вот что делать с ЯОН ?
Валяй.
Re[6]: Суть паттернов и других подходов в программировании
Здравствуйте, Sinclair, Вы писали:
S>Потому, что в язык встроены понятия "class type" и "виртуальный конструктор". S>Если я объявил класс TMyButton с конструктором Create, унаследованный от TControl, то я могу передать ссылку на этот класс в любой код, который ожидает ссылку на TControlClass. И этот код сможет порождать мои кнопки, вызывая конструктор Create через эту ссылку.
Это плохой пример. Фабрика это довольно устойчивая модель и внутри достаточно простая. Нет никакой проблемы с макросами.
С любой устойчивой моделью будет ровно то же.
Вопрос в том, как быть, когда модель меняется постоянно, то уезжает частями на сервер, то в бд, то еще куда нибудь.
Язык разумеется ЯОН, а не ДСЛ-всемогутор.
Вот если сделано все через функции, то тупо заглядывая внутрь, я буду находить нужные детали. При внятном дизайне я могу видеть ровно столько, сколько мне нужно.
Непонятно, как быть с макросами. Я вот всерьёз считаю, что восстанавливать детали реализации из метакода занятие малоперспективное. Вот скажем неделю назад я несколько дней листал репозиторий через вебморду частично с телефона, частично с ипада. Весь генерированый текст под носом. Собтсвенно генерация делается только там, где без неё не обойтись, т.е. нужно описать неизвестное заранее количество сущностей.
Посмотрел шаблон, посмотрел где какие функции чего делают, и все вобщем понятно.
Как это повторить, если все детали спрятаны в мета-коде макроса, совершенно непонятно.
Предполагается, что любой программист должен уметь компилировать в уме макросы ?
В простых случаях, навроде интерполяции строк, генерации сущностей для некоторой устойчивой модели, все понятно. Но вот чем дальше, тем все тухлее.
Как быть с преобразованием синхронного кода в асинхронный и обратно ?
Вроде как самое то для макросов. Но вот непонятно, как сорганизовать код, что бы все необходимое было в макросах.
Re[20]: Суть паттернов и других подходов в программировании
Здравствуйте, WolfHound, Вы писали:
I>>У меня без макров кода примерно столько, как у тебя с макрами. Мне, скажем, незачем выжимать такты процессора для интерактивных сцериев. Оптимизирую я для своих конкретных случаев и очевидно это не такты процессора. WH>Ты код то покажи. Вот мой если выкинуть всё что к делу не относится. WH>
WH> [ImplementNotifyPropertyChanged]
WH> public class DemoCustomer : INotifyPropertyChanged
WH> {
WH> public string CustomerName { get; set; default String.Empty; }
WH> public string PhoneNumber { get; set; default String.Empty; }
WH> }
WH>
Чего ты не унимаешься ? Я вроде как сказал, что для стабильных моделей макросы вполне себе годятся. Конкретно в моём случае T4 шаблон.
1 детали реализации проще отследить
2 весь код в репе, отсюда все мыслимые и немыслимые тулы умеют работать с этим искаропки
I>>На примере макры Синглтон. Независимо от размера кода самого синглтона, 10 строчек кода на реализацию или 20, проблемы находятся в вызывающем коде. WH>А у меня синглитонов нет совсем. WH>Ни одного.
Это не ответ. Мы про макрос Синглтон, а не про твой подход к дизайну.
I>>Ты предлагаешь забить на эти проблемы и сделать код синглтона короче. У меня вот некоторые синглтоны вызываются по 1000 и более раз (>50мб кода). Это значит, что количеством кода самого класса, какой бы вариант для синглтона не был выбран, можно тупо пренебречь. WH>Когда все на ДСЛях то обе стороны генерируется.
Ты наверное хочешь, но стесняешься сказать примерно такое
1 — кроме макров надо поменять парадигму, использовать чтото навроде language oriented programming или dsl oriented programming
2 — вместо ЯОН нужен расширяемый ДСЛ-всемогутор
3 — нужен внятный дизайн
Как следствие из всего выше, в команде не должно быть студентов, которые жаждут применить паттерн Синглтон.
Если все на расширяемом ДСЛ то как бы вопросов нет. Вопрос в том, что будет с макросами в ЯОН.
I>>Зато имеет значение, как избавляться от этих синглтонов. И здесь это не так просто, как кажется. Каждый случай использования нужно обрабатывать руками, общего решения нет и быть не может. WH>Их изначально не должно быть.
То есть, в кратце, макры здесь ничем не помогают ?
I>>Имя свойства в C# уже "само" приходит. Ты же сам вроде показал. WH>Где?
Атрибут перед именем переменной '[CallerMemberName]' в твоём коде
I>>Копипаста !!! WH>Посчитай количество кода типа в своём проекте. WH>
WH>foreach (xxx in yyy)
WH>{
WH> zzz
WH>}
WH>
Такой код почти везде, что тебя смущает ?
I>>вот от этого в немерле уже избавились или как ? WH>А немерле нет. Парсер слабый. В нитре на которой будет немерле2 подобных ограничение изначально не будет.
То есть, это то о чем я говорил — язык перестает развиваться не смотря ни на что. Сколько лет уже ждут Nemerle 2 ?
I>>То есть, ничего кроме общих слов. WH>Есть. А вот у тебя только бла-бла-бла. WH>https://github.com/JetBrains/Nitra
Это не ответ. С таким же успехом ты можешь дать ссылку на библию или собрание сочинений Ленина.
I>>см выше WH>Что выше? Ты ни одного примера своей работы с метапрограммированием не привёл.
Правильно, это ведь ты рассказываешь про некий мифический профит, но стесняешься придумать один нормальный пример — скоро десять лет одно и то же твердишь.
Re[6]: Суть паттернов и других подходов в программировании
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!