ab.com コミュニティ https://www.activebasic.com/forum/ |
|
プロパティの実装方法について https://www.activebasic.com/forum/viewtopic.php?t=1607 |
ページ 1 / 1 |
作成者: | 山本 [ 2006年10月08日(日) 18:13 ] |
記事の件名: | プロパティの実装方法について |
只今ライブラリ開発フォーラムにて、クラスのプロパティ機能に関する議論を行っております。 プロパティはオブジェクト指向プログラミングにおいて、非常に重要な仕様の一です。ライブラリ開発チームに限らず、より多くの皆様のご意見をお聞かせ願いたいと思い、こちらへ投稿いたしました。 まず、実装に際しての選択肢として二通りの方法を提案しております。 【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 [ 2006年10月08日(日) 18:22 ] |
記事の件名: | |
「ライブラリ開発」での自分の発言をこちらにも掲載します。 引用: プロパティとメソッドの仕様上の違いを明確に強制する必要があるか否かの問題ですよね。
というわけで、こちらでも票を投じさせてもらいました。構文が異なるというだけで意味上はどちらも同じですから。 「これこれのときはプロパティとして、そうでない場合はメソッドとして実装しなさい」というような意味論的な規約を(明示的であれ暗黙的であれ)プログラマに押しつけるのは正直嫌ですし、その規約を守るか破るかもプログラマ次第ですから、プロパティはメソッドの単なる syntax sugar で構わないと考えています。 つまりD言語スタイルに一票です。 意見などがございましたらこちらにレスをください。 P.S. to 山本様 選択肢に「どちらでもよい」と「プロパティは必要ない」も入れてほしい、と書き込もうと思うも一足遅し。 ま、いっか。 |
作成者: | 山本 [ 2006年10月08日(日) 20:09 ] |
記事の件名: | |
引用: 選択肢に「どちらでもよい」と「プロパティは必要ない」も入れてほしい、と書き込もうと思うも一足遅し。
追加しておきました(^-゜)v
ま、いっか。 |
作成者: | OverTaker [ 2006年10月09日(月) 00:43 ] |
記事の件名: | |
引用: 「これこれのときはプロパティとして、そうでない場合はメソッドとして実装しなさい」というような意味論的な規約を(明示的であれ暗黙的であれ)プログラマに押しつけるのは正直嫌ですし、その規約を守るか破るかもプログラマ次第ですから、プロパティはメソッドの単なる syntax sugar で構わないと考えています。
私もどちらかと言えば、より自由にコーディングできる言語のが好きではありますが、今のActiveBasicはクラスのメソッドのAbstract,VirtualやOverrideが既にあるので、プロパティだけ意味論的な規約がないのは気持ち悪い感じがしてしまいます。また、ライブラリ開発の方でも言った通り、プロパティを実装したときにコードに明確な違いが表れた方が、パッとみわかりやすいと思います。 というわけで、VB.NETスタイルに一票投じようと思います。 が、実は私、ActiveBasicとObjective-Cしか使ったことないので、もちろんプロパティも使ったことがないんですよ。それなのですべて想像上で考えていることなので、もっと経験のある方の意見を尊重したいと思っています。 |
作成者: | tak [ 2006年10月09日(月) 12:41 ] |
記事の件名: | |
> 私もどちらかと言えば、より自由にコーディングできる言語のが好きではありますが、今のActiveBasicはクラスのメソッドのAbstract,VirtualやOverrideが既にあるので、プロパティだけ意味論的な規約がないのは気持ち悪い感じがしてしまいます。 いや、意味論的というのはオブジェクト指向的な意味ではなくてですね、えーと、、、 抽象メソッドや仮想関数、関数のオーバーライドといった考え方は元々オブジェクト指向に基づく概念なんですね。 これらはどれも「他の何かと等価」というわけにはいかないんですよ。 それに対して、現状プロパティの本質は完全に「メソッドと等価」ということは理解していただけるかとおもいます。 本質的にはどちらも同じですから、あくまでコンパイラの立場になりきってみると、プロパティだか、メソッドだか、なんて話は無意味なんですね。 ではプロパティとメソッドを区別する必要があるのか? と、僕は最終的にこの疑問にたどり着いたわけなのですが、その結論を「意味論による」と表現させてもらいました。 プロパティとメソッドの違いを見出せるのは人間だけ(上述のとおりコンパイラには同じに見える)、それをどうやって見出すかは、文脈によって「ここまではプロパティ、ここからはメソッド」と自分の中で線引きして、自分の主観を基準としてどちらかを選択することになると思います。 その主観による束縛を文法によってある程度プログラマに強いることを、上では「意味論的な規約」と表現しました。 僕はこれをナンセンスだと思うので、よりプログラマの自由度の高いD言語スタイルの方がよいと考えています。(D言語スタイルの方が優れている、とまではいいませんが。) > プロパティを実装したときにコードに明確な違いが表れた方が、パッとみわかりやすいと思います。 わかりやすければそれにこしたことはありません。 しかしどのあたりがどういう感じでわかりやすくなるのか、いまいちイメージが掴めません。 なので、一応コメント保留。 |
ページ 1 / 1 | 全ての表示時間は UTC+09:00 です |
Powered by phpBB® Forum Software © phpBB Limited https://www.phpbb.com/ |