問題タブ [boo]

C# では、コンストラクターを連鎖させたい場合は、これを行います...

Boo の同等の構文は何ですか?

最近、Ayendeの本Building DSLs in Booを購入しました（購入して読んでください。すばらしいです）が、実装の問題が発生しているので、生成されたコードがどのようになるかを確認したいと思います。私は通常、リフレクターを使用してコードを確認しますが、この場合、アセンブリは動的であり、メモリ内にのみ存在します。動的アセンブリをディスクに保存して、それらを反映できるようにする方法はありますか？

編集/私の答え：

うわー、これに戻るのに少し時間がかかりました。残念ながら、私は元の質問から重要な部分を省きました。

重要なビット：本で推奨されているように、私はAyendeのRhinoDSLライブラリを使用しています。DslEngineのサブクラスにあるbooコンパイラにアクセスできます。これは次のようになります。

最小限の変更で必要なものを取得するには、1行追加する必要がありました...

これにより、コンパイラはアセンブリを〜\ LocalSettings \ Tempディレクトリに出力し、それを反映することができました。この変更を行うと、プログラムの残りの部分が破損することに注意することが重要です（RhinoDSLは、アセンブリをディスクに出力したため、メモリ内のアセンブリを見つけることができなくなりました）。したがって、これはデバッグツールとしてのみ役立ちます。

以下が有効な Boo ステートメントである状況はありますか。

どこでtargetマクロrequires/メソッド/その他のもの（キーワードを除く）にすることができますか？
これは DSL の質問なので、コンパイルできる限り、どの言語ハックでもかまいません。

私は.NETで作業しています（具体的にはBooですが、答えはC＃でも機能します）、コマンドライン内に編集可能なボックスを作成して、出力のセクションを上部に表示できるようにする方法を知りたいですコマンドラインで、irssi プログラム (IRC クライアント) と同じように、下部に入力用の 1 行のボックスがあります。

これは .NET で可能だと思いますが、どのようにアプローチすればよいでしょうか?

私はBooが初めてで、ハッシュのタイプを宣言する方法を理解しようとしています。私がする時：

コンパイラは、「メソッドはオブジェクトのメンバーではありません」と不平を言います。ハッシュの値の型がわからないことがわかりました。

文句を言わないように、ハッシュのキーと値の型をコンパイラに宣言する方法はありますか?

私はBooでネストされたマクロを作成しています、私はこのプログラムを書きました：

しかし、コードの3行目に「UnknownIdentifer：' text '」というエラーが表示されます。

私はBooを見てみましたが、それはかなり素晴らしいですね! この段階でどれだけ安定しているか気になりますか？つまり、実際の本番コードで使用することを検討していただけますか?

Boo を含むリファレンスを更新しようとしています。Binsor をコンパイルすると、大量のエラーが発生します。これを 1 つずつハッキングしています。多くのソースの参照とグーグル検索の後、次の行 ( TransformUnknownReferences.cs、行 115)を修正する方法がわかりません。

リビジョン 3260のExternalConstructorコンストラクターは次のとおりです。

TypeSystemServices がどこから来たのか、Binsor コードのこの時点から IReflectionTypeSystemProvider に到達する方法がわかりません。Binsor および/または Boo の深い知識を持っている人が簡単な修正方法を知っている場合は、声を上げてください :)。

さらに良いのは、過去 6 か月間にコードが更新された、ある種の非表示の Binsor リポジトリです。

私はDSLを書いたことがありませんが、それを新しいプロジェクトの機能として考えています（架空）。エンドユーザーは、月の最初の月曜日を除いて、平日10〜11などの自然言語の概念で表現できるようになります。

オランダのユーザーは、op de eerste maandag vandemaandに代わってweekdagentussen10en11と書くかもしれません。この場合、単語の位置は一致しているように見えますが、言語によって動詞や名詞などの位置が異なる表現がある場合があります。

私は明白な答えを理解します（それは異なります）。私は.NET開発者であり、Booの使用を検討していますが、提案を受け付けています。各変換で実装の一部（どの部分）を書き直す必要があるのか​​、または実際の変換を行う方法がある場合は、おそらく何らかのプリプロセッサで行う必要があるのか​​を理解する必要があります。

さまざまなクライアントに展開するためのASP.Netアプリケーションの構成を管理するのに問題があります。調整が必要なさまざまな設定の膨大な量には多大な時間がかかり、現在の構成方法は複雑すぎて、この責任をサポートパートナーに押し出すことができません。

これを処理するためのより良い方法、または調査するための優れた情報源についての提案はありますか？

現在のやり方：

• AppSettings.xmlなど、Web.Configで参照されるさまざまなxml構成ファイル。
• 特定のサイトの構成は、重複した構成ファイルに保持されます。
• サイトに固有のデータのリストを含むテキストファイル
• 場合によっては、データベースへの手動による1回限りの変更
• Windsor IOCのC＃構成。

私たちが抱えている特定の問題：

• さまざまな機能が有効になっているさまざまなサイト、話し合う必要のあるさまざまな外部サービス、さまざまなビジネスルール。
• さまざまな展開タイプ（ライブ、テスト、トレーニング）
• 構成キーはバージョン間で変更されます（追加、削除）。つまり、重複するすべてのファイルを更新する必要があります。
• アプリケーションの実行中にキーを変更できる必要があります

これにどのように取り組むかについての現在の考えは次のとおりです。

• 構成を動的にコンパイルされたコード（おそらくBoo、Binsor、またはJavaScript）に移動します
• 何らかの形式の差分/マージ構成があります。デフォルト構成をライブ/テスト/トレーニング構成およびサイト固有の構成と組み合わせます