Я на нее ссылаюсь в своем описание, именно ваша работа с подвигла написать этот пост. Expression<Func<T, bool>> это конечно круто, но когда речь идет об объектах предметной области (так же они являются Aggregation root) вы попробуйте написать адекватный Expression. Объект хранилища может не обладать свойствами объекта предметной области как решить эту проблему?
Смотря что назвать скиллом, «впихнуть невпихнуемое» это конечно круто, но все это не от хорошей жизни, а от недостатка, недостатка ресурсов, памяти, мощности… Шаманство катострофически снижает читаемость и понимаемость кода, а значит и сопровождение. Но к сожалению часто приходиться брать в руки бубен и надеяться, что этот код ни кто ни когда не увидет и уж тем более не станет побывать исправлять.
Речь идет больше о WPF на фреймворке, а вот тут отличия значительные, мыло в тексте, отсутствие «Кэшированная композиция», мега баг с RadioButton.IsChecked и привязкой… Со всем этим можно жить, можно и на заборе спать. Вот только очень много неудобств, допилов и
некоторого количества шаманств прикручивается
и это все в место того что бы заниматься высокоуровневой архитектурой ( которая мне куда интересней чем технологическое шаманство, от которого к сожалению ни куда не деться )
Настоящие проблемы у тех, кто хочет строить действительно интересные интерфейсы (то есть приложения для потребителе)
К сожаление потребитель на которого мы работаем (а это тысячи клиентов) часто не намерены обновлять железо ради покупки инструмента, но при этом все хотят красивый интерфей да еще удобный да еще и что бы летал. Бизнес диктует правила из за которых приходится плясать с бубном.
А я понимаю разработчиков. На данный момент работаю над проектом на c#. Требования жесткие, программа должна запускаться на машинах с XP (а это .net 3.5), в качестве каркаса используем Prism (wpf). Бд MS SQLServer. И вот что бы это чудо работало и на «Калькуляторах» реально приходиться плясать с бубном — это и жесткая оптимизация ресурсов WPF и всевозможное кэширование данных, что бы лишний раз не делать обращения к мс серверу. Ах да «Калькуляторы» обладают одной не приятной особенностью — наличием памяти, точнее отсутствием необходимого объема.
с 1м согласен.
Со 2м не согласен. Отписка — ее нет (ну может я плохо искал). Хоте ее можно реализовать самостоятельно (допиливая существующий функционал или написав новый, чего не особо хочется)
с 3м согласен, злоупотреблять стэком это не хорошо.
«Язык гетто» или слабонервным вход воспрещен. Можно смело ставить в одну линейку с BrainFuck и Whitespace. Выглядит отпадно! Но сам бы я на таком писать… увольте. Запишу в историю, с пометкой «Как делать не стоит».
Борюсь с остатками здравого смысла, и прошу разработать язык Орков.
для слушателя то же самое дерево, только слушатель обойдет все дерево (обходом нельзя управлять), а посещением можно управлять, например для оптимизированных bool выражений (target != null && target.Value > 100 — если target == null, то правое условие даже проверять не нужно, что удобно. Выполнение же правой части выдаст ошибку)
Здесь рассматривается конкретная задача, и ее решение двумя способами. Так же проводиться сравнение двух подходов для решения (да да, я повторяюсь) конкретной задачи. Так же я написал, что если оставить исходную постановку задачи (трансляция JSON в текст XML), по слушатель подойдет лучше.
И как их правильно комбинировать между собой.
Сначала подумал «бред», потом все ж пришел к выводу, что это вполне возможно (одно поддерево скушать, а другое посещать). Есть какой ни будь пример (заинтересовало)?
А можно как то формализовать области применения одного и другого?
PEG фактически описывает нисходящий рекурсивный парсер с откатами. Этот тип парсеров имеет одно ограничение. Без специальной доработки (негативно влияющей на производительность и сильно усложняющей парсер) парсеры этого типа не могут разбирать леворекурсивные грамматики.
Леворекурсивной грамматикой называют грамматику, которая имеет леворекурсивные правила (прямые или нет). Например, следующая грамматика имеет левую рекурсию:
X = X '+' 1 / 1
…
Научно доказано, что любое леворекурсивное правило можно переписать без левой рекурсии. Например, приведенное выше правило можно переписать так:
что то мне не нравиться сгенерированный парсер, понятно что он авто, но вот поиск ошибок будет затруднен
states[0] = new State(new int[]{28,27,8,31,9,35,10,39,11,43,12,47,13,51,14,55,15,59,16,63,17,67,18,71,19,75,20,79,21,83,22,87,23,91,24,95,25,99,26,103,3,108,4,109,5,110,6,112,7,113,39,114,32,116,31,118},new int[]{-1,1,-3,3,-4,30,-5,107,-6,111});
states[1] = new State(new int[]{2,2});
states[2] = new State(-1);
и так 150 строк не перевариваемого кода. можно захлебнуться
и это все в место того что бы заниматься высокоуровневой архитектурой ( которая мне куда интересней чем технологическое шаманство, от которого к сожалению ни куда не деться )
К сожаление потребитель на которого мы работаем (а это тысячи клиентов) часто не намерены обновлять железо ради покупки инструмента, но при этом все хотят красивый интерфей да еще удобный да еще и что бы летал. Бизнес диктует правила из за которых приходится плясать с бубном.
Со 2м не согласен. Отписка — ее нет (ну может я плохо искал). Хоте ее можно реализовать самостоятельно (допиливая существующий функционал или написав новый, чего не особо хочется)
с 3м согласен, злоупотреблять стэком это не хорошо.
Борюсь с остатками здравого смысла, и прошу разработать язык Орков.
Сначала подумал «бред», потом все ж пришел к выводу, что это вполне возможно (одно поддерево скушать, а другое посещать). Есть какой ни будь пример (заинтересовало)?
А можно как то формализовать области применения одного и другого?
я не очень знаком с грамматиками
очевидно левая рекурсия, но как от нее избавиться?
когда примерно то же самое в antlr
а если убрать весь шум (помогающий обходить дерево)
хотя обход нужно писать отдельно (но за разделение ответственности нужно платить)
и так 150 строк не перевариваемого кода. можно захлебнуться
калькуляторы, куда ж без них. Нужно будет посмотреть спасибо!