プロパティの実装方法について

[山本]

只今ライブラリ開発フォーラムにて、クラスのプロパティ機能に関する議論を行っております。

プロパティはオブジェクト指向プログラミングにおいて、非常に重要な仕様の一です。ライブラリ開発チームに限らず、より多くの皆様のご意見をお聞かせ願いたいと思い、こちらへ投稿いたしました。


まず、実装に際しての選択肢として二通りの方法を提案しております。


【VB.NETの構文を参考にしたプロパティ構文の実装】
一つ目はVB.NETの構文に似せた形です。Get/SetアクセサはProperty～End Propertyステートメントの内部に記述し、Setアクセサに関してはValue変数が自動的に名前付けされます。

コード: 全て選択

'-------------------------------------------------------
' VB.NETの構文を参考にしたプロパティ構文の実装
' Note:  Property～End Propertyの間にGet/Setアクセサ
'      を記述する
'-------------------------------------------------------

Class CTest
	m_label_str As String
	m_label_i As Long

	m_table[100] As Long

Public

	Property label As String
		Get
			Return m_label_str
		End Get
		Set
			'"Value As String" が自動的に生成される
			m_label=Value
		End Set
	End Property

	'lableプロパティをオーバーロード
	Property label As Long
		Get
			Return label
		End Get
		Set
			label=Value
		End Set
	End Property

	'配列要素を持たせたプロパティ
	Property table[e As Long] As Long
		Get
			Return m_table[e]
		End Get
		Set
			m_table[e]=Value
		End Set
	End Property
End Class

【D言語の構文を参考にしたプロパティ構文の実装】
そして二つ目、こちらは呼び出し側の解釈をちょっと変えてみる発想になります。プロパティの記述のために新しいステートメントを導入しないところがミソです。この手法はD言語で採用されており、新たな構文が必要ないこと、なんといってもソースコードの行数が少なくて済みます。

具体的には代入先、参照先に期待するメンバが存在しなかったときに、コンパイラが下記のような解釈をするようにします。

Getアクセサ:
"a=obj.label" → "a=obj.label()"

Setアクセサ:
"obj.label=b" → "obj.label(b)"

コード: 全て選択

'-------------------------------------------------------
' D言語の構文を参考にしたプロパティ構文の実装
' Note:  呼び出し解釈に柔軟性を持たせる
'-------------------------------------------------------

Class CTest
	m_label_str As String
	m_label_i As Long

	m_table[100] As Long
Public

	Function label() As String	'label.Getアクセサ
		Return m_label_str
	End Function
	Sub label(Value As String)	'label.Setアクセサ
		m_label_str=Value
	End Sub

	Function label() As Long	'label.Getアクセサ
		Return m_label_i
	End Function
	Sub label(Value As Long)	'label.Setアクセサ
		m_label_i=Value
	End Sub

	'配列要素を持たせたプロパティ
	Function table(e As Long) As Long	'label.Getアクセサ
		Return m_table[e]
	End Function
	Sub table(e As Long, Value As Long)	'label.Setアクセサ
		m_table[e]=Value
	End Sub
End Class

私（山本）の意見としては、実装が簡単であり尚且つ新しい予約語を導入しなくても済む後者（D言語スタイル）の方法が適切ではないのかと思い、試験的に実装を行いました。結果、下記のような印象を持ちました。

・試験段階ではD言語スタイルを採用
・それを実装し、テストした感触は「使い易い」
・しかし、言語構造としての完璧性が求められず、曖昧性が生じている
・その問題を解消するには、C#・VB.NETのようなスタイルを採用する必要がある

ここで言う曖昧性とは下記のようなことを意味しています。

・プロパティのつもりで用意したメソッドを通常呼び出しで利用できてしまう
・通常呼び出しをするつもりで用意したメソッドをプロパティとして利用できてしまう

ようは、文法を統一して簡略化をはかったぶんだけ、記述の曖昧性が生まれているということになります。この件に関しては、Get/Set修飾子を用意し、文法に規制をかけるという案がありますが、この意見を突き進めると、結局のところC#やVB.NETなどのProperty～End Propertyステートメント、Getアクセサ、Setアクセサに辿り着くことになります。

また、この曖昧性の問題の本質を分析しますと、"間違った書き方を容認してしまう" 仕様であることは認識せざるをえませんが、"アクセスしてはいけない部分にアクセスできてしまう" 仕様ではありません。ようは、危険なコードを誘発しまうような事象に直結する問題ではないということです。

もし、文法規制を重視するのであれば、C#・VB.NETのような完全なるプロパティ文法を導入すべきだと考えられます。

逆に、D言語のような曖昧スタイルを採用するのであれば、それは一種の相互記述が可能な文法だと解釈し、書き方はユーザーに任せるものであるという認識が必要になると思います。

皆さんは、これらの特徴をどのように捉え、どのような言語仕様に決定すべきだと思われるでしょうか？

ご意見・アドバイスをお聞かせ願えると助かります。

[tak]

「ライブラリ開発」での自分の発言をこちらにも掲載します。

プロパティとメソッドの仕様上の違いを明確に強制する必要があるか否かの問題ですよね。
構文が異なるというだけで意味上はどちらも同じですから。

「これこれのときはプロパティとして、そうでない場合はメソッドとして実装しなさい」というような意味論的な規約を（明示的であれ暗黙的であれ）プログラマに押しつけるのは正直嫌ですし、その規約を守るか破るかもプログラマ次第ですから、プロパティはメソッドの単なる syntax sugar で構わないと考えています。
つまりＤ言語スタイルに一票です。

というわけで、こちらでも票を投じさせてもらいました。
意見などがございましたらこちらにレスをください。


P.S. to 山本様

選択肢に「どちらでもよい」と「プロパティは必要ない」も入れてほしい、と書き込もうと思うも一足遅し。
ま、いっか。

[山本]

選択肢に「どちらでもよい」と「プロパティは必要ない」も入れてほしい、と書き込もうと思うも一足遅し。
ま、いっか。

追加しておきました(＾-゜)v

[OverTaker]

「これこれのときはプロパティとして、そうでない場合はメソッドとして実装しなさい」というような意味論的な規約を（明示的であれ暗黙的であれ）プログラマに押しつけるのは正直嫌ですし、その規約を守るか破るかもプログラマ次第ですから、プロパティはメソッドの単なる syntax sugar で構わないと考えています。

私もどちらかと言えば、より自由にコーディングできる言語のが好きではありますが、今のActiveBasicはクラスのメソッドのAbstract,VirtualやOverrideが既にあるので、プロパティだけ意味論的な規約がないのは気持ち悪い感じがしてしまいます。
また、ライブラリ開発の方でも言った通り、プロパティを実装したときにコードに明確な違いが表れた方が、パッとみわかりやすいと思います。

というわけで、VB.NETスタイルに一票投じようと思います。
が、実は私、ActiveBasicとObjective-Cしか使ったことないので、もちろんプロパティも使ったことがないんですよ。それなのですべて想像上で考えていることなので、もっと経験のある方の意見を尊重したいと思っています。

[tak]

> 私もどちらかと言えば、より自由にコーディングできる言語のが好きではありますが、今のActiveBasicはクラスのメソッドのAbstract,VirtualやOverrideが既にあるので、プロパティだけ意味論的な規約がないのは気持ち悪い感じがしてしまいます。

いや、意味論的というのはオブジェクト指向的な意味ではなくてですね、えーと、、、


抽象メソッドや仮想関数、関数のオーバーライドといった考え方は元々オブジェクト指向に基づく概念なんですね。
これらはどれも「他の何かと等価」というわけにはいかないんですよ。

それに対して、現状プロパティの本質は完全に「メソッドと等価」ということは理解していただけるかとおもいます。
本質的にはどちらも同じですから、あくまでコンパイラの立場になりきってみると、プロパティだか、メソッドだか、なんて話は無意味なんですね。

ではプロパティとメソッドを区別する必要があるのか？

と、僕は最終的にこの疑問にたどり着いたわけなのですが、その結論を「意味論による」と表現させてもらいました。
プロパティとメソッドの違いを見出せるのは人間だけ（上述のとおりコンパイラには同じに見える）、それをどうやって見出すかは、文脈によって「ここまではプロパティ、ここからはメソッド」と自分の中で線引きして、自分の主観を基準としてどちらかを選択することになると思います。
その主観による束縛を文法によってある程度プログラマに強いることを、上では「意味論的な規約」と表現しました。
僕はこれをナンセンスだと思うので、よりプログラマの自由度の高いＤ言語スタイルの方がよいと考えています。（Ｄ言語スタイルの方が優れている、とまではいいませんが。）


> プロパティを実装したときにコードに明確な違いが表れた方が、パッとみわかりやすいと思います。

わかりやすければそれにこしたことはありません。
しかしどのあたりがどういう感じでわかりやすくなるのか、いまいちイメージが掴めません。
なので、一応コメント保留。