Когда я должен использовать Предметно-ориентированный язык? [закрытый]
(xCode 9.2, Swift 4) Следующее может не помочь в решении вашей точной проблемы, но может помочь другим в решении очень похожей проблемы. Это была моя ошибка:
ошибка: IB Designables: Не удалось отобразить и обновить состояние автоматического макета для CustomExampleView (XXXXX): агент потерпел крах
Мне удалось удалить ошибка при удалении CustomExampleView.xib и CustomExampleView.swift. Для репликации я затем заново создал файлы, перешел на .xib и установил для пользовательского класса представления верхнего уровня значение CustomExampleView.
Моя ошибка заключалась в установке пользовательского класса в представление верхнего уровня на .xib вместо установки пользовательского класса в Владельце файла . После установки правильного пользовательского класса моя проблема была решена.
6 ответов
Есть очень мало веских причин для создания еще одного DSL. В мире полно специализированных языков.
Подумайте вместе с этими строками.
Решите проблему с помощью универсального языка, такого как Python, Java, C ++ ... что угодно.
Оптимизируйте это решение, чтобы фактор из общих функций и построить действительно красивую, действительно элегантную, действительно расширяемую библиотеку классов.
Оптимизируйте эту библиотеку классов, чтобы подчеркнуть «ортогональность». Убедитесь, что все функции хорошо работают вместе, без каких-либо проблем.
Если вам нужно только упрощение синтаксиса, создайте оболочку сценария вокруг вашей красивой библиотеки классов. Это ваш DSL. Для Python это просто - это уже динамический язык. Для Java есть вещи, которые вы можете использовать. Для C ++ может потребоваться небольшая работа по созданию этой гибкой среды сценариев.
Если вам все еще нужна дополнительная оптимизация, подумайте о написании компилятора для вашего DSL.
В статье ACM Computing Surveys Когда и как разрабатывать предметно-ориентированные языки даются советы только по этой теме, как и в книге Мартина Фаулера 2010 года Доменно-специфические языки .
Во-первых, я бы использовал DSL, когда проблемная область, в которой вы работаете, является широко известной областью, и некоторые бизнес-эксперты в этой области уже прошли через многое. построить такой DSL, чтобы вам не пришлось самостоятельно решать все проблемы, которые они уже выяснили.
Если вы думаете о создании DSL, я бы подумайте о том, чтобы сделать это, если ваш бизнес ведется в очень конкретной области, и вы проводите большую часть своего времени, сосредоточившись на конкретной проблемной области. Если вы постоянно работаете над приложениями для нескольких проблемных областей, я бы не советовал применять такой подход.
Например, если ваш бизнес занимается исключительно созданием налоговых приложений, было бы неплохо создать DSL налоговой системы.
One situation that comes to mind is when the requirements requires a very high or improbable level of customization/configuration. So you would provide a kind of scripting model against a DSL instead.
Takes a car assembly "arm" for example, providing a configuration model to support various factory configurations would be impossible. (detect this, don't detect that, when this happens do this ... etc.)
But compiling a new application with specialized logic for each customer is probably not a good way to go. So in this case, you create a little framework that would becomes a kind of DSL, and then for each robotic arm you sells, you write a little app in your DSL and save it along with the core software that would compiles and runs your DSL scripts instead. Or better yet, tools to program the DSL are included along with the robotic arm so your customer can "program" the arm themselves in the DSL you created.
One real world examples that comes to mind is Yahoo Pipes (you could think of it as a DSL) or the robots.txt directive for automated web crawler for example. They may not be a full-blown DSL but they demonstrate where DSL might be useful.
The most obvious is you should definitely use them when the language already exists and is well-supported. The prime examples of this are UIL for Motif-based GUI development and make for software builds.
If you have to make your own, I'd say to look for domains a large amount of effort is in just specifying things properly, and where your compiler can't really find most errors, but a domain-specific compiler could. GUIs are a great example, as most of the work is in setting up the layout, and there are generally lots of ways to make syntacticly valid C++ calls that make no sense whatsoever to your underlying GUI system (EG: trying to embed an entire dialog widget inside a button).
I find UIL particularly a huge gain for GUI development because a UIL compiler can find errors in a GUI specification that just look like nice normal compilable code to a C++ compilter. The fact that it is well-supported means that the code is easy to port between platforms, and even GUI builders.
Что ж, кто-то должен это сказать, так что вот оно:
Lisp рассматривается some в качестве предметного языка для любого домена . При этом хорошо поддерживаемый и очень расширяемый DSL.
В некоторых случаях создание DSL из Lisp (или подобного языка, такого как Haskell) могло бы фактически обеспечить большую мощность с минимальными усилиями и, таким образом, было бы вполне оправданным. DSL не всегда требует значительного обслуживания.