{}{論組(ロンぐみ)言語(ゲンゴ)}{類型}{構築子}(4)
{進捗記録}{進捗}{HTML}{dg_fnd()}{希哲14年8月12日の開発}{SQL::lim_T}{SQL::ofs_T}{ページ番号管理}{doc::pgr_T}{希哲14年8月12日の進捗時限}(29)

{希哲14年8月12日3歩 K#F85E/5B28-496F}

前後景一覧整備,装体書整理ページ付け自輪郭検索

途中で終了。

デルン初期からある doc::pgr_T とは別に,汎用的pgr_T を作ることにした。旧実装は経験不足ページ番号管理から HTML出力まで詰め込んでいるが,今回はページ番号管理特化する。

SQL::ofs_T にも SQL::lim_Tページ番号を受け取る構築子を加える。

また,これまで dg_fnd() が空の検索語を受け取ると無名輪郭検索していたため,全輪郭を取得する dg_oln_all() を設けていたが,これは多少煩雑なので dg_fnd() でも空文字列による全輪郭検索に対応し,一本化していくことにした。

{進捗記録}{進捗}{s_T}{デライト手定め離立}{希哲14年2月2日}{to_ 接頭子}{希哲14年2月2日の進捗時限}{希哲14年2月2日の進捗}{デライト先行離立}{複合型}(22)

{希哲14年2月2日1歩 K#F85E/5B28-96B9}

デライト最終調整KNEST 認証整理。

睡眠食事を取り,作業再開。

途中で終了。

本日中の「デライト手定め離立」を目指す。これまで「デライト先行離立」と呼んでいたものとほとんど同じだが,表現を厳密化した。

型変換を統一的に扱うため,これまで活用していなかった to_ 接頭子を活用することにした。構築子構築函数to 演算子と中途半端に被る気がして避けてきたが,拡張性柔軟性明示性が高く変数名名称空間との衝突も避けられるため,s_T のような複合型ではこちらを標準的に利用した方がいいだろう。

{委譲}{構築子}{C++11}(3)
{進捗記録}{進捗}{30時}{27時40分}{備立}{希哲13年12月13日の開発}{be::cnn_T}{最終調整}{希哲13年12月13日の進捗時限}{希哲13年12月13日の進捗}(15)
{開発}{開発記録}{理腑}{デライト正式離立}{構築函数}{希哲13年12月15日}{目標意識}{SQL 類型群}{希哲13年12月11日}{出場}(21)

{希哲13年12月11日の開発 K#F85E/5B28-815C}

出場周辺の理腑新知番実装換装続き。

かねてから検討していた SQL 類型群の導入実験を始めた。SQL を構成する諸要素を類型化し,各類型毎に構築子構築函数演算子を設定することで,DGDBI保守性を向上させる。

一日がかりで基本的な部分を書き換え終え,想像以上に直感性簡潔性厳密性が向上することが分かった。

大きな収穫ではあったが,デライト正式離立への目標意識が稀薄になってきたため,15日に目標を再設定した。

{合い所}{希哲13年8月18日のツイスト}{希哲13年8月18日}{備立子}{JavaScript}{instanceof}{ツイスト}{インスタンス}{論組屋}{アイデンティティ}(15)

{あれ K#F85E/5B28-F81C}

これ自体は,ある程度経験のある論組屋プログラマー)なら割と思いつくと思うのだが,難しかったのは,備立子(ビルダー)として自然で直感的な「名前」だ。というのも,JavaScript において構築子客体(オブジェクト)の合い所アイデンティティ)でもあるので,new foo が foo の個体インスタンス)を返さないと例えば new foo instanceof foo が成立しないわけだ。これをどう整合的に表現するか。

{希哲13年8月18日のツイスト}{希哲13年8月18日}{備立子}{bld()}{JavaScript}{ツイスト}{窓口}{凝集}{客体}{構築子}(11)
{プロトタイプベース言語}{希哲13年8月18日のツイスト}{希哲13年8月18日}{備立子}{JavaScript}{ビルダー}{ツイスト}{客体}{オブジェクト}{構築子}(11)
{構築子}

{}