Ognacの雑感

木漏れ日々

目次

Blog 利用状況

書庫

ギャラリ

文字列列挙体がほしい

   public enum 仕訳区分
    {
        出金=0,
        入金=1,
        振替=2,
    }

など、区分値が整数のときは、 enumが重宝します。
でも、区分値が文字のときは、使えません。新規設計ならば、区分値を数値で設計できますが、既存のコード体系が、文字コードで構築されているケースは、如何ともできません。
次のような列挙体が欲しい。
    public enum 仕訳区分
    {
        出金="O",
        入金="I",
        振替="C",
    }

周囲のソースを見ると
const string 仕訳区分_出金="O";
const string 仕訳区分_入金="I";
const string 仕訳区分_仕訳="C";

const string 性別区分_男="M";
const string 性別区分_女="F";

のように、xxx区分の要素を平面的に列挙しているケースが多い。
でも、xxx区分で一塊だから、同格列挙するのは、引っ掛かります。
そこで、

    public class 文字列_列挙体 
    {
        public string Value;
        public 文字列_列挙体(string _value)
        {
            Type t = this.GetType();
            BindingFlags bf = BindingFlags.Static | BindingFlags.Public;
            foreach (FieldInfo f in t.GetFields(bf))
            {
                if (_value == (string)f.GetValue(this))
                {
                    Value = _value;
                    return;
                }
            }
            throw new Exception(this.GetType().Name + "に含まれない値[" + _value + "]でインスタンス化されました");
        }
    }
を作ってみました。
    public class 仕訳区分 : 文字列_列挙体 
    {
        public 仕訳区分(string value) : base(value) { }
        public const string 出金 = "O";
        public const string 入金 = "I";
        public const string 振替 = "C";
    }

使用例

仕訳区分 sk = new 仕訳区分( 仕訳区分.入金);
MessageBox.Show(sk.Value);

カスタム属性で実装する手もありますね。
どちらにしても、野暮ったさが残ります。

文字列Enumが欲しい!!!

投稿日時 : 2010年10月20日 20:33

Feedback

# re: 文字列列挙体がほしい 2010/10/21 10:00 中博俊

同意

# re: 文字列列挙体がほしい 2010/10/21 11:24 aetos

そのクラスを作る必要はあるのだろうか…

public static class 仕訳区分
{
public const string 出金 = "O";
public const string 入金 = "I";
public const string 振替 = "C";
}

でいいんじゃないの…

# re: 文字列列挙体がほしい 2010/10/21 14:06 あおおにくん

1文字限定なら、charでいけると思うのですが

# re: 文字列列挙体がほしい 2010/10/21 14:26 れい

あまり必要を感じません。
必要な場合は私もaetosさんのようなやり方をしています。

const stringだけのクラスを「enum」と表現可能にして開発効率向上を狙ってもよいかとは思いますが、それもあまり好きではありません。

リファレンス型をenumにして向上するのは(分かり易さを含めた)開発効率だけです。
言語仕様としては複雑で無駄が多いかと。

砂糖漬けな言語は浅い理解は早いのですが、原理・原則が見えづらくなるので、深く理解するのに時間がかかります。

便利だから、で言語使用が追加されるのはPerlとかRubyのようなお手軽な言語の方が得意でしょうし。

# re: 文字列列挙体がほしい 2010/10/21 14:49 noname

そういえばフラグ列挙体って使ったことないな。

# re: 文字列列挙体がほしい 2010/10/21 17:32 Oganc

うーん。言語構文として複雑になるのか。
「型重視の言語」という点で、欲しくなります。
ご指摘のように、
public static class 仕訳区分 {.....}
で記述すると、使う側は、

string Kubun = 仕訳区分.入金; と記述することになります。

Kubun はstring型変数になり、「仕訳区分」型ではなくなります。
「Kubunは仕訳区分型である」という制約は、コード上から消えるので、開発者が「Kubun == 仕訳区分型」と意識する必要があります。
そういった事態を避けるために、Enum型があります。
その延長線上に、文字型列挙体があってもよいのでは。...と思うのです。

型重視言語は、型制約はコンパイラーがチェックしてくれるのが大きなメリットてす。
なので、仕訳区分として宣言している変数は、仕訳区分の制約をコンパイラーに認識して欲しい...
無謀な望みなのかなぁ。理由があって却下されたのだろうか。

# re: 文字列列挙体がほしい 2010/10/21 18:54 なし

あおおにくんがすでに書かれてますけど、
1文字限定でしたらこう書けます。
限定できないんでしょうけど。

public enum 仕訳区分
{
 出金 = 'O',
 入金 = 'I',
 振替 = 'C'
}

var databaseValue = ((char)仕訳区分.入金).ToString();
MessageBox.Show(databaseValue);

var value = (仕訳区分)databaseValue[0];
MessageBox.Show(value.ToString());

# re: 文字列列挙体がほしい 2010/10/21 22:31 Pasie.

>同意
 その際には文字列だけでなく是非実数型系もよろしく。

>必要な場合は私もaetosさんのようなやり方をしています。
 私も同じ感じですね。
 あとはGeneric.Dictionayあたりを使って表現したりとか。
 もっとも引数入力時にインテリセンスで一覧を出されるとかは無理なわけですが…

# re: 文字列列挙体がほしい 2010/10/21 22:56 ognac

>1文字限定でしたらこう書けます。
(char)、(仕訳区分)のキャストが必要なのと、1文字限定が...つらいなぁ。

インテリセンスなしもつらいなぁ。
インテリセンス依存になってしまった私。あかんなぁ...orz;

# 文字列列挙体っぽい挙動をするものbeta 2010/10/22 2:05 まさるblog

文字列列挙体っぽい挙動をするものbeta

# re: 文字列列挙体がほしい 2010/10/22 3:05 れい

> うーん。言語構文として複雑になるのか。

構文は簡単ですよね。
仕様と実装が問題になります。

> 「型重視の言語」という点で、欲しくなります。

ただ「便利だから欲しい」という話ではなく、「型重視の言語としてあるべき」と議論するなら…

> 無謀な望みなのかなぁ。理由があって却下されたのだろうか。

そうそう。
理由を議論して、どうしたらいいのか議論したいと思いますね。

実は私も以前考えたことがあります。
(当時はC++でしたが。

おそらく理由は二つ。

一つは歴史的経緯から、enumがただの列挙ではなく、フラグとして使われることも想定している点。
だからsingleやdoubleなど実数型はenumにできない。

もう一つは参照型の状態は固定できないという点。
参照型はいつ、どう状態が変わるかわからないので列挙型にしたらわけがわからなくなる。
だから参照型はenumにできない。

ならばこれらが解決されればいい。
前者は簡単。
enum以外に純粋な「選択肢」型を作ればいい。
例えばselectionというキーワードにしてみる。
後者は「値が変更されない」ことを保証した参照型があればいい。
それはつまりimmutableのことなので、それを言語がサポートすればいい。

そうするとこんな感じになる。

public immutable class flower {
private string _truename;
flower(truename as string) { _truename = truename; }
}

public selection whiteflower {
オシロイバナ=flower("Mirabilis jalapa"),
カスミソウ=flower("Gypsophila"),
サギソウ=flower("Pecteilis radiata")
}

CreateTriColorBouquet( blueflower.スミレ, whiteflower.カスミソウ, redflower.バラ )

これならかなり美しい。
インテリセンスも対応可能でしょう。
コンパイラの型制約もできる。

問題は、immutableをどう保証するかという点。
immutable型のメンバは参照型ならimmutableしかダメ、値型フィールドはprivateで、全プロパティはreadonly。
それでもまだ不十分です。
ある型が真にimmutableであるかどうかを機械的に保証する手はありません。
なので、immutableというキーワードを新たに作ったとしても、それは「制約」にはなりません。
努力目標というか、「コンパイラに対する指示」でしかなくなります。(実際、C++はそうですよね)
それは.Netのコンセプトとは合わない。

またそうなってくると「immutableの列挙型」の意味はインテリセンスしかなくなってしまいます。

それはもう却下ですよね。

あとは言語仕様的に「例外」として文字列の列挙型を許すという手もありますが、それは前述のとおり、過剰な砂糖は体に悪い。

と、そのくらい考えて納得しています。
文句がないわけではないですが。
歴史的経緯とはいえ、フラグと列挙は全く違う概念なのに同じenumを使っているのはいやです。

# re: 文字列列挙体がほしい 2010/10/22 17:35 Oganc

「immutableの列挙型」実装...美しく使えそうな感じを受けますが。ご指摘の問題が残るのですね。
>それは.Netのコンセプトとは合わない。
これに尽きるのか。
参照型要素を列挙対象にすると、動的変更に対応できなくなるので、追跡できなくなるから......文字型変数は、参照型だから却下。
ならば、値型のConstant文字列型 かあれば、可能だったのかも。

C#/VBの switch(変数)文に 文字列を許しているので、明確な区別が灰色になっていそうです。
文字列は参照型なのに "==" 判断可能にしているなど(Javaは不可ですよね) 値型と同様に使える。など
もう十分、砂糖まみれになってる感じがします。
砂糖まみれになって、深く知ろうとしないかどうかは、本人しだいと思うので、「砂糖になるから教育上で不可」というのは説得力に欠けそうに思います。

確かに、フラグとEnumを同居させたのは、よくなかったかも。
FlugAttributeで動作を切り替えるのは、美しくない。

C#/VBでは、stringを継承できません。継承したくなる時がシバシバあります。
参照型でありながら、値型に見せかけてます。解り難くしていますね。これも砂糖の副作用かな。

# re: 文字列列挙体がほしい 2010/10/23 0:00 Pasie.

> immutable型のメンバは参照型ならimmutableしかダメ
 この意見を採るとして、Stringリテラルに限定される場合、可能なように読めますが、その理解でOKですか?

> enum以外に純粋な「選択肢」型を作ればいい。
 結局ここなんですよね。
 選択肢型ほすぃ~

> "==" 判断可能にしている
 オペレーターオーバーロード?
 javaを引き合いに出すなら。javaにしても+で連結できるのもおかしいと思いますが。

> 参照型でありながら、値型に見せかけてます。
 自身がないですが、immutableでNotInheritableなだけではと。

> 継承したくなる時がシバシバあります。
 なんのためにですか?
 sjis型とかeuc型とか?

>参照型要素を列挙対象にすると、動的変更に対応できなくなるので
 すみません、どういうケースを想定されていますか?

>それは.Netのコンセプトとは合わない。
 ここが今ひとつ私がよく分かっていない所なんですが、stackにスカラー型しか配置できなくなった理由ってなぜなんでしょう?つまりなんで配列が置けなくなったのか、ってことですけど。

# re: 文字列列挙体がほしい 2010/10/23 4:20 れい

Ognacさん。
> 「砂糖になるから教育上で不可」というのは説得力に欠けそうに思います。

教育じゃなくて、学習の方です。
砂糖漬けだと原理・原則以外の例外が増えるので、学習速度が遅くなるでしょう。

Heavyな言語の言語仕様で、やる気のある人の学習を妨げる言語仕様はダメ。
やる気のない人でも使える言語を目指すなら軽量な言語にしとけばいい、と。

Pasie.さん。
> この意見を採るとして、Stringリテラルに限定される場合、可能なように読めますが、その理解でOKですか?

む。文章が悪いかな。

「stringは例外としてenum可能」という案は「例外」だから却下。
「immutable型はenum可能」という案は例外じゃないという意味ではOK。
でも、「immutable型」を保証する術は無い。
なので「immutable型はenum可能」という案も却下。

です。

>>参照型要素を列挙対象にすると、動的変更に対応できなくなるので
> すみません、どういうケースを想定されていますか?

例えば。

enum StringBuilderEnum {
aaa = "aaa",
bbb = "bbb"
}

StringBuilder buf = StringBuilderEnum.aaa;

buf.Remove(0,1) 'これはアリ?ナシ?

とか。immutableであっても…

enum WellKnownUri {
google = new Uri("http://google.com")
myservice = new Uri("mymethod://mydomain.com")
}

OKかと思いきや。
UriParserのオプションを変えて、「末尾のスラッシュ」の意味などを変えたらもうEqualityが成り立たなくなります。
UriParserがimmutableだっとしても、初期化の順序とかで結果が変わってしまう。


>>それは.Netのコンセプトとは合わない。
> ここが今ひとつ私がよく分かっていない所なんですが、

「immutable」と宣言しても、immutableを保証できないわけです。
一部の制約キーワードは制約ではなく実装次第になってしまうのは厳密な型制約がある言語体系としてはダメでしょう。
ILでも実装できない。

> stackにスカラー型しか配置できなくなった理由ってなぜなんでしょう?つまりなんで配列が置けなくなったのか、ってことですけど。

あれ。
話が通じていませんね。
ILの話でしょうか?
ILなら配列のリファレンスをstackに置きますよね?
それと今の話となにか関係あるのかしら?

# re: 文字列列挙体がほしい 2010/10/23 23:18 ognac

>javaを引き合いに出すなら。javaにしても+で連結できるのもおかしいと思いますが。
そう。javaも同様に、砂糖構文な気がしています。

>自身がないですが、immutableでNotInheritableなだけではと。
>継承したくなる時がシバシバあります。
string変数を通常変数のように見せかける、糖衣構文だとおもいます。
strjngが継承可能ならば、
class 仕訳区分: string
{
制約一杯
}
制約付文字列 が作れる

同様に 整数系型が継承可能ならば
class 月 : byte
{
1~12の制限
}
などが可能になれば、いいなぁと思ったりします。

# re: 文字列列挙体がほしい 2010/10/23 23:27 Pasie.

>ILでも実装できない。
 何となくこれでわかった気がする。
 仮にCのStructのようなものであったら、可能なんですかね。もちろんメンバに参照が含まれないと仮定して。
 参照があるとすると、参照先がかえられうるから不可能だという意味でOKですか?

>ILなら配列のリファレンスをstackに置きますよね?
 まじでー(汗
 すんませんILは全く勉強していないんです。すみません(汗

>それと今の話となにか関係あるのかしら?
 ないです。.Netのコンセプトってところに便乗しました(汗
 固定長文字とか固定長配列とかstructをそのままバイナリ化とか、たまにあったらいいなと思うことが封じられているのでその辺の理由を正確に把握していないなあと(私が)

# re: 文字列列挙体がほしい 2010/10/23 23:35 Pasie.

> 制約付文字列 が作れる
 邪道だー(笑
 少なくともオペレーターオーバーロードが砂糖漬けだという人はこんな意見いっちゃだめかと(笑

# re: 文字列列挙体がほしい 2010/10/24 1:00 ognac

>少なくともオペレーターオーバーロードが砂糖漬けだという人はこんな意見いっちゃだめかと(笑
>教育じゃなくて、学習の方です。
うーん。二律相反しますね。
初学者は、最初のハードルが凄く高く感じるので、
砂糖は必要でしょう。
 それ以後のハードルを越える技量が必要か?
Heavy開発者は、自力でも習得するでしょうし、
個人的偏見ですが。
単なる事務的開発者は、糖衣構文が喜ばますし、それ以上を望んでいない人も一定数います。開発会社もそれを前提にしている面あり、構造的な不条理を孕んでいます。
 C#以上に、VBは甘くなっています。一般開発者に技量を求めることの是非は現場では永遠の課題だと思っています。
でも、GCを意識しなくなった時点で、砂糖まみれになっている気もしますが。(実際、楽ですものね)
糖衣の定義設定も人それぞれなんでしょうね。

# re: 文字列列挙体がほしい 2010/10/24 3:33 れい

あれ。
コメントしたつもりが消えちゃってる。

テスト。

# re: 文字列列挙体がほしい 2010/10/24 3:34 れい

書き込みができない…

Pasie.さん。
> 参照があるとすると、参照先がかえられうるから不可能だという意味でOKですか?

Yes。
でも「参照」と何回も言いましたが、値型でもプリミティブじゃないものはダメなんですよね。
例えば構造体。

> 仮にCのStructのようなものであったら、可能なんですかね。もちろんメンバに参照が含まれないと仮定して。

構造体はメンバの一部を変更できてしまいますから、ダメです。
それにC#やVBは構造体のコンストラクタがないからどうやって初期化したらいいかわからないし。

# re: 文字列列挙体がほしい 2010/10/24 3:35 れい

NGワード一覧が無いと書き込みがつらい…

Ognacさん。
> string変数を通常変数のように見せかける、糖衣構文だとおもいます。

NotInheritableでimmutableを糖衣というのは違うかと。
型制約ですから、クラスベースObject指向の本質かと。
楽にはなりますが、それをすべて糖衣というなら、Object指向すら糖衣でしょう。

そこに本質的な意味があるかどうかで糖衣かそうでないか決まると思います。

ですので、GCは糖衣ではない。
自動プロパティは糖衣。

# re: 文字列列挙体がほしい 2010/10/24 3:37 れい

> 同様に 整数系型が継承可能ならば
これはダメかな。
byteから月を派生したら、「月 is byte」が成り立たなくてはならない。
それをするくらいなら「月」型とbyte型の間に暗黙の変換を定義すべき。

# re: 文字列列挙体がほしい 2010/10/24 3:41 れい

> 制約付文字列が作れる
この発想もおかしいかな。
文字列型がimmutableなままだとするなら、その制約を課すためには
RestrictedStringCreator( string str )
みたいなメソッドを作って、その中でチェックすればいいだけです。
一度作られた文字列は変更されないので制限できます。

もし文字列型をimmutableでないと仮定しているなら、StringBuilderを継承して同じ目的のクラスが作れます。
StringBuilder.ToString()でチェックでもすればいいですよね。

いずれにせよ、そんな継承は要りません。

> 初学者は、最初のハードルが凄く高く感じるので、
> 砂糖は必要でしょう。

NotInheritableを糖衣というなら、その糖衣は必要ですが、それは糖衣ではないと私は思います。

例えば、自動プロパティが糖衣です。
便利ですが、覚えていなくても問題ありません。
これは無くても学習速度は変わらない。
むしろ早くなります。

# re: 文字列列挙体がほしい 2010/10/24 3:41 れい

「O r i g i n a l」が書き込めないのか…

# re: 文字列列挙体がほしい 2010/10/24 11:33 ognac

>NGワード一覧が無いと書き込みがつらい…
同意。
でも、NGワードを公開すると、逆利用する人も出てくるし、痛し痒しですね。

>楽にはなりますが、それをすべて糖衣というなら、Object指向すら糖衣でしょう。
>ですので、GCは糖衣ではない。
私自身の「糖衣」の規定(使い方)が揺らいでますね。
 言語仕様の根幹に左右するかどうかで決めるなら、その通りですね。
「楽になる構文」を糖衣と称したから混乱しましたね。別の用語ってないかなぁ(広義の糖衣とするとヤヤコシイし)


>自動プロパティは糖衣。
記述の簡略化と見て、糖衣か。
delegage記述で メソッド = new delegate(割り振りメソッド) ; が  メソッド = 割り振りメソッド と記述可能にしたのは、糖衣ですか。

>もし文字列型をimmutableでないと仮定しているなら、StringBuilderを継承して同じ目的のクラスが作れます。
StringBuilderは継承できないですね。
自分のコードでカバーするか、基礎型に依存するかの基準を自覚する必要がありますね。

>NotInheritableを糖衣というなら、その糖衣は必要ですが、それは糖衣ではないと私は思います。
>便利ですが、覚えていなくても問題ありません。
その分類方法、面白い。
私の感覚では、 GCを搭載して、メモリ解放処理を、不要にした時点で、開発者に砂糖環境を与えたと思ってしまいます。
車のオートマティック免許も砂糖漬けの印象が拭えません。(話がずれるので、別エントリーで)

>「O r i g i n a l」が書き込めないのか…
知りませんでした。

# re: 文字列列挙体がほしい 2010/10/24 22:34 Pasie.

 さて、糖衣構文マンセーな私がきましたよ、と。
 でもねでもね。糖衣構文の定義がはっきりしない中で言うのもなんですが、
 > 自動プロパティが糖衣です。
これって糖衣ですか?VB2010だと、
 > Public Property AAA As Integer
 >
 > Public Function GetAAA() As Integer
 >   Return (_AAA)
 > End Function
というコードが通るんですね。いつ _AAA を宣言したというのか!こういうのは糖衣ですらなくて、自動(勝手に)コード補完に類する機能なんじゃないかと思うわけですが…
 なんかPropertyの記述が楽になったと思った次の瞬間に、暗黙の変数宣言がセットってのに激しく落胆した私がいます…

# re: 文字列列挙体がほしい 2010/10/24 22:54 Pasie.

 ところで糖衣というと、Property構文、は糖衣なんでしょうか?

 あとGCは糖衣ではなくて手法のひとつだと思います。
 なぜなら、GCを糖衣というと、参照カウントだって糖衣だし、スタックだって糖衣ですよね。
 まあ少なくとも、糖衣"構文"では決してないかなあと個人的には思います。

# re: 文字列列挙体がほしい 2010/10/24 23:05 Pasie.

れいさん。
>構造体はメンバの一部を変更できてしまいますから、ダメです。
 うまく伝えられていないところがあると思ったので、もう一度。
 そんな処理系は現在ないというのは承知で。。
 構造体のメンバーが全て参照のない値で、その値を定数としてコンストラクタで与えられる(というか直にスタックないし静的領域に積む)ことが可能であるとして。
 そしてそのメンバーの値は変更不可であるとして。

 それでも構造体って不可ですか?

 個人的には構造体はどうでもよいのですが、Stringを参照の仲間だしプリミティブじゃない、という表現がひっかかるんですよね。
 現在の言語系の実装方法はともかく、Stringは本来プリミティブなものなんじゃないですか?というのが私の主張で。
 もしこれをプリミティブでないと言われると、プリミティブって私の意識ではBinary(0or1)になってしまうし、少なくとも32bitCPUの64bit長データはプリミティブじゃないかも知れない。
 .netのchar型のようなものもプリミティブじゃなくなってしまう。(現時点でenumにならないからプリミティブじゃないという判断か…?)

# re: 文字列列挙体がほしい 2010/10/25 8:40 れい

Ognacさん。
> StringBuilderは継承できないですね。
うぎゃ。
でも意味は通じてますよね。
StringBuilder相当のクラスを作ればそれでいいわけです。

> 私の感覚では、 GCを搭載して、メモリ解放処理を、不要にした時点で、開発者に砂糖環境を与えたと思ってしまいます。
> 車のオートマティック免許も砂糖漬けの印象が拭えません。(話がずれるので、別エントリーで)

それは「抽象化」もしくは「仮想化」、「カプセル化」であろうと思います。
「低レベル層を知らなくていい」ことと、「より簡単に見えて使いやすい」ことは別。

Pasie.さん
> 自動(勝手に)コード補完に類する機能

それも糖衣でいいのでは?
コード補間で且つ糖衣。
包んで中で勝手に書いてくれてる。
甘い。

> ところで糖衣というと、Property構文、は糖衣なんでしょうか?

当然この話題になりますよね。

Propertyがない時代は自分でマクロ等を使って作っていました。
これはGetやSetというメソッドを包んだ糖衣。
でも、人はそこにプロパティという「意味」を与えていた。
マクロで「プロパティ」を包んでいたわけじゃないのに注意。

で、その「意味」も含めて言語がサポートした。
なのでPropertyは本質的な意味を持ってる。
糖衣ではない。

と理解しています。
糖衣したことで意味が分かったり、生まれたりすることもあるでしょうし、実際に意味があるかどうかは人次第な所はありますが。

> それでも構造体って不可ですか?

immutableが保証できるなら選択肢型の基底に成れてもいいと思います。

> Stringは本来プリミティブなものなんじゃないですか?というのが私の主張で。

うーん…。
私の認識では。
「プリミティブ」は実装を考慮しない場合は意味がない単語なのだと思います。
形而下の話。
なので…

>実装方法はともかく
実装方法がないなら意味がない。
> Stringは本来プリミティブなものなんじゃないですか?
「本来」という単語は形而上を指すのでプリミティブには当てはまらない。

Pasie.さんは「プリミティブ」を「原子性」(atomic)や「immutable」と誤読しているのではないかと。

選択肢型として必要なのは「等しいことが確実に判定できる」ことでしょう。
(場合によっては「唯一に等しい」というのを要請したい気もします)

値型であろうと参照型であろうと、ちゃんと初期化できて値が勝手に変わったりしないようなObjectであれば「等しいことが確実に判定できる」ので、選択肢型の基底になってもよいかと。

それって「本来」immutableですよね。
値型がどうのこうのとか、スタックがどうのこうのは関係ない。

intもcharも捉え方を変えればimmutableですよね。
int i=1;
i = i+1;
このiはもう「別のobject」と取ることもできます。
でも、
Pair p = new Pair(a,b);
p.A = c;
このpは別のobjectではありません。

Pasie.さんの言う「プリミティブ」の定義がよくわからないのですが、「immutable」なのではないでしょうか?

# re: 文字列列挙体がほしい 2010/10/25 10:30 Oganc

>でも意味は通じてますよね。
ええ。通じてます。

>それは「抽象化」もしくは「仮想化」、「カプセル化」であろうと思います。
>「低レベル層を知らなくていい」ことと、「より簡単に見えて使いやすい」ことは別。
・砂糖構文: 機能は同等で、 煩雑な構文を単純な構文で記述する。
・砂糖漬 : 原理原則をしらなくても、動作仕様を満たす構文
私は、この二つを、混同して使ってましたね。
 どちらも、原理原則を知っていて欲しい開発者とっては、マイナス面は感じます。

砂糖漬に関して
 原理原則を知らなくても済む開発者にとっては、プラス面が多い。
VBとC#は、この点で進化の方向が違ってきているように思います。
Visual Studioなどの IDEの自動生成機能が充実しているので、穴埋め問題式にコーディングするスタイルが一部では定着しています。
そうしないと、底辺が広がらない。
レベルを上げるには、底辺を広げないといけないだろうし。
文化の浸透の流れのような感じかなぁ。

●文字1.equals(文字2) を 文字1 == 文字2
と書けることを、砂糖構文と書きましたが、字面をみると、そう見えますが、 演算子OverLoadで実装している、実装事情からみれば、別機能なので該当しないようにも思えます。
文法面での、砂糖構文と、機能面での砂糖構文的な文は、ややこしいですね。

# re: 文字列列挙体がほしい 2010/10/25 11:17 れい

> ・砂糖構文: 機能は同等で、 煩雑な構文を単純な構文で記述する。
> ・砂糖漬 : 原理原則をしらなくても、動作仕様を満たす構文

この辺の語彙、以前調べたのですが、ずいぶん古い言葉のようで、初出や本来の意味はよくわかりませんでした。
もしかするとProgramming以外の分野からの借用かもしれません。

syntactic sugar
syntax sugar
sugared syntax
糖衣構文
構文糖
etc...

英語も日本語も微妙にニュアンスが違う単語がいくつかあります。

私は「本質でないが楽になるもの」という意味で使っており、その場合は「糖衣」や「sugared」が適切であろうと考えています。
理解を助けるもの、という意味であれば「構文糖」「syntactic sugar」が適切かもしれません。
そのあたりはあいまいですが、

> ・砂糖漬 : 原理原則をしらなくても、動作仕様を満たす構文

意味がちょっとわかりませんが、「知らなくてもいい」という意味で「糖」を使うことは一般にないと思います。

「書いたり読んだりするのが楽になる」か「理解しやすい」のどちらかで使われると思います。

# re: 文字列列挙体がほしい 2010/10/25 23:57 Pasie.

> それも糖衣でいいのでは?
では、「甘い、甘すぎる!」ってところで…

> Propertyは本質的な意味を持ってる。
 とりあえず諒解。

>「プリミティブ」を「原子性」(atomic)や「immutable」と誤読しているのではないかと。
 難しい問いですね… とりあえず私の認識を。
 immutableは多分同じ理解。生成後、変更不能なインスタンス。

 プリミティブは私の理解では単一の値。intとかdoubleとかは当然として、Stringやdatetimeも。
 あとは、色(RGB)や座標(x,y,z)や複素数(a+bi)も私の意識ではプリミティブ。もしかしたら行列もプリミティブ。
 逆にプリミティブではないimmutableは、例えば「氏・名・生年月日・性別」からなるオブジェクトとか「郵便番号・住所」とか。
 つまりプリミティブとは意味的に分解不能かどうかであって、immutableとは別物ではないかと。
 では、ファイルの属性みたいに、int16をフラグで運用するケースはどうなのかと言われたら、意味的にはプリミティブではないのではないかと。本来はbooleanであるべき。

 原子性は、たとえば32bitCPUにあって64bit整数(或いは実数)はアトミックじゃないよね。とか。あるいはトランザクション。
 意味的には同時にアクセスできないとならないが、物理として順次アクセスする際の単位、あるいは他から介入されない間の期間みたいなのもの?

 って理解なんですがあってますか?

# re: 文字列列挙体がほしい 2010/10/26 0:06 Pasie.

> その場合は「糖衣」や「sugared」が適切であろうと考えています。
 えー。"セイロガン糖衣A"の「糖衣」じゃないのー?

# re: 文字列列挙体がほしい 2010/10/26 4:56 れい

あー。
私の言った「プリミティブ」のコンテキストを誤解しているのですね。

> つまりプリミティブとは意味的に分解不能かどうかであって、immutableとは別物ではないかと。
「それ以上分けると意味をなさない最小単位」というのは状況で変わりますよね。

> 例えば「氏・名・生年月日・性別」からなるオブジェクト
これは「個人情報」というprimitive型とみてもいいのでは?
「生年月日」だけじゃ「生」の意味がないでしょう。

というように、見方や価値観によって違うのは「意味論のprimitive」、「自然言語のprimitive」です。
例えば、オブジェクト設計中に「どちらがよりprimitiveか」と考える時のprimitiveは「意味的に分解不可能」という意味で、「意味論のprimitive」です。
Pasie.さんのprimitiveは「意味論のprimitive」です。

ですが、私が言っているのは「コンパイラのprimitive」、「処理系のprimitive」です。
このprimitiveは、「そのobjectを単純に処理できるかどうか」を示すもので、その処理系にとって原始的なobjectかどうかというだけです。

primitive型の定義は言語によってさまざまですが、基本的には「処理系のサポートのある型」のことです。
VBやC#では「定数になれる」「enum可能」などの他の型にない追加の機能があり、それはメモリ内で単純に表現可能、つまり処理系にとって原始的であるということからきています。

例えば、私のオブジェクト設計の指針の一つとして以下のようなものがあります。

『(意味論的に)primitiveなオブジェクトのうち、データ量が少ないものは「immutable」なオブジェクトにする。
その際、メンバはできるかぎり(処理系の)primitiveな型にする。』

どっちがどっちなのかは前後の文章で判断していただくしかないのですが。

「価値観次第」の話をしているなら意味論のprimitive、
機械的な判断が必要とされるなら処理系のprimitiveです。

# re: 文字列列挙体がほしい 2010/10/26 23:47 Pasie.

> これは「個人情報」というprimitive型とみてもいいのでは?
>「生年月日」だけじゃ「生」の意味がないでしょう。
 そちらではなくて。生年月日は単独で成立しなくても、氏名は独立できてしまいます。 それに対して座標や色などはどれか一つの要素だけでは独立できませんよね。組み合わせて初めて意味が生じます。

>「コンパイラのprimitive」、「処理系のprimitive」
 理解はしました(したつもりです)が、これまでの文意から、これを推定するのは難しいのではと。
 そもそも文字列列挙が欲しいというのはAsIsでなくToBeの問題なので、現時点の処理系がNGなのは置いておいて、列挙(選択肢?)型になりうるとすると、それはプリミティブであるとするなら、それは意味論に置けるプリミティブを差すのではないかなあと思った次第です。

>基本的には「処理系のサポートのある型」
 Stringは将来に渡って絶対にサポートされないですかね?この話題の流れの中でAsIsだけを語っても仕方がないのではと…

>(意味論的に)primitiveなオブジェクトのうち、データ量が少ないものは「immutable」なオブジェクトにする。
 immutableとデータ量の多少は直接的には関係のない物だと思いますが…無限のメモリと処理能力があったとき、全てのオブジェクトはimmutableであるべきと言う考え方ですか?

>その際、メンバはできるかぎり(処理系の)primitiveな型にする。
 無駄なコードを書くな、程度には理解できますが、メンバはその必要があるからその型になるのであって、プリミティブ"型"に代替できるものではないと思うわけですが…
 具体的に、オブジェクトインスタンスをプリミティブに交換できる事例を思いつけない。

>機械的な判断が
 機械的というと具体的には?

 すみません、なんか"何故何くん"になってしまいした(汗

# re: 文字列列挙体がほしい 2010/10/27 0:47 れい

> これまでの文意から、これを推定するのは難しいのではと。

あれれ。そうですか。

> そもそも文字列列挙が欲しいというのはAsIsでなくToBeの問題なので、

いやいや。
今現在、何故無いのかを私なりに分析しただけですので、立場はずっと「AsIs」でした。
どうすれば作れるのか、という話はしていない。
なので前述の指針も、「現実」の話。
理想の話はしていない。

でもまぁ前述の「処理系のprimitive」が伝わったようなので、それはもうおしまい。

「ToBe」の話にしましょう。
当然こちらのほうが面白い。

ただ、「無限のメモリと処理能力があったとき」は考えられません。
無限のメモリと無限の処理能力があれば、すべての問題が解けてしまうので。

> 無限のメモリと処理能力があったとき、全てのオブジェクトはimmutableであるべきと言う考え方ですか?

前述のように、無限のメモリと処理能力は仮定できません。
豊富にあったらimmutableの敷居が下がるかと言えば、私はYes。
現に、stringがimmutableでない言語は多い。
豊富に資源があれば、immutableとできるオブジェクトは増えるでしょう。

> プリミティブ"型"に代替できるものではないと思うわけですが

ええ。これは現在の現実の指針ですので。
immutableの敷居を挙げる枷です。

> 機械的というと具体的には?
計算で判断がつけられるということです。
人間が判断せずに。

> Stringは将来に渡って絶対にサポートされないですかね?
それは「enum : string」のサポートですよね?
上の「AsIs」でサポートされてない理由はおおむね合理的だと私は思っています。
ですので、「enum : string」は要らない。
stringは「処理系のサポート」があるので、原理的には可能でしょうが、サポートするのはただのsugar。

より便利にするなら、選択肢型を用意してほしい。
immutableかどうかを、「一般の型」について機械的に保証することはできませんが、
制約を課せばある程度使えるものができるはずと考えています。

選択肢型が最初に参照されるときに選択肢内の全オブジェクトの生成、
同値判断はEqualsで、
代入の右辺値はあり、左辺値はなし、
オブジェクトが変更されてしまってもそのまま。
とすれば「自己責任」でimmutable型を選択肢型に使えます。

ただ、最近は深い理解が必要な言語は流行ません。
「IDisposableはusingで」とか「gotoは使うな」とか分かりやすい標語で手段を制限されることが多いので、動作が不安定に成り得る選択肢型は使えない、という話になりそうです。

# re: 文字列列挙体がほしい 2010/10/27 23:12 Pasie.

>無限のメモリと無限の処理能力があれば、すべての問題が解けてしまうので。
 ああ。では無限とも思える、でもいいです。具体的には、今の環境ってZ80-4MHz,64KB-RAM,320KB-MD2Dの環境からすると無限に近い世界ですよね。程度で考えてもらえると助かります。
 その上で私は、やはりメモリの大小によってimmutableかそうでないかは分かれないと思うんですね。あくまで機能で選択されるんじゃないかと。

>stringがimmutableでない言語は多い。
 私が知る限り、Cとその影響をうけた言語だけが、文字列をPrimitiveでないものとして扱っている様な気がしているんですが。もっとも「Cとその影響をうけた言語(c,c++,java,.net等)」が現時点で主力勢力なんでそれをもって多いといわれればそれまでですが。(.netやjavaのstringはimmutableですけど、参照という仕組みを無視できないあたりはCと似ていると)

 ところで選択肢型がなにかわからなくなってきた…とりあえず、
> 選択肢型が最初に参照されるときに選択肢内の全オブジェクトの生成、
 可能であればコンパイル時点で埋め込んでしまってもOK、と捉えてもok?
> 同値判断はEqualsで、
 値を比較ということで、参照(アドレス)をするのではないという意味でok?
> 代入の右辺値はあり、左辺値はなし、
 数値リテラルと同じ考え方ですよね?
> オブジェクトが変更されてしまってもそのまま。
 これはよく分からない。
 選択肢型を左辺値にもってきたときに、代入されないという意味?
ってところで理解は間違っていないですか?(最後は除く)

>動作が不安定に成り得る選択肢型
 どのあたりを不安定と言われていますか?

# jrWrvdsPTy 2022/04/19 11:04 johnansaz

http://imrdsoacha.gov.co/silvitra-120mg-qrms

タイトル
名前
Url
コメント