しらたまのコミッタ日記

2011-04-20

[]OSC神戸2011 01:58

参加してきました。

私は午後からの参加でしたが、はあまりなでしこユーザーの方はいませんでした。

しかし、紹介&説明の中で興味を持っていただいた方は多かったので、まだまだこういったイベントでアピールするのは有効だなと感じました。

特に、オフィス連携の機能の食いつきが良かったです。また、文法機能に興味を示されることも多くありました。

#来場者の中に高専の先生がおられて、少し驚きました;;

 

説明の中でなでしこ2をC#作成していることを言うのですが、まだβ公開などが出来るほどモノがないので、開発協力していきたいところです。

ただ、のためには仕様や構成について、もっと細かく定めておく必要あると思います。

いうわけで、以下、なでしこ2のしようについて話したことと、個人的所感など。

オブジェクト指向

参加者の中で話した限りでは、「あった方がいい」のではないかという見方でした。

私も、「あった方がいい」の立場です。

ただし、出来る限りの仕組みは、普通に使っている分には(特に初心者には)、見えないようにしてあるのが望ましいと考えます。

なぜなら、開発MLでも指摘されているように、初心者にとっては取っつきにくいものと感じてしまう可能性があるためです。

しかし、完全にオブジェクト指向的なものを排除してしまうと、ある程度プログラムを書けるようになったとき、

処理をまとめようとするときなど手続き的な仕組みだけでは物足りなくなって、なでしこから離れていってしまうことが懸念されます。

*加筆するかも*

名前

のなでしこでは基本的に名前はファイル単位でしか存在しません。

私は、これに加えて少なくともプラグインごと、出来れば各プラグインの命令ごとに必要だと思います。

利点としては、例えばデータベースやオフィスなど、対象と接頭語が違うだけで意味は変わらない命令群などは、

接頭語を削除して定義し、名前を指定するようにすれば、名前を変えるだけで、まとめて動作を変えられて便利ということがあります

また、接頭語が削除されることで命令が普通の動詞っぽくなって日本語らしさ向上すると思います。

グループでも代用できますが……

コードの形式

コード生成の難易度は上がりますが、MSILで出力するのがよいかと思います。

独自コードの方がコード生成自体の手は下がりますが、実行系は.NET/monoに投げられます。

これらに投げれば、少なくともWin/Mac/Linuxでは一通り動きます。レンタルサーバでもVPS(月1000程度)ならmonoでいけます。

デバッガ

現在デバッガはvnako組み込みとなっていますが、ここは世の開発環境にならってエディタ側に組み込むべきだと思います。

利点としては、以前に少し話題になったexeに固めたけどデバッグウインドウでソースが見えるということが無くなります。

また、実行ファイル組み込みではそれぞれの実行ファイル(cnakoとか)でデバッガを作らなければなりませんが、エディタ側だと1作ればOKです。

ブレークポイントの処理の対応も取りやすいですし、エディタ組み込みにしない手はないと思います。

エラー処理

現在のエラー監視では、エラーメッセージから、どの命令でエラーが起きたのかわかりにくい・finallyに相当する物がないいう不便な点が存在します。

これを解消するために、エラーオブジェクトかエラー番号の導入と、finally節を導入した方がいいと思います。

例:

エラー監視

  「」でエラー発生

エラーオブジェクト1のエラーならば

  「エラー2」と表示

エラーオブジェクト2のエラーならば

  「エラー2」と表示

最後に

  「監視から抜けます」と表示

文字列と(二次元)配列の関係(変換)

A=「1,2,3,4

5,6,7,8」

Aの変数型確認して表示#=>文字列

A[0]を表示/*=>1

2

3

4

*/

Aの変数型確認して表示#=>配列

文字列からの各種自動変換は便利なのですが、たまにとまどう挙動を見せます。

文字列<=>配列の例では、文字列Aの一行目を取得しようとA[0]とすると、2次元配列に変換され、Aは以降配列として扱われてしまいます。

ここでさらに「Aを表示」などとすると、最初にAへ代入したもの次第で、微妙に文字列に戻したときの表示が異なってきます。

これを抑制するため、この自動変換をオプションで切り替えられるようにした方がよいと思います。

(デフォルトをどちらにするかは更に議論する必要あると思います。)

インデクサ

グリッドへのアイテム設定がデータ全部をセッターで設定するようになっているため、毎全部のデータを更新していて効率が悪い上、グリッドの選択位置がリセットされてしまいます。

なのでインデクサのような仕組みを用意し、ゲッターセッターの先が配列のようなものでも、個別に値を取得設定できるようになったら便利かなと思います。

例:

A実体とは配列

●A設定(V,I)

 A[I]=V

●取得(I)

 _=A[I]

Aとは配列 ←A設定 →A取得

A[1]は100

文字列の中のインデント無視

インデントされた行で複数行の文字列を書く場合、2行目以降で先頭のインデントを削除しないといけないので、少々見づらいです。

  「あああ

いいい

ううう」と表示

これを、一行目と同じインデントの分の白は2行目以降でも無視するようにすると、多少なりとも見やすくなるのではないでしょうか。

エディタの自動インデント挿入とも相性が良いはずです。

  「あああ

  いいい

  ううう」と表示

 

余談ですが、ヒアドキュメントって私の手元のメモでは「元々改行含めた文字列がいけるからいらない?」って書いてありますけど、実装されていますね。

まあ、かぎ括弧含む文字列には有効ですが。

ハッシュのアクセス

ハッシュへのアクセスである@は左辺に変数しか取ることが出来ません。

これを拡張して、左辺に式が来てもハッシュへのアクセスと見なすようにした方がいいのではないかと思います。

そうすると、「A@B@C」を「(A@B)@C」と解釈可能になるので、ハッシュハッシュが実現できます。

さらに配列へのアクセス[]も左辺に指揮を執れるようにすると、「(A@B)[0]」のように配列へのハッシュも実現できます。

ゲッターセッター変数での「それ」の変更

ゲッターセッター変数関数と同じように動作していますが、使い方は普通の変数と同じなので、

普通の変数のつもりで使うと、ゲッターセッター変数の参照のあとで「それ」が書き換わってしまうので、「それ」が変わらないと思いこんでのうっかりミスに繋がる可能性があります

これをなくすために、なんとか普通の変数と同じように「それ」が書き換わらないように出来ないものかと思います。

akaginoyamaakaginoyama2011/04/20 09:10OSC神戸2011お疲れ様です。
ここに書かれてあることには激しく同意です!!

改行をそのまま配列にするモードと
CSVなどの利用する際にシンプルに処理できるように
明示的に配列の区切り文字を選べるモードなどの切り替えなどもあれば良いと思います。

200612
200701020304050708101112
20080103040506070912
200904
20100204
201104