PSLの公開している名前

ま た w i n d o w s . h か

それはそれとして、まず名前空間が、全部大文字のPSLってのがどうなんだっていうね．
正式な名前はバクロニムなので全部大文字が正しいんですが、
コード中で必ずしもそれに従う必要はなくない？っていう．
もっというならPSL.hからしてどうなんだ感．
ファイル名大文字だとややこしくない？

ちょっとマニュアル整備にも必要なのでリストアップ．

class string
std::stringとの兼ね合いで混乱を来しかねないことは分かっていながら
SHIFTを押す手間を省く為だけにこの名前にしてしまったのだ、許せ(外はPSLにしながら…)

	static empty
	static min_i
	公開する必要も無いのだが隠す理由も感じないので公開してある
	そしてmin_iもまさに以前windows.hに押しのけられた名前なのだ(前はminだった)

	c_str
	find
	rfind
	copy
	substr
	reverse
	sprintf
	w_str
	全部小文字
	まあこれはいいんじゃないでしょうか
	標準との兼ね合いもありますし

class wstring
	wchar_t*文字列変換用、または一時的に保持しておきたい場合に使う為だけのクラス
	メンバはc_strのみで操作も用意してない
	尚、これ同士で普通に代入した場合は中身共有するので普通に返値にしても平気

class variable
	type
	clone
	substitution
	assignment
	ref
	pointer
	instance
	length
	push
	exist
	set
	del
	keys
	c_str
	toPointer
	toString
	基本的に1単語なこともあって小文字のみですが
	toXxxだけlowerCamelCase
	まあこれはこれでいいんじゃないかなと思いますね
	c_strはstring等のやり方に従っています
	まあvariableのc_strは非推奨関数ですけどね(中でstatic stringを持っている)
	分かって使うならいいんですが

	enum Type
	ここでいきなり頭大文字の型名？
	統一感が…まあこれを得るメソッドtypeとの兼ね合いもあるのですが…
	上をgetTypeにする？どうもねえ、まあいいんじゃないですか、これぐらい
	型名が大文字始まりというのは本来的には悪くない筈なのだ…
		NIL,
		INT,
		HEX,
		FLOAT,
		STRING,
		POINTER,
		RARRAY,
		OBJECT,
		METHOD,
		CFUNCTION,
		CMETHOD,
		CPOINTER,
		THREAD,
		BCFUNCTION,
		CCMETHOD,
		問題はこっち
		全部大文字にしてしまっているけど、よくないよねえこれは…
		その意味合いは分かってはいるんだが、
		どうも定数＝大文字みたいなイメージが出来てしまっているのだよねえ
		頭大文字系にするとMethodだけ被るか
		まあ誰かのdefineと競合するまでは放置しよう
		っていうかそれに関しては中はもっと酷いんですがね

	typedef hex
	typedef function
	typedef method
	typedef buffer
	こちらは全部小文字、まあいいでしょう

	class Function
	中身はありません
	VMを通さずに通常の関数をバインドしたい場合に使えます
	(コンストラクタオーバーロード用)
	ついでにclass Method<>ってのもあります、メンバ関数バインド用

	struct PSLException
	まあ使わないしこれは放っておこう

class PSLVM
全部大文字ってどうなんだっていうね
	Run
	LoadScript
	LoadString
	LoadCompiledCode
	WriteCompiledCode
	今回問題になったものも含めて何故かこいつはUpperCamelCase…かと思いきや
	add
	get
	その流れからでも1単語ならまあ小文字というのも…
	addFunction
	addClass<>.instance
	addInstance
	突然のlowerCamelCase!
	なんだろう、4文字は長いけど3文字は短いとかそういう判断だろうか

	enum error
		NONE
		FOPEN_ERROR
		NOT_COMPILED_CODE
		PARSE_ERROR
		そして再びこれ
		でもエラーコードとか大文字だろーとか思っちゃう、よくない

まあ中身はもっと酷いですけどね．

んー、PSLVMのメソッドも全部lowerCamelCaseにするのが手っ取り早いか．
他は微妙に統一感には欠けるが、
改めてこうして見てみてもそんなに大きな問題がある様にも思えなかった．

後の争点は、名前空間PSLはpslでもいいんじゃないか、
PSLVMなんてvmだけでもいいんじゃないか、いやそれはやり過ぎか、名前空間内でも．
psl::vmならいいんだが、どうせvariableも使うならusing namespace psl;ってするし、
二文字の型名はちょっとねえ．
でも今書いて思ったがアクロニムを小文字にすると視認性が悪いな…
取り敢えず今のままでいいか…
VMだけにする、ってのはまああるようなどうかな…

その観点で言えばvariable::Typeの中身…ああでもこれはしょうがないのか．
intにするわけにはいかないものな．
pintとかでもいいけど、分かり難いだろう．
if (v.type() == variable::STRING)とか、
variable t(variable::THREAD);とか、
ちょっとどうかと思うけど、まあいいか…

まあ手間とか使い方とか見た目とかじゃなくて、
全部大文字は避けた方がいいのは確かなんだが…
小文字の名前や普通のUpperCamelCaseの方がdefineと干渉するんだから、
もう今考えても仕方ない気もする．

取り敢えずwindows.hは酷い．