ＨＳＰでのクラスについて

なんでないんでしょうね、欲しいですよね。
OpenHSPを見る限りそういった動きは全くなさそうですが…。

＞確かに本格的なオブジェクト指向を実装すれば
＞初心者の敷居が高くなってしまいますね。
確かに、HSPとしてオブジェクト指向のパラダイムしか許さないのであれば敷居は高くなるでしょうね。
しかし、現在のBASICライクな手続き型のパラダイムを今から全部捨てる必要性はないですし、
その上にオブジェクト指向ライクなパラダイムも選んで使える分には利はあっても害はないと思うのですが。

現状でも使う人は使うしそうでない人は使わない（と、私は認識してますが）「モジュール型変数」もあることですし、
「OOPを使うとこれぐらい書きやすくなるよ！」という主張はあっても「OOP使ってこう書くべき！」とはならなそうなのを考えると、
今のHSPの書きやすさを残したままオブジェクト指向を取り入れることに大きな抵抗はないように思えます。

＞継承、ポリモーフィズム
現状でも継承、ポリモーフィズムでやりたいことを考えるなら、メソッドに関しては単にvtableっぽいものを自分で作れば出来るには出来る、ハズです。



#module poly thisType, labelF, labelG
#enum global POLY_TYPE_BASE = 0
#enum global POLY_TYPE_DERIVED

#modinit int type
	switch( type )
		case POLY_TYPE_BASE : initAsBase thismod : swbreak
		case POLY_TYPE_DERIVED : initAsDerived thismod : swbreak
	swend
	thisType = type
	return

	// vtableを初期化
#modfunc initAsBase
	labelF = *baseF : labelG = *baseG
	return
#modfunc initAsDerived
	initAsBase thismod
	labelF = *derivedF// Fだけオーバーライド
	return

	// メソッドのエントリー
#modfunc f
	gosub labelF : return
#modfunc g
	gosub labelG : return

	// 実際の処理用
*baseF
	mes "[F]hello Base[type="+thisType+"]" : return// thisTypeなどインスタンス変数も正常に使える
*derivedF
	mes "[F]hello Derived[type="+thisType+"]" : return
*baseG
	mes "[G]hello Base[type="+thisType+"]" : return
#global// poly

		// ２個インスタンス作って、別々に初期化
	newmod pi, poly, POLY_TYPE_BASE
	newmod pi, poly, POLY_TYPE_DERIVED
		// スクリプトとしては同じだけど、実行されるコードは違う
	foreach pi
		mes "instance : "+cnt
		f pi(cnt)
		g pi(cnt)
	loop

コンストラクタに値渡す必要があるあたりがスクリプト的に腐ってる気がしますが、実行時多態に必要な道具立てはHSP内で既に揃ってはいます。
フィールドの実装はちょっと骨が折れそうな気がしますが、ある程度の制約を設ければそこそこ動くものにはなりそうです。

問題は例えば継承した際の派生クラス側の処理をスクリプト的に分割して書けないこととか色々（多々？）ありますが、
そもそもHSPがそういう風に設計されてないですし無理やりなコードになることは必至でしょう、多分。

上記の通り「自分で実装することは頑張れば出来るには出来る」状況ですが、それを楽にするための文法とかシンタックスシュガーな筈なので、
やっぱり是非ともオブジェクト指向な書き方ができる何かは欲しいですね。。。

＞オーバーロード
は、HSPのように本来的に変数の型が静的に定まらない場合、実行時に解決されるのでコスト高そうですね。
かつスクリプト書いてる時にどの実体が呼ばれるのか自分で考える必要があってちょっと面倒くさいかと思いますが…。

HSPTV!掲示板