thisの束縛
JavaScriptの関数内で使えるthisですが、基本的には、その関数を呼び出したobjectが返ります。
つまり、同じ関数であっても、呼び出す箇所によって、thisがコロコロ変わる可能性がある訳ですね。
例えば、他のオブジェクト指向言語における、メソッド呼び出しの際のthisなりselfなりでは、
自分が所属するクラスなりインスタンスとなる。
場合によっては、それと同じように、thisを固定したい時もあったりする。
最近、この実現方法で、しばらく煮詰まっていたのだけれど、
さすが変態言語であるところのJavaScriptである。(笑)
ちゃんと、そういう手段が用意されていた。
「bindを使え!!」
任意の関数funcのbind関数にthisとして与えたいobjectを指定すればＯＫ。
var newFunc = func.bind(object);
これで、newFuncを呼び出せば、期待した動きとなる。
今更 JavaScript
久々に通いの勤め人となり、ここ数週間、JavaScript浸りである。
はるか昔に自分が使っていたJavaScriptとは、随分と様変わりしていた。
正直、恐ろしいくらいに...
実行速度もやれる事も規模も全く比べ物にならない。
この世界は、本当に、変化のスピードが速い。
様々なライブラリやフレームワークが提案され、
様々な使い方が模索されているが、
頻繁な機能拡張や仕様変更、何層にも重なるモジュール群とその関連性で、
複雑さや難解さは加速度的に増すばかりである。
これらをブラックボックスと割り切って使っている間はまだしも、
ちょっとでも道を踏み外そうものなら、
あっと言う間に奈落の底へ突き落とされたような気分になれる。苦笑
結局「シンプル・イズ・ベスト」ではないけれども、
必要な物を必要な分だけ取り入れる方が、
見通しも良くメンテナンス性も維持し易いような気がしてくる...
「過ぎたるは及ばざるが如し」の格言通り、
何でもかんでも突っ込んでしまうのではなく、
むしろ不要な物を削っていくような発想も必要なんじゃないかと、
漠然とだけど、そんな事を感じる、今日この頃である。
レガシーな理由(BIOS)
元祖「IBM PC」が発売されたのが、1981年。
所謂「互換機」の祖である「PC/AT」が発売されたのが、1984年。
それから３０年近い年月を経てきた訳だ。
この間、PCの性能は驚異的に高まり、
周辺機器なども淘汰が繰り返され、
中身は全く別物と言っても良いくらい変化してきた。
ところが、BIOS に関しては、この30年間、
細かい改良は継続されつつも、
根幹を成す部分について、大きな変化はない。
極端な言い方をしてしまえば、現在の BIOS は、
ブートメディアの先頭１クラスタ(512Byte)分をロードする為だけにある。
後は、ロードしたプログラムに制御を移し、
基本的には、ここで、お役御免となるのである。
＊但し、ロードされた IPL や OS から BIOS サービスを利用したり、
ハードレベルの(電源管理等における)状態遷移処理などで、
ちょこちょこ引っ張り出されたりはする。
ブートメディアも時代により主役が入れ替わり、
当初はフロッピーディスクが主流だった物が、
ハードディスクになりＣＤ−ＲＯＭになり、
現在ではＵＳＢメモリ等からのブートも可能になっている。
勿論ブートメディアとして利用する為には、
BIOSが対象メディアを認識・制御出来なければならない。
逆に言えば、BIOSが認識出来ないメディアからのブートは不可という事になる。
たかだか先頭１クラスタをロードするだけの処理ではあるが、
これが実行されなければ後に続くOS本体のロードもままならない訳で、
非常に重要な機能である事は間違いなかろう。
それだけ重要な機能であるが故に、
この３０年間、大きな変化を許されなかったとも言えよう。
大きな刷新を行いたいのであれば、互換性を犠牲にする覚悟が必要となる。
それはそれで、ある程度、納得は出来るのであるが、
この為にBIOSから制御が移された直後はリアルモードとなる点が、
避け難い副作用としてつきまとう事になるのである。
諦めていませんよ〜!!
自分は、人の二倍三倍、やる事が遅い。
必然的に、人の二倍三倍、時間を掛けなければ、結果が伴わない。
いや、結果が伴えば、まだ幸い。
それだけ時間を掛けても、まだ、とっかかり状態、だったりする... (^^;;;
ただただ、諦めが悪いだけで、なんとか、ここまで、続けてきている。
そんなこんなで、自分の中では、ずっとずっとROSeプロジェクトは継続中。
いつになったらファイルの読み書きが出来るようになるのか、自分でも分からないけど、
とりあえずは、今でも、それを直近の目標に、悶々と日々を過ごしている。苦笑
で、自分の過去記事など読み返しつつ、知識の整理をしていたりすると、
当時はそれで十分だったと思った記述が、まるで意味不明だったりする。
良くある事と言えば、良くある事... とも思う。
書いている本人は、色々と調べつつ試しつつ、記述している訳なんだけど、
それらの知識を前提にしつつ、要点を書き出しているような状態だ。
前提とした知識が抜けてしまった状態、もしくは、まっさらな状態で、
その要点だけを読んでみても、なかなか、その内容を理解出来るものでもないな... と。
とりあえず、ここでは、日記半分、記録半分なので、それはそれで良いとして、
まとめ方を考えていかないと自分でも読めない内容ばかりになってしまいそうだ。
要注意...
だからメーカー製は!!
現在、自分のところでは、主に二台のノートパソコンが稼働しています。
一台は、ひょんな事から貰っちゃった Dynabook で、過去にも色々と問題のあった子。
もう一台は、去年の頭に、ご乱心気味の勢いで購入した、Faith の重量級。
Faith マシンは、これまでも何台か購入していて、実にお気に入りなのである。
余計なソフトはほとんど入っておらず、見た目も渋く、オシャレさとは全く無縁。
客に媚びず、時代に媚びず、正に言葉通り質実剛健なマシンです。
まぁ、一般受けなんて、これっぽっちも考えていない、玄人向けの構成ですね。
だから良い。
これまでの歴代マシンも含めて、とにかく安定している。
PEN4時代の爆熱マシンだって、ちょっとやそっとじゃフリーズなんてしなかった。
それなのに... それなのに...
Dynaときたら、なんやかんやで、頻繁にフリーズするんですよ!!
やたら敏感な揺れ検出機能とか付いていたり、ＨＤＤプロテクションとか付いていたり、
何か起きた後に、付いてて良かった！って思う事もあるかもしれないけれど、
きっと、９９：１で、こんな無駄な機能は要らん！って思う事の方が多い気がする。
で、最近、何気なくネットを調べていたら、ありました。
こんな記事が。
「cymon.sysが原因と思われるブルースクリーン」
なんと、このドライバーが、諸悪の根源であった可能性が！
これが、プレインストールされている「BookPlaceReader」というソフトにくっついているらしい。
早速、アンインストール！
さて、これで安定してくれれば、万々歳なのだが...
VARIANTの文字列をByRefで渡す
SWTのVARIANT型を普通に使う分には、特に悩む事はないと思うのだが、
ByRef渡しのVARIANTを扱う際には、ちょっと不親切かも知れない。
プロトタイプ的には、
public Variant(int ptr, short byRefType)
なのであるが、ptr が指す先に、何を設定するかが問題である。
これがプリミティブ型であれば、
public void setByRef(int val)
だとか
public void setByRef(float val)
だとかがあるので、データサイズ分の領域をOS.GlobalAllocで確保してあげれば良いのだが、
文字列については、このようなメソッドが用意されていない。
とりあえず、ptr が指すアドレスから、NULL終端文字列を配置してみたが、これはＮＧ。
ならばと、同じタイプを戻り値とするメソッドを呼び出してみて、その中身を調べてみると、
どうも、ptr の指すアドレスにもポインタが設定されており、
文字列の実体は、その先に配置されているようだった。
しかし、同様にやってみたつもりでも、自分がやると、何故かＮＧとなってしまう。
何故だ？
結論から言ってしまうと、文字列の場合、ptr に設定すべき値は、
COM.SysAllocStringの戻り値であるアドレスとなるようだ。
一見、通常のメモリアロケートとなんら違いが無いように見えるが、
BSTRは、文字列データの前に文字列長が配置される構造となっており、
COM.SysAllocStringは、その領域を含めてアロケートを行っている。
戻るアドレスが、文字列データの先頭(文字列長データの直後)となっているので、
通常のNULL終端文字列を扱うように使えるが、実は別物という、曲者である。
そもそも、Javaで、アドレスを駆使するようなプログラムを書かなきゃいけない時点で、
何か間違っているような気がしなくもないのだが...
