問題タブ [oslo]

.NETコミュニティ（ala Qi4j ）内のCOPについては、過去1年間にある程度の関心があったようです。数人の人々が独自のCOPフレームワークを導入しており（以下のリンクを参照）、.NET4.0のDynamicDispatchとMEFが.NETCOPフレームワークで潜在的な役割を果たしているように見えます。

一方で、これの多くはSystem / 38日からのアイデアを思い起こさせるように見えます（はい、私は老人です）が、他方では、オスロ（モデリングとリポジトリ）にもかなり適しているようです）。MicrosoftがCOPに取り組んでいるかどうかについて誰かがコメントできますか？

最近の.NETCOPフレームワークの取り組み：

HendryLuk-あなた自身のCOPをロールバックする

YvesGoEleven.com-警官-概念実証

AndersNorås-トリックまたは特性？C＃を使用した複合指向プログラミング

MagnusMårtensson- Unityアプリケーションブロックでの複合指向プログラミングの急増

従来のシステムでは、独自の VM を作成して実行時に内部 DSL を実行していました。社内 VM は、社内 DSL のみを実行するように設計されています。現在、レガシー アプリケーションを書き直しています。私たちが検討しているアイデアの 1 つは、内部 DSL を外部 DSL (C# または Java) に変換し、その VM を利用することです。

内部 DSL 用に独自の VM を作成する場合と、外部 DSL に変換してその VM を実行する場合の明確なガイドラインはありません。

私が Oslo で見てきたことによると、宣言型 XML が重要な役割を果たします。実際のアプリケーションを作成するために、多くのデザイナーが生成した XML をいじることは期待できますか? 私がこれを研究していないことを知ってください。あなたが主題を調べたなら、私はあなたの視点に感謝します.

いくつかの背景...

XML を利用した宣言型テクノロジ (Silverlight や WPF、ASP.NET、MSBuild など) の真下を掘り下げると、生の XML テキストを大量に編集することになります。デザイナーが私のニーズを十分に表現してくれることはめったにありません。

一方で、人間と機械の可読性の間で妥協点が改善されているとは思えません。公平を期すために言えば、XML 編集のエクスペリエンスは、具現化するたびに改善されています。

一方で、XML がその用途のいくつかに理想的であるとは思いませんでした。特にロジックの表現、リファクタリングとテスト容易性に関しては。デザイナーが弱すぎるか、XML の表現力が強すぎるか、または私が不機嫌すぎてオブジェクトやメソッドに甘やかされている可能性があります。

Microsoft Oslo SDK CTP 2008 (Intellipad を使用) では、次のコードは正常にコンパイルされます。

以下のコードをコンパイルすると、「M0197: 'Text' は Type コンテキストでは使用できません」というエラーが発生します。

最初のケースでは Text が Type コンテキストでも使用されているため、これらの例の違いはわかりません。

アップデート：

混乱を招くために、次の例を考えてみましょう。これも問題なくコンパイルされます。

M 言語仕様には、次のように記載されています。

フィールド宣言は、レキシカル スコープをオーバーライドして、宣言の型が宣言自体にバインドされるのを防ぎます。フィールド宣言の割り当てられた型は、宣言自体であってはなりません。ただし、宣言は制約で使用できます。次の例を検討してください。

タイプA; タイプ B { A : A; }

フィールド宣言 A の型割り当ての字句的に囲んでいるスコープは、エンティティ宣言 B です。例外なく、型割り当て A はエラーである循環参照でフィールド宣言にバインドされます。この例外により、字句検索はこの場合フィールド宣言をスキップできます。

ユーザー定義型と組み込み (組み込み) 型は同等に扱われていないようです。

更新 2:

上記の例のValueは予約済みのキーワードではないことに注意してください。Valueの名前をYに変更すると、同じエラーが発生します。

何か案は？

よろしく、タンバーグ

Microsoft Oslo SDK CTP 2008 (Intellipad を使用) では、次のコードは正常にコンパイルされます。

次の Reach SQL 出力が生成されます。

ただし、モジュール T のコメント行を次のように変更した後

エラー メッセージ "M2037: SQL Generation Internal Error: Missing generator for variable 'A'" が (Intellipad の Reach SQL ウィンドウに) 表示されます。

何か案は？

よろしく、タンバーグ

カイロで有名な Microsoft は、新しいモデリング プラットフォームである Oslo に取り組んでいます。Microsoft Server & Tools Business のシニア バイス プレジデントである Bob Muglia は、モデリングの利点は常に明らかであると述べています。

簡単で実際的な言葉で言えば、オスロがユーザーに与える明確な利点は何ですか?

Oslo/MI に関する講演に参加した後、既存の方法よりも優れている点と、どのような状況で役立つかを理解するのに少し苦労しています。

私はそれが非常に新しく、すべての詳細が公開されているわけではないことを知っていますが、誰かが私にいくつかの利点を教えてくれますか?

ありがとう、

アレックス

それは DSL 生成ツールですか、それとも自然なクエリ言語ですか?

私は MSchema に Oslo を使用しています。よく働く。データベース設計用の M スキーマを記述でき、T-SQL を生成して PK、FK、整合性チェックなどを含むデータベース全体を構築します。.m を .mx にコンパイルしてロードする .bat ファイルをセットアップしました。それをデータベースに追加し、SqlMetal をプロジェクトに実行すると、30 秒で変更を続行できます。大好きです。

では、mGrammar に進みます。アプリにどのように組み込むかはよくわかりませんが、それを理解します。最初に必要なのは、Intellipad をセットアップして、入力/文法/出力のトリプティクを提供することです。私は困惑しています。フローで設定する方法がわかりません。はい、おそらくsong.mgプロジェクトを取得して名前を変更できますが、それがどのように機能するかについての洞察は得られません。何か案は？

たとえば、実行時にユーザーが既存の型を作成および変更できるアプリケーションを作成できますか? 100,000 レコードを追加し、(本当に) 高速なクエリを期待するユーザーを心配することなく、これらの型のインスタンスを SQL で永続化できますか?

SharePoint コンテンツ タイプを考えてみてください。オスロステロイド - 可能かどうか?