アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
争点 (スコア:1, 興味深い)
uim側の最大の不満は、IIIMFのセキュリティの弱さだったのだろうか。
(でも、IIIMFのサーバをuserで動かせば良いだけのような気がしたり)
それとも、設計の汚さ?
プロジェクトが欧米主導で進められていることに対する感情的な問題の方が、
大きかったりするんではないかと言ってみる。
Re:争点 (スコア:1)
> Bad Design賞を差し上げたいような作りになっていますが、
とゆーことで、設計の汚なさなのでは。(中を見たわけではないので、どこがどうマズいのかは判断が付きませんが)
> プロジェクトが欧米主導で進められていることに対する感情的な問題の方が、
んー、主導している人は日本人 [openi18n.org]なので、そーゆー問題ではないのではないかと。
確かに所属企業はSunとかIBMとかRedhat
Re:争点 (スコア:1)
とりあえず、このXMLらしきもの [gnome.org]は悪寒がしました。
あとはシンクライアントを前提としたclient/server設計になってるところとか。
具体的な問題は中身を読んでないの
Re:争点 (スコア:0)
単なる疑問なのですが、何故悪寒がするのですか?
Re:争点 (スコア:2, 参考になる)
XML形式で実装してるようですが、これが酷い仕様だからです。具体的に問題点を挙げると、
・醜い
CやJavaやSchemeなどの既存の言語と比べると非常に見にくいです。
<lt></lt>が不等号の「<」とかいうのは想像付くのですが、これで何かプログラムを書けと言われたらキレます。
・XMLらしくない
とりあえずプログラミング言語らしき部分は目をつぶるとしても、それ以外の箇所も酷いです。
<deftable name="romakana" from="mtext" to="mtext"></deftable>でローマ字→ひらがなの対応を定義
Re:争点 (スコア:1)
ソースコードの見やすさがアスキーアートによって制御されている状況はもう古いと思います。いいかげんモデルとビューを分けるべきです。
EclipseやMathematicaやSqueakやVisualStudioのような統合開発環境がビットマップディスプレイ上に見やすく整形して表示すればいいだけの話です。実際Mathematicaは数式を綺麗に表示してくれます。それでいながら数式の構造を厳密に知りたいと思えば"関数名[引数]"の形で表示させることもできます。
C++でテンプ
Re:争点 (スコア:1)
> XMLらしくないというのは同意ですが、醜いというのはスタイルシートでどうとでもでき得ることでは。
> いいかげんモデルとビューを分けるべきです。
発
Re:争点 (スコア:1)
「生のXMLの文法がプログラミング言語に向いていないのでXMLでプログラムを書くアプローチは酷い仕様である」
ということに対する反論、さらに
「逆にスタイルシートを使うことを前提とすればXMLでプログラムを書くことは多くのメリットがある(『メリットはほぼ皆無』などではない)」
ということです。
>発言が矛盾してますよ。
いや、XML部分(モデル)はアルゴリズムを記述するのに専念してソースの読みやすさなどのビューの部分はスタイルシートで調整しろという意味です。
現状ではソースコードにアルゴリズムと
なんというか (スコア:0)
それとXMLでプログラムを書くアプロー
Re:なんというか (スコア:1)
Re:なんというか (スコア:0)
なんか微妙に軌道修正してるような。
> 問題はPCELや似たような言語の設計が酷い仕様と言えるかどうかです。
構造化すべきところが構造化されていない時点でダメヴォキャブラリ確定でしょうに。
Re:なんというか (スコア:1)
「XMLらしくないというのは同意」と最初から言ってまして、問題はXMLをベースにしたプログラミング言語が良いかどうかです。
Re:なんというか (スコア:1, 興味深い)
ずいぶんもりあがるもんですねぇ。なんだか重箱の隅という気もしますが。
## この分ならdefpatternなんて出したら、もっと大騒ぎされそう。
面白いから続けてみましょうか。
実は、私も、deftableを考えるときに、
1 ... <item><key>K</key><val>V</val></item>
2 ... <item>K V</item>
3 ... <key>K</key><val>V</val>
4 ... K V
の場合を検討してみた記憶があります。
3はまず最初に却下されることになりました。
XPathのツリーモデルでも何でもよいので、deftableの内容モデルを木構造で考えて
見ます。すると、key要素とval要素が内容モデルでリストとしてぶら下がっている形になります。
S式で書いたほうがよければ、((key . K)(val . V)...)みたいなイメージかな。
属性リストの変形みたいな感じですね。この方式のメリットは、せいぜいK, Vに型情報を
与えることができるぐらいなんですが、それなら、1のほうがよほどメリットがあるでしょう。
1, 2は、ほとんど連想リストと同じ構造です。
4は、ほとんど属性リストと同じ構造をしています。
そういうわけで、まぁ、はじめは1がよいかなと思ったわけです。
で、1で実際のテーブルを書いてみました。数千個の漢字テーブルを作って
みたところ、サイズが大きく膨れ上がってしまいました。
(XMLを採用した時点で、そんなことは諦めろとかいわれそうですが。)
ただ、deftableは、deftableは偶数番目と奇数番目の型がすべて一致する必要が(実装のために)
あるので、正直なところ1は冗長な気がします。また、keyにはidentity constraintが必要なので、
さらに、ここで一つ一つに型情報を入れたところで「正しい」deftableを構築する役には、
XMLとしての情報がそれほど有用とはいえません。結局のところ、PCEL定義の型情報を
必要としてしまうのです。
すると、一番シンプルな4を採用してもそれほど問題はないだろう。なにしろ、属性リストは
何年も利用されているリスト構造です。また、空白でリストを作るのは別にXMLでは非常に
一般的な方式で、コンセンサスも十分に得ている表現でしょう。
というわけで、4をとりあえず実験的に採用しました。
異論はあるでしょうけど、これはそれほど悪い判断でしょうか?
ちょうど偶数個を強要するリスト構造は気持ち悪い?
とはいえ、こういうパターンは、RELAX NG tutorialでも例に
挙げられているんです。
まぁ、こういう空白によるリスト構造は許せないという人はいるんですよね。
「XMLで文字列内に構造を作る」というのは確かにad-hocな側面もあります。
(RELAX NGでも、少々ややこしい扱いになってますし)
実のところ、私はそういう人の気持ちもわからないでもないです。でも結局、
重要なのは、コンセンサスを得た利用方法かどうかということですね。
「XMLらしい/らしくない」というトピックは、すさまじくcontroversialであることは、
某標準化団体を見ていれば疑問の余地はないでしょうね。
ところで、実用的な面からも、4にはdrawbackがないわけではないですね。
何だと思います?
そういうわけで、今どうするかと聞かれれば、keyやvalを属性で表現することを
選びそうです。<item key="" val=""/>というように。
from himi