HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2015
0628
#define HSPHSPでのクラスについて7解決


#define HSP

リンク

2015/6/28(Sun) 10:28:30|NO.69878

なぜHSPにはクラスなどのオブジェクト指向に欠かせない物がないのですか?
HSPには類似したモジュールなどの機能がありますが、継承、ポリモーフィズムなどを
実現する為の機能が存在しないのは疑問に思います。
あったほうが便利なのではとも思いますが...



この記事に返信する


nepisat

リンク

2015/6/28(Sun) 10:36:34|NO.69879

私も継承等便利だと思うのですが、簡単さやHSPらしさ(BASICポイ感じ)
が消えてしまいもはや別言語になってしまうような気がします。



#define HSP

リンク

2015/6/28(Sun) 11:00:07|NO.69880

返信ありがとうございます。
確かに本格的なオブジェクト指向を実装すれば
初心者の敷居が高くなってしまいますね。
BASICライクな文法、また0行でウィンドウを出せるところが、
初心者にもとっつきやすいHSPの良さなのかもしれませんね。



kanamaru

リンク

2015/6/29(Mon) 19:05:17|NO.69887

継承は#includeで再現。
ポリモーフィズムはさすがにないか。
オーバーロードなら
#define&varptr&ifで根性でできるかな?
(最大引数を決めなければいけないけど。)



3k

リンク

2015/6/29(Mon) 20:45:27|NO.69889

なんでないんでしょうね、欲しいですよね。
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 // 2個インスタンス作って、別々に初期化 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のように本来的に変数の型が静的に定まらない場合、実行時に解決されるのでコスト高そうですね。
かつスクリプト書いてる時にどの実体が呼ばれるのか自分で考える必要があってちょっと面倒くさいかと思いますが…。



kanamaru

リンク

2015/6/30(Tue) 08:30:59|NO.69899

僕の言った方法はあとから考えてみたら少々無理やりですね。
というか僕の言った方法だとパラメータに変数しか使えない…。



Velgail

リンク

2015/6/30(Tue) 09:01:43|NO.69900

そんなに問題があるならC++でHSPライクなライブラリを作っちゃえば?

……いや、実際作ろうとしてちょっと分量多すぎて止まってるんだけども。
(あとC++で実装するなら例えばRaspberry Pi向けのライブラリとかあると面白そう)



skyblue

リンク

2015/6/30(Tue) 16:36:49|NO.69904

>なぜHSPにはクラスなどのオブジェクト指向に欠かせない物がないのですか?
オブジェクト指向でした?HSP



ONION software Copyright 1997-2021(c) All rights reserved.