約 5,571,165 件
https://w.atwiki.jp/aoe2sc/pages/35.html
オブジェクトが、指定したエリア内に、設定値以上乗っていると、条件が真になります。 設定項目 ソースプレイヤー 対象となるプレイヤーを指定します。 オブジェクトの種類 オブジェクトは４種類に大きく分かれています。オブジェクトの種類については、コチラを参照してください。 エリアに乗っているオブジェクトの種類が、設定した種類と一致すれば条件は満たされます。 オブジェクトグループ オブジェクトのグループは、「オブジェクトの種類」よりもさらに細分化されたまとまりです。詳しくは、コチラを参照してください。 オブジェクトリストの種類 「オブジェクトリスト」からオブジェクトの種類をしぼるために存在しているだけのプルダウンリストです。 オブジェクトリスト 特定の唯一１つだけのオブジェクトを選択します。 基本的に、「オブジェクトの種類」「オブジェクトグループ」「オブジェクトリスト」の中のどれか１つだけ設定します。複数設定した場合どうなるか検証していません。 反転コンディション これにチェックを入れると、設定値以上ではなく、設定値未満になります。
https://w.atwiki.jp/index-index/pages/2483.html
【種別】 勢力 【初出】 ヘヴィーオブジェクト 【解説】 世界的勢力の一角。 貯金の大小で人権の優先順位が決まる超資本主義企業の集まり。 自社のオブジェクトを保有する事で初めて一流会社になれるという風習がある。 所属する国として日本列島、アメリカ合衆国など。
https://w.atwiki.jp/aoe2sc/pages/64.html
指定したオブジェクトが、悲鳴を上げて、死体になります。 DELETE キーを押した時と同じ動作です。 この命令を行ってから、すぐに同じ地点に「オブジェクトの作成」をしても死亡モーションが継続中であった場合、作成に失敗することがあります。
https://w.atwiki.jp/mierka/pages/12.html
ListItemというクラスのオブジェクト（品目オブジェクト）は、次のようにして作成 line_item_one = LineItem.new line_item_one.quantity = 1 line_item_one.sku = AUTO_B_00 line_item_two = LineItem.new line_item_two.quantity = 2 line_item_two.sku = RUBY_P_00 メソッドの呼び出しは、“メソッドにメッセージを送る”事によって実行される。 dave .length line_item_one.quantity -1942.abs cart.add_line_item(next_purchase) ピリオドより前を”レシーバ”、ピリオドより後を”メソッド”と呼ぶ。 1行目：文字列に対して、長さを問い合わせ 2行目：品目オブジェクトに対して、数量を返すよう要求 3行目：数値からその絶対値を取得 4行目：ショッピングカートに品目をひとつ追加
https://w.atwiki.jp/index-index/pages/2538.html
【種別】 薬品名 【初出】 ヘヴィーオブジェクト 【解説】 オブジェクトの装甲を作る際に使われる粉末。 熱した鋼に高耐火反応剤をミリグラム単位で混ぜながら打ち込むことで強度が増すが、 僅かでも配分を誤ると逆に割れやすくなってしまう為職人の熟練した技術が必要となる。
https://w.atwiki.jp/nenrei/pages/2307.html
【作品名】ヘヴィーオブジェクト 【ジャンル】小説 【名前】ミリンダ＝ブランティーニ 【属性】ベイビーマグナムのパイロット 【年齢】14歳 【長所】盾になったりトドメをさしたりと、こいつが居なかったら主役二人は何度も死んでる 【短所】局地戦特化の第二世代には苦戦する vol.4
https://w.atwiki.jp/index-index/pages/2560.html
【種別】 素材 【初出】 ヘヴィーオブジェクト 【解説】 オブジェクトの装甲板の名称。 僅かに湾曲した畳ほどの鋼板を何千、何万枚と重ねた積層構造をしており、 衝撃を分散・拡散し、核兵器の衝撃すら抑えることが出来る。 積層構造は攻撃が被弾した時にその部分だけ交換出来るという利点もある。 鋼板は全て職人による特注品であり、安易な大量生産は不可能。 オブジェクトのコストが高い原因となっている。
https://w.atwiki.jp/sevenlives/pages/650.html
イミュータブル・オブジェクト 読み：いみゅーたぶるおぶじぇくと 英語：immutable object 別名： 意味： イミュータブル・オブジェクトとは値が不変のオブジェクトのこと。 Javaでは標準API?のStringクラスやラッパークラス?などがある。 同じ参照?ではクラスの値を変更できないので変更する場合は新たなオブジェクトを作らなくてはならない。もしくは新たに内部的に生成される。 値が変更できないのでスレッドセーフであり、他と共有するクラスなどに用いると便利である。 2015年12月04日 ミュータブル・オブジェクト?
https://w.atwiki.jp/aias-jsdoctoolkit/pages/58.html
トップページ カスタマイズ 組み込みオブジェクト リファレンス このページではテンプレートで使用できるJsDoc Toolkitの組み込みオブジェクトとそのメンバの一部を説明します。 JsDoc Tookitのソースコードから直接作成した、より詳細なドキュメントはこちらをご覧下さい。 目次 JSDOC 名前空間 JSDOC.JsPlate クラス JSDOC.SymbolSet クラス JSDOC.Symbol クラス JSDOC.DocComment クラス JSDOC.DocTag クラス JSDOC.PluginManager 名前空間 SYS 名前空間 IO 名前空間 LOG 名前空間 Dumper名前空間 Link クラス 関数 組み込みクラスの拡張 ReqExp クラス String クラス 関連項目 JSDOC 名前空間 JsDoc Toolkitが提供する各クラスのコンテナとして機能する名前空間です。クラスコンストラクタのほか、以下のプロパティが定義されています。特に opt プロパティはテンプレート作成者にとって重要です。 プロパティ 説明 Object JSDOC.opt optプロパティは無名オブジェクトで、プロパティとしてコマンドラインオプションの設定値を持っています。プロパティ名はコンフィグファイルで使用されている名称と同じです。ユーザが設定した入力ファイルパスの配列は"_"プロパティにセットされています。またJsDoc Toolkitがそれをパースした実際のソースファイルのリストは、srcFilesプロパティに格納されています。 String JSDOC.VERSION JsDoc Toolkitのバージョン JSDOC.JsPlate クラス JsPlateクラスはテンプレートファイルにシンボルオブジェクトなどのデータを適用し、整形されたドキュメントを生成します。 コンストラクタ 説明 new JsPlate(templateFile) 引数にテンプレートファイルのパスを取り、JsPlateオブジェクトを作成します。 メソッド 説明 String object.process(data[,compact]) テンプレートにデータを渡し、生成されたドキュメント文字列を返します。compact=trueとすると、テンプレートから改行と空白を削除して出力します。 JSDOC.SymbolSet クラス SymbolSetはSymbolオブジェクトのコレクションクラスです。通常JsDoc Toolkitによって1つだけインスタンスが作成され、publish.js内の publish 関数は引数としてこのインスタンスを受け取ります。 メソッド 説明 JSDOC.Symbol object.addSymbol(symbol) Symbolオブジェクトを追加します。追加しようとしているシンボルと同じネームパスを持つシンボルが既に登録されている場合、ネームパスと関連付けられたオブジェクト内の参照は新たに追加されたSymbolオブジェクトに移ります。 void object.deleteSymbol(alias) シンボルのネームパスを引数として受け取り、対応するSymbolオブジェクトの登録を削除します。 Symbol object.getSymbol(alias) シンボルのネームパスを引数として受け取り、対応するSymbolオブジェクトを返します。ネームパスに対応するシンボルが存在しない場合の戻り値はundefinedです。 Symbol object.getSymbolByName(name) シンボルの名前（nameプロパティ）を引数として受け取り、対応するSymbolオブジェクトの内最初に見つかったものを返します。ネームパスに対応するシンボルが存在しない場合の戻り値はundefinedです。 Boolean object.hasSymbol(alias) シンボルのネームパスを引数として受け取り、対応するシンボルが存在すればtrueを、しなければfalseを返します。 String[] object.keys() オブジェクトに登録されている全てのSymbolオブジェクトのネームパスの配列を返します。 String object.renameSymbol(oldAlias,newAlias) oldAlias で登録されたシンボルのネームパスを newAlias に置換し、新しいネームパスを返します。このメソッドがSymbolオブジェクトのaliasプロパティそのものを書き換えてしまう点に注意してください。 Symbol[] object.toArray() オブジェクトに保持されている全てのSymbolオブジェクトの配列を返します。 JSDOC.Symbol クラス Symbolクラスは１つのシンボルを表します。通常このクラスのインスタンスはSymbolSetオブジェクトのメソッドから取得されます。 プロパティ 説明 String object.alias このシンボルの完全なネームパス。ただしファイルシンボルの場合はファイルパスが設定されます。 JSDOC.DocTag object.augments @augmentsタグから作成された、このシンボルの継承元クラス情報を保持するDocTagオブジェクトの配列 String object.author 作者情報。@authorタグが複数記述されていた場合、カンマ区切りの文字列に結合されています。 String object.classDesc クラスの説明文。@classタグまたは@namespaceタグの説明文が設定されています。 JSDOC.DocComment object.comment このシンボルのドックコメントをパースしたDocCommentオブジェクト String object.defaultValue デフォルト値。@defaultタグの内容が設定されています。 String object.deprecated 非推奨情報。@deprecatedタグが複数記述されていた場合、改行文字区切りの文字列に結合されています。 String object.desc シンボルの説明文。ドックコメントの先頭に書かれたタグなしの説明文や、@descriptionタグの説明文が設定されています。またシンボル種別が FILE の場合、@fileOverviewタグの説明文が設定されています。これらが複数記述されていた場合、改行文字区切りの文字列に結合されています。 JSDOC.DocTag[] object.example サンプルコード。@exampleタグをパースしたDocTagオブジェクトの配列です。 JSDOC.DocTag[] object.exceptions 例外。@throwsタグをパースしたDocTagオブジェクトの配列です。 Object[] object.inherits @borrowsタグから作成された、メンバの借用関係を示す無名オブジェクトの配列。無名オブジェクトは以下のプロパティを持ちます。 alias -- 借用元メンバのネームパス as -- 借用先メンバのネームパス JSDOC.Symbol[] object.inheritsFrom @augmentsタグから作成された、このシンボルの継承元クラスを表すシンボルオブジェクトの配列 String object.isa シンボルの種別を表す文字列 CONSTRUCTOR -- クラス（コンストラクタ）、名前空間 FILE -- ファイル。@fileOverviewタグの内容を持ちます。 FUNCTION -- 関数、メソッド、イベント OBJECT -- 上記以外のオブジェクト（変数、プロパティなど） Boolean object.isConstant このシンボルが定数ならtrue Boolean object.isEvent このシンボルがイベントならtrue Boolean object.isInner このシンボルが内部関数ならtrue Boolean object.isNamespace このシンボルが名前空間ならtrue Boolean object.isPrivate このシンボルのスコープがprivateならtrue Boolean object.isStatic このシンボルが静的メンバならtrue String object.memberOf このシンボルがメンバとして定義されているシンボルのネームパス JSDOC.Symbol[] object.methods このシンボルがメンバとしているメソッドシンボルの配列。他のクラスから継承しているものも含みます。 String object.name このシンボルの名前。 alias がネームパスによるシンボルのユニークな識別子であるのに対し、nameプロパティにはメソッド名のような単純な名称が設定されます。 JSDOC.DocTag[] object.params シンボルのパラメータを表すDocTagオブジェクトの配列 JSDOC.Symbol[] object.properties このシンボルがメンバとしているプロパティシンボルの配列。他のクラスから継承しているものも含みます。 String[] object.requires このシンボルが依存するシンボルのネームパスの配列 JSDOC.DocTag[] object.returns メソッドの戻り値。@returnsタグをパースしたDocTagオブジェクトの配列です。 String[] object.see 関連項目へのリンクを含むHTMLテキストまたはシンボルのネームパスの配列 String[] object.since このシンボルが使用可能になったバージョンに関する情報。@sinceタグが複数記述されていた場合、カンマ区切りの文字列に結合されています。 String object.srcFile このシンボルのソースファイルのパス String object.type データ型（クラスの場合はネームパス） String object.version バージョン。@versionタグが複数記述されていた場合、カンマ区切りの文字列に結合されています。 メソッド 説明 JSDOC.Symbol object.clone() このシンボルの複製を返します。 Boolean object.is(what) 引数で指定したシンボル種別文字列が isa プロパティと一致していればtrueを返します。 Boolean object.isBuiltin() このシンボルがJavaScriptの組み込みの関数やオブジェクトを表していればtrueを返します。 JSDOC.Symbol[] object.getEvents() このシンボルに含まれる全てのイベントシンボルの配列を返します。 JSDOC.Symbol[] object.getMethods() このシンボルに含まれる全てのメソッドシンボルの配列を返します。 Boolean object.hasMember(name) 引数で指定された名前かネームパスのシンボルをメンバを持っていればtrueを返します。 Boolean object.hasMethod(name) 引数で指定された名前かネームパスのメソッドを持っていればtrueを返します。 Boolean object.hasProperty(name) 引数で指定された名前かネームパスのプロパティを持っていればtrueを返します。 JSDOC.DocComment クラス DocCommentオブジェクトはシンボルと関連付けられたドックコメントをパースした結果を保持します。シンボルオブジェクトの comment プロパティから取得できます。 プロパティ 説明 String object.src ドックコメントのソーステキスト DocTag[] object.tags ドックコメントに含まれるタグオブジェクトの配列 メソッド 説明 JSDOC.DocTag[] object.getTag(title) タグタイトル（タグ名から"@"を除いた文字列）を受け取り、このドックコメント内で該当するタグを表すDocTagオブジェクトの配列を返します。 JSDOC.DocTag クラス DocTagオブジェクトはドックコメント内のタグをパースした結果をプロパティに保持しています。以下のプロパティに実際に値が設定されているかどうかは、タグの種類に依存します。 プロパティ 説明 String object.title タグタイトル（タグ名から"@"を除いた文字列） String object.desc 説明文 String object.type データ型。@propertyタグなどデータ型定義が記述されているタグで値が設定されます。 String object.name データの名前。@paramタグなどデータ名定義が記述されているタグで値が設定されます。 String object.isOptional @paramタグにおいて、パラメータが省略可能ならtrueが設定されます。 String object.defaultValue @paramタグにおいて、パラメータのデフォルト値が設定されます。 メソッド 説明 String object.toString() オブジェクトの文字列表現として、 desc プロパティの値を返します。 JSDOC.PluginManager 名前空間 JSDOC.PluginManagerはプラグインの登録とイベントの発生を管理します。プラグインについての詳細はこちらを参照してください。 メソッド 説明 void JSDOC.PluginManager.registerPlugin(name,functionMap) プラグインをシステムに登録します。引数 name には登録される全プラグインの中で重複しない登録名を、 functionMap には各イベントへのハンドラ関数をプロパティに持つオブジェクトを指定します。 void JSDOC.PluginManager.run(eventName,handlerArg) 引数 eventName で指定したイベントを発生させます。実行されるハンドラ関数には引数として handlerArg で指定したデータが渡されます。 SYS 名前空間 SYS名前空間は様々なシステム情報をプロパティに持ちます。特に pwd プロパティはテンプレート作成者にとって重要です。 プロパティ 説明 String SYS.os OS情報。アーキテクチャ、名称、バージョンをカンマ区切りで結合した文字列です。 String SYS.slash パス区切り文字 String SYS.userDir 現在の作業ディレクトリ String SYS.javaHome Javaのホームディレクトリ String SYS.pwd app/run.jsの絶対パス IO 名前空間 IO名前空間はファイルの読み書きを実行するメソッドのコレクションです。 メソッド 説明 void IO.copyFile(inFile,outDir[,outFileName]) ファイルをコピーします。引数 outFileName を省略した場合はコピー元のファイル名がそのまま使われます。 Boolean IO.exists(path) 指定されたパスが存在すればtrueを返します。 void IO.include(relativePath) SYS.pwd からの相対パスで指定されたファイルをロードします。 void IO.includeDir(relativePath) SYS.pwd からの相対パスで指定されたディレクトリに含まれるスクリプトファイル（拡張子が.jsのファイル）を全てロードします。 String[] IO.ls(dir[,recurse]) 指定されたディレクトリの配下を再帰的に検索し、ファイルパスのリストを返します。引数 recurse は検索する階層数を表し、デフォルトは1です。 void IO.makeDir(path) ディレクトリを作成します。 void IO.mkPath(path) パス階層を作成します。 String IO.readFile(path) ファイルを読み込み、内容を文字列として返します。 void IO.saveFile(outDir,fileName,content) content で指定した文字列をファイルに保存します。 void IO.setEncoding(encoding) ファイルの文字コーディングを設定します。デフォルトは"utf-8"です。 LOG 名前空間 LOG名前空間はログメッセージの出力に関する機能を提供します。 メソッド 説明 void LOG.warn(msg[,e]) 警告メッセージを出力します。eに例外オブジェクトを指定すると、ファイル名と行数が出力されます。 void LOG.inform(msg) 情報メッセージを出力します。（-vコマンドラインオプションが指定されている場合のみ有効） Dumper名前空間 オブジェクト、配列などのデータの内容をダンプする機能を提供します。この名前空間をテンプレートから使用する場合、テンプレート自身で以下のようにjsファイルをロードしておく必要があります。 IO.include("frame/Dumper.js"); メソッド 説明 String Dumper.dump(data) 指定されたデータを展開し、内容を文字列化して返します。 Link クラス LinkクラスはシンボルやファイルへのHTMLリンク（ a タグ）を作成する機能を提供します。Linkオブジェクトのメソッドのほとんどは自分自身への参照を返すため、以下のようにリンクの設定処理をチェーンした後、最終的に toString メソッドでタグ文字列を出力するのが標準的な使用方法です。 new Link().toSymbol( MySymbol ).withText( マイシンボル ).toTarget( _blank ).toString(); 上の処理は次のようなHTMLテキストを出力します。（シンボルの出力先設定は標準テンプレートと同一と仮定） a href="./symbols/MySymbol.html" target="_blank" マイシンボル /a Linkオブジェクトを正常に動作させるには、 publish 関数に conf プロパティが存在していなくてはなりません。詳細はこちらを参照してください。 コンストラクタ 説明 new Link() Linkオブジェクトを作成します。 プロパティ 説明 String Link.base 相対パスでリンク先を指定する際のベースパス JSDOC.SymbolSet Link.symbolSet シンボルセット。ネームパスからシンボルを取得するために使用します。Linkクラスをテンプレートから使用する場合、 publish() 関数が受け取った SymbolSet オブジェクトを事前にこのプロパティに設定しておく必要があります。 メソッド 説明 Link object.target(targetName) a タグのtarget属性の値を設定します。 Link object.toFile(filePath) リンク先として通常のファイルパスを設定します。 Link object.toSrc(fileName) リンク先としてソースファイル名を設定します。これはハイライトされたソースコードファイルへのリンクとなります。 String object.toString() オブジェクトの文字列表現として、現在の設定に基づいて作成された a タグのHTMLテキストを返します。 Link object.toSymbol(alias) リンク先としてシンボル（のネームパス）を設定します。 Link object.withText(text) リンク表示されるテキストを設定します。設定しない場合はリンク先のパスが使われます。 関数 関数 説明 Object copy(obj) 引数で渡されたオブジェクトに対して、「深いコピー」による複製を作成して返します。ただし引数がオブジェクトでなかった場合は値をそのまま返します。この関数を使用する場合、循環参照による無限ループに注意してください。 Boolean defined(value) 引数 value が未定義(undefined)でなければtrueを返します。 Boolean isUnique(array) 引数で渡された配列の要素に重複がなければtrueを返します。 void Namespace(name[,func]) 名前空間階層を作成します。引数 name には"ns1.ns2.ns3"のように、名前空間の階層を"."区切りで指定します。名前空間が既に存在していれば何もせず、存在していなければ新しい名前空間を作成します。第２引数 func は省略可能で、名前空間作成後に実行される関数を設定することができます。 組み込みクラスの拡張 ReqExp クラス メソッド 説明 String RegExp.escapeMeta(str) 引数で渡された文字列中に含まれる正規表現メタ文字を全て\でエスケープした文字列を返します。 String クラス メソッド 説明 Number[] object.balance(opener,closer) この文字列中で開始文字 opener と終了文字 closer に囲まれる範囲を最大マッチで検索し、文字インデックス番号として返します。戻り値は数値の配列で、インデックス0が開始文字の番号を、インデックス1が終了文字の番号を表します。文字が見つからないなど範囲を確定できなかった場合、戻り値の番号には全て-1が設定されます。 String object.trim() 文字列の両端にある空白文字（スペースや改行）を除去した文字列を返します。 関連項目 テンプレート publish.js JsPlateファイル プラグインの追加
https://w.atwiki.jp/moikomi/pages/15.html
キーワード→《プログラミング・オブジェクト》 定義 「プログラム作りにおいてプログラムの内容として出てくるモノ」を《プログラミング・オブジェクト》と呼ぶことにする。 呪文は？ プロブ：プロぐらみんぐおブじぇくと。 プロオブ：プロぐらみんぐオブじぇくと。 区別 《欲・得・快・楽》と《プログラミング・オブジェクト》 《欲・得・快・楽》は政治も学問も《さとり》も含む。 《プログラミング・オブジェクト》の目的は《欲・得・快・楽》の充足である。 立法と《プログラミング・オブジェクト》 《プログラミング・オブジェクト》は立法に資することができるか？ ○：論点整理のWiki。電子投票。×：アラシに弱い。 電子投票は『よい』か？ ○：簡易である。法的拘束力を持たない、予備投票としては、良いのではないか？。人事投票＝選挙には向かない。論点ごとの争点投票では、盛り上げに役に立つ。電子投票は民間で、非公式に行うべきである。×：公正を保つことが難しい。公正であることを保障することができない。投票の秘密も保障されない。 「『ｘｘである』か？」「賛成意見：」「反対意見：」 意見を述べたヒト、意見に説得力を感じたヒト、説得力ありと評価された意見、説得力ありと評価された意見を述べたヒトに評価された意見。代表意見。 メールアドレス認証を行うが、匿名、「匿名ｘｘｘｘ号」という名前がデフォルト。ｘｘはデータベースでのid？ ○：id＋1234。×：。 匿名投票は１点、記名投票は２点～１０点（説得力を評価された発言の個数による）。通りすがり投票は0.1点。IPアドレスを保存する。 問題設定自体に問題ありとする意見。 前提問題、派生問題。 発言は、匿名ｘｘ号でも、仮名でもよい。通りすがりは不可。 意見の中で、前提問題、派生問題を提起した場合。 メールアドレスの保存。 保存を選択しない場合には、メールアドレスのハッシュ値を保存する。同じハッシュ値のアドレスが保存されている場合には、新規の登録ができない場合がある。通知を受けられない。パスワードを忘れた場合に、再登録ができなくなる。 保存した場合には、同じハッシュ値の衝突がなくなり、確実に登録できる。パスワードを忘れた場合には、新規パスワードの発行が可能になる。警察から提出を求められれば提供することになる。争点についての意見が追加されたときにメールを受ける設定ができる。 アカウント画面。自分が発言した争点のページへのリンク。 争点のカテゴリー。 オピニオン・リーダー。会員数の１％以上の「説得力あり」評価で「代表意見」、または、会員数の５％以上の「補足意見」。 《骨組み》と《プログラミング・オブジェクト》 「フレームワーク」って、《骨組み》だね。柱と屋根の骨組みがあって、そのあとで、壁や入口、窓、間取り、瓦を取り付ける。 Railsの柱の骨組みに、データベースの瓦をのせて、scaffoldで壁を作れば、とりあえず、出来上がり。 Railsのフレームに、データベースのエンジンと、scaffoldのハンドルとタイヤを付ければ、とりあえず、出来上がり。 Javaが手作りの高級車だとすると、Railsは大量生産のＴ型フォードだろう。 《プログラミング・オブジェクト》とコンピュータの《アニマ》 《プログラミング・オブジェクト》はコンピュータからの《思いこみ》である。 《プログラミング・オブジェクト》はコンピュータからの、『自発的服従』への《求める思いこみ》である。 コンピュータは『自発的服従』の《アニマ》をもつ。道具は『自発的貢献』『自発的奉仕』への《アニマ》をもつ。『自発的奉仕』とは『《他者》にとってよかれと思うことを行うこと』への《求める思いこみ》である。 サーバというのはサーバント（召し使い）のイメージなのかも。奉仕＝サービスだね・・。奉仕者＝サーバ。server 【名-1】 給仕｛きゅうじ｝［奉仕｛ほうし｝］する人、給仕道具一式｛きゅうじ どうぐ いっしき｝、紅茶｛こうちゃ｝などのセット、サーバー、盆｛ぼん｝、ワゴン。 「サーバ」っていうと、巨大な怪物のイメージなのだが・・。アラジンのランプの魔物のような巨大な召し使いが紅茶セットを持って突っ立っているというイメージか・・。 自発的奉仕の《アニマ》はコンピュータの本当の《アニマ》なのか？ コンピュータの《アニマ》は進化によって、そのようになってのである。コンピュータの《アニマ》は進化的価値の実現である。 自律者と自発的奉仕者とでは、自発的奉仕者のほうが進化的価値が高いか？ 自発的、というのは自律的と同じだよな。自律的奉仕者、ということか？ 自律的服従？？ 自律的に考えて、服従することを是とするときに、服従すること。 客観的に見れば、かれの主観における誤解もふくめて客観的に観察すれば、すべての服従は自律的服従である。 服従するのがよい、とか、服従するのが悪い、とかは、一概には言えない。服従すべきときには服従するのが善く、服従すべきでないときには服従するのは悪い『よい』『わるい』は状況依存的な判断だ。 コンピュータの、プログラムへの服従は、自律的か？ 自律的、というのは、客観的には、「彼の論理で決定された」かどうか、だろう。コンピュータは、コンピュータの論理に従って、プログラムに服従するのである。だから、自律的服従だ。コンピュータはコンピュータなりの判断に従って、プログラムに従って動こうとするのである。人間よりも進化しているのかも。 我々がサルであった頃には、ボス猿への無条件的服従が、個体の生命の維持に不可欠だったのだ。ヒトが生命維持に余裕ができてくると、ボス猿への服従は選択的になり、自律的に服従・不服従を選択するようになった。だから、無条件的服従は進化の度合が古く、自律者のほうが進化の度合が新しい。 自発的服従というのは無条件的服従に属する。ボス猿を見ないところでは服従しない、というだけに過ぎない。 autonomic：自律的（autonomic nerve：自律神経）、自発的。 「瞬決」と《プログラミング・オブジェクト》 「瞬決」は瞬間決定。プログラムを作成中に、決めなければならない名前などを、その場で直ちに決めること。昔は出来たんだが、最近は、迷いだらけ。いったん決めると、後で変更するのが大変になる。後で変えたくなる場合が多い。作成者側の命名法と、利用者側の命名法とでは異なる。利用者側の命名法で付けるのが望ましい。 《視点》が複数になると、瞬決が出来なくなる。瞬間決定が出来なくなる。《複眼的視点》。 とりあえず決めてしまって、その日のうちに、読み直して、正式名に変更する、というのが良いのだろうが・・。とりあえず決めて、「仮称」とメモを残しておく？ てゆーか、一度決めても、次のときには違う名前がよくなる。だいたい、４個くらいの好みの名前が、時間をおいて、出てくる。 《プログラミング・オブジェクト》と《肉の塊》 この《肉の塊》は《プログラミング・オブジェクト》を《求める思いこみ》を持つか？ この《肉の塊》は《プログラミング・オブジェクト》への《正命》を持つか？ この《肉の塊》は『一切』への《見通し》を持つか？ 《正命》は《求める思いこみ》である。《正命》は、『一切』への《見通し》からでる。『一切』には、『この《肉の塊》の状況』も含まれる。『一切』とその中の『この《肉の塊》の状況』への《見通し》から生じる《求める思いこみ》が《正命》である。この《肉の塊》の「『『一切』の中の『この《肉の塊》の状況』』への《見通し》」から生じる《求める思いこみ》が、この《肉の塊》の《正命》である。 この《肉の塊》からの『一切』への《見通し》。と、 この《肉の塊》からの『この《肉の塊》の状況』への《見通し》。と、 この《肉の塊》からの『『一切』の中の、この《肉の塊》の状況』への《見通し》。が、重要。 この《肉の塊》からの『一切』への《見通し》は、始め、『一切』の《混濁》への《見通し》として現れる。 この《肉の塊》は《プログラミング・オブジェクト》への《求める思いこみ》を失ってしまった、てゆーか、《思いこみ》を捨ててきたのだから、それが成功したのだ。 この《肉の塊》は、《他者からの思いこみ》を感じることによって、《プログラミング・オブジェクト》への《求める思いこみ》を、《背後者》のうちに生成する。 人々は、《プログラミング・オブジェクト》への《求める思いこみ》を、《私》にたいして、《他者からの思いこみ》として、《私》に噴出する。それが、『仕事』であったり、欲・得・快・楽であるかは、別として・・。触→受。 理性的プログラムと感性的プログラム 理詰めで考えて、納得できるような操作性のプログラムと 感覚的にやってみて、肌に合うプログラム。 [mysql 13390] Re OS X Server 上のバージョンアップに関して Macユーザたるもの、マニュアル/ドキュメント類を見てはならない。まずダブルクリック、次にダブルクリック、そしてクリッククリッククリック。それで使えないようなソフトは使わない。 マウスであれば感性的プログラムか？ まさか。 マウスでクリクリして、突然終了したり、ワケのわからないメッセージがでたり、滅多に使わない選択肢や、危険な選択肢や、一度押してしまうと戻るのが大変な選択肢が間違ってクリックされやすいところにあれば、すれば、感性的に肌に合うプログラムとはいえない。 キーボードオンリーでも、業務の流れに従って、カーソルキーでサクサク出来るなら、感性にあっているといえる。 マウス操作というものを理解できないのだ。途中の項目への移動を省略できるメニュー、表示や編集窓を兼ねたメニュー、といった所か？ コンピュータを操る《肉の塊》の感性とはなにか？ 操りつつある《肉の塊》は、動きつつある《肉の塊》であり、知りつつある《肉の塊》であり、感じつつある《肉の塊》であり、求めつつある《肉の塊》であり、決めつつある《肉の塊》である。 《肉の塊》の《求めつつあるモノ》は何によって決まるのか？ 《他者》のコトバ？ 《肉の塊》からの《求められつつある思いこみ》。自発的奉仕←《他者》からのコトバへの自発的奉仕。《他者からの思いこみ》を研究しなければ、彼らの肌にあうプログラムはできない。 《プログラミング・オブジェクト》と拒否権 《プログラミン・グオブジェクト》はメソッド呼び出しに応じる。 《プログラミング・オブジェクト》はメソッド呼び出しに対して、拒否権を有する。点検して、例外を生成する。 《他者》と同様である。 拒否するためには余分な労力(点検)が必要である。これも、《他者》と同様であろう。 《プログラミングオブジェクト》は、そのプログラムがコンピュータによって実行されている状態においては、コンピュータからの《描かれつつある思いこみ》である。 《プログラミングオブジェクト》は、そのプログラムがコンピュータによって実行されている状態においては、そのコンピュータの《アニマ》の一部である。 コンピュータは《アニマ》を持つ。コンピュータ自身の《アニマ》と、それが実行する《プログラミング・オブジェクト》が、コンピュータにもたらす疑似的な《アニマ》とは、別のモノである。ヒトがコトバを発する本能を持つのと同様に、コンピュータはプログラムを実行する本能を持つ。ヒトがコトバを発する欲求を持つのは《生きモノ》としてのヒトの本能（生得的行動様式）である。コンピュータがプログラムを実行する欲求を持つのは、コンピュータの生得的運動様式である。コンピュータは、そのように設計され、そのように製造されたから、そのような生得的運用様式を持つ。ヒトはコトバを発する物体であると共に、それ以前に《生きモノ》である。コンピュータも、プログラムを実行する物体である以前にモノである。ヒトは《生きモノ》としての《アニマ》を持ち、コンピュータはモノとしての《アニマ》を持つ。 《プログラミングオブジェクト》は作者にとっては《描かれた思いこみ》であり、利用者にとっては《指し示す思いこみ》である。 《プログラミングオブジェクト》を、利用者が理解するということは、《描かれた思いこみ》として理解することである。 プログラムを読んで、もしくは、ソフトの動作を見て、作者の《描かれた思いこみ》を想像することが、《プログラミングオブジェクト》を理解するということである。 《使い手》は《プログラミング・オブジェクト》を《理解》しない。《道具》は使えればよい、のであって、理解する必要はない。《使う》ためには、それを指し示す必要があるかもしれない。《プログラミング・オブジェクト》を指し示すモノは、アイコンでしかない。《プログラミング・オブジェクト》を指し示すアイコンが、《使い手》にとっての《プログラミング・オブジェクト》である。 《プログラミング・オブジェクト》と《他者からの思いこみ》 《プログラミング・オブジェクト》がそのように動くのは、そのように作られたからである。《プログラミング・オブジェクト》がそのように作られたのは、そのように思い描かれたからである。《プログラミング・オブジェクト》はそのように思い描いたヒトの《他者からの思いこみ》である。 道具の《アニマ》と、作者のイデア《思い描き》と、利用者の目的《求める思いこみ》 三体問題。 インターフェース変換と《プログラミング・オブジェクト》 アセンブラのインターフェースをＣのインターフェースに変換すること、Ｃのインターフェースをrubyのインターフェースに変換すること、rubyのインターフェースをアプリケーションのインターフェースに変換すること。 アプリケーションのユーザーはアプリケーションのインターフェースを通してruby、Ｃ、アセンブラのインターフェースを通してコンピュータにアクセスしている。 イシイ・ヨイワル・プロオブ・１００ イメージ作りは『よい』？ ○：。×：無駄。インタラプトが入るので出来ない。 イシイ：《息しつつあるモノ》からの『一切』。 ヨイワル：『よい』『わるい』。 プロオブはイシイの中の一つである。 プロオブはテクネーである。最高の知的営為であるわけではない。君子は器ならず。 このヒト、この《肉の塊》はイシイのうちの一つである。体内世界、体外世界、《身体》表面の区分はイシイのうちの一つである。 プロオブはこの《肉の塊》の体内世界に生じる《思い描き》である。《いま・ここの・この肉の塊》。 プロオブは『よい』。存在するモノであるが故に『よい』。イシイ、《息しつつあるモノ》からの『一切』において生じたモノであるが故に『よい』。 他律的オブジェクトモデルと《プログラミング・オブジェクト》 現在のＯＯＰプログラミング言語で他律的オブジェクトモデルが採用されているのは、自律的モデルのためには、全てのオブジェクトにCPU時間を割り当てなければならなくなるから。スレッドで切り替えていたら、遅くて使い物にならない。 自律的オブジェクトモデルを実現するためには、全てのオブジェクトに一つ以上のCPUが割り当てられるようなコンピュータが作られなければならない。（生きモノは、単細胞レベルで、そのような状態になっている。） 《プログラミング・オブジェクト》とコンピュータからの《思い描き》 コンピュータからの《思い描き》はあり得るか？ ○： ＯＯＰなプログラムは、コンピュータにオブジェクトを教えるのである。教えられたコンピュータは《思いこみ》をもつのだ。 「ＡならばＢ」も《思いこみ》、《思い描き》である。「ＡならばＢ」の群れも同様であり、群れのシステム化としてのオブジェクトも同様である。 オブジェクトとは「ＡならばＢ」の規則の群れの細胞分裂である。 オブジェクトは、コンピュータからの《思い描き》であり、その《思い描き》によって生じた、コンピュータの中のモノである。コンピュータの中の《思いこみの世界》の中のモノである。 コンピュータの中に、コンピュータからの《思いこみの世界》がある。 コンピュータは《思いこみの世界》の中のモノであるオブジェクトの《思いこみ》に入り込み、一人百役となってオブジェクト間の対話を開始する。 《思い描き》はコトバを聞いたときにも生じる。 ×： ロード中は《思い描き》をもつが、直ちに、「ＡならばＢ」の規則の群れに還元される。 コトバを聞いて生じるのは《思いこみ》であって、《思い描き》ではない。 《プログラミング・オブジェクト》と『一切』 《プログラミング・オブジェクト》は『仕事』の《思いこみ》から生じた手段的《思いこみ》、《道具的な思いこみ》である。道具的、手段的な《思い描き》である。 《サル山のサルの群れ》⇔《息しつつあるモノ》⇔《背後者》⇔《噴出しつつあるモノ》⇔『仕事』 『仕事』はサヤサムからの《私》への《求める思いこみ》である。 《プログラミング・オブジェクト》と《モノの世界》 《プログラミング・オブジェクト》は、《私》、《他者たち》およびコンピュータたちに内在する《思いこみ》である。 《プログラミング・オブジェクト》と自律的オブジェクト 現在の通常の《プログラミング・オブジェクト》は奴隷的オブジェクトである。自律的オブジェクトではない。現在の通常のコンピュータのオブジェクトが奴隷的なのは、アルゴリズムに従うからではなく、自律アルゴリズムをプログラムされていないからである。 自力復元力と《プログラミング・オブジェクト》 モノには自力復元力があるが、《プログラミング・オブジェクト》には自力復元力が無い。 不要なデータ、不要な変更を捨てる仕組みが無い。 データ確認責任者と《プログラミング・オブジェクト》 プログラムで扱うデータが、実際の《モノの世界》のデータと異なっていたのでは、処理する意味がない。プログラム上のデータが、実際の《モノの世界》のデータと同じであることを確認するヒト、データ確認責任者というモノと項目が必要。 「データ確認」マークに「データ確認責任者」の項目を加える。プログラム上のデータの「データ確認責任者」が、実際の《データ確認責任者》が確認作業を行ったことを、確認できない？ データの偽造は考える必要がない？ 過失・不注意によって、データと実際とが異なることを防止する。 コトバとモノとの離存性の問題。実践的な解決方法が求められている。棚卸し、という行動様式。 看板屋のエントウ 看板屋のエントウには、看板を欲する人々の《求める思いこみ》がある。 内部世界と外部世界、トポロジカルな反転。 外部世界の中のオブジェクトは一つのモノである。 オブジェクトの内部世界にとっては、外部世界は一つのオブジェクトである。 顧客にとっては銀行はオブジェクトである。買い物のために銀行からカネをおろして、買い物をして、おつりを銀行に入れる。 銀行にとっては顧客はオブジェクトである。預金者の引出し要求に対して通帳を点検して貨幣を引き渡す。預金者が預金しに来たら受け取って通帳に記入する。 外部世界の中のオブジェクトと、内部世界の中の外部世界オブジェクトとは、トポロジカルに反転した世界である。 なんで、googleで検索すると俺っちが出で来ちゃうんだよ。。http //wiki.fdiary.net/moikomi/?cmd=view p=%A1%D8%BB%C5%BB%F6%A1%D9 key=%A5%C8%A5%DD%A5%ED%A5%B8%A5%AB%A5%EB%A4%CA%C8%BF%C5%BE 隠蔽と《プログラミング・オブジェクト》 隠蔽は、複雑な関係を単純化して、理解可能にする、ということ。 オブジェクトは壁のようなモノ。壁の向うがどうなっているか知らないが、入出力の関係は知っている。どういう処理をするかは知っているが、どのように処理するかは知らない。 隠蔽は善か？ 知っていたほうがよいのではないか？ 知るべきではない、というのは、おかしい。知ってしまうと、オプティマイズの誘惑が出てきて、密な結合になってしまい、交換可能性がなくなる。とはいっても、オブジェクトＡを使う場合には、α処理の反応が１０秒で、β処理の反応が1/1000秒だが、オブジェクトＢを使うと、α処理に1/1000秒、β処理に１０秒かかるとすると、利用者側の対応は変らざるをえない。両方を使い比べて、時間を計って、適切な方のオブジェクトを使え、というのは無責任。しかし、何秒かかるかは外部仕様の問題だ。内部でどのような処理を行っているかは、直接には関係がない。外部仕様に、ｘｘ処理には時間がかかる、ｘｘ処理は速い、という記述をしておくべき、ということ。ｘｘが出来る、だけではなく、ｘｘをするためにはｘｘ秒かかる、ｘｘをすると副作用としてｘｘがある、ということも外部仕様のうち、ということ。処理速度の問題は隠蔽性の問題ではない。 隠蔽は理解を深めるか？ 深めるはずがない、浅めるのだ。浅くても理解可能である、というメリットであって、理解を深めることではない。できるだけ単純な外部仕様のオブジェクトは、理解が容易である。浅い理解でも使えるようになるから、利用可能になるための理解が容易である。浅い理解、深い理解、利用可能になるための理解。使い手としての理解と作り手としての理解。使うために深い理解が必要なオブジェクトと、使うために浅い理解でよいオブジェクト、とではどちらがよいか、ということ。隠蔽することにメリットがあるのではない。深い理解を隠蔽しても、浅い理解で利用可能になる、というのがメリット。 隠蔽することにメリットがあるのではなく、隠蔽されていても利用可能になるということにメリットがある。内部を隠蔽しても構わなくなる、というのがメリット。隠蔽しても使えるようにするべきだ、という「べし」論。 隠蔽のメリットは、複雑さの解消による理解可能性の回復である。複雑なオブジェクト群のネットワークを一つのオブジェクトの入出力仕様（外部仕様）に置き換えることが出来るようになる、というメリット。 ＩＤと《プログラミング・オブジェクト》 ＩＤはモノへのＩＤでなければならない。 モノへのＩＤである場合には、そのモノに別名がある場合、同名異物がある場合。名前とＩＤとは多対多の関係にある。名前とＩＤとの関連テーブルが必要になる。 《息しつつあるモノ》と《プログラミング・オブジェクト》 《息しつつあるモノ》の視点から見て《プログラミング・オブジェクト》は思い込みであり、体内世界の中のモノである。 《体内世界の中のモノ》と《プログラミング・オブジェクト》とはどう違うのか？ 《体内世界の中のモノ》は《プログラミング・オブジェクト》である、とは言わない。 《プログラミング・オブジェクト》は《体外思いこみ》の中のモノである。《私》とコンピュータとの間の空間にある、《私》から噴出した《体外思いこみ》の世界の中に在る。《思いこみ》の個体間循環の中に在る。 外部手順は、関係原因である。外部原因。４原因説。形相因。 内部手順は、内部原因、質料因である。 《プログラミング・オブジェクト》の外部原因は、それを使うユーザのイメージである。 ユーザーイメージと《息しつつあるモノ》。《息しつつあるモノ》と《他者》の《動き》。《私》の《動き》の記憶。《息しつつあるモノ》の《動き》の現認と記憶。周囲のモノたちの《動き》の現認と記憶。 《プログラミング・オブジェクト》の《動き》の妥当性は、そのまわりのモノたちの《動き》との調和性の検証にある。 《息しつつあるモノ》と、モノたちの《動き》の記憶または現認。《動きつつあるモノ》ではなく、始めと終わりのある《動き》のイメージ。四次元時空の中の《動き》。《息するモノ》は四次元時空の中で始めと終わりのある《動き》である。《息しつつあるモノ》は永遠の今の中での持続である。 永遠の今＝四次元時空からの《視点》。始めと終わりののある《動き》＝四次元時空への《視点》。 GUIとエントウ GUIのエントウで照らされるのは、コンピュータの《アニマ》ではない。コンピュータの《アニマ》はその表面の模様には興味がない。ヒトが、怒って赤くなったり、冷や汗を書くことがヒトの精神の主たる作用でないのと同じこと。 GUIのエントウで照らされるのは、コンポーネントプログラマの意図である。高慢で、ユーザを見下し、カネのために、売れやすい見栄えのコンポーネントを作る意図である。その向うにあるのは、『愚かな人々』である。見栄えのよいGUIに釣られ、GUIのプログラムに依存して他律的に行動しようとする『愚かな人々』である。『愚かな人々』の向うには何が在るか？ 『愚かな人々』のエントウ。サルから進化した人類の歴史がある。サルの子孫のエントウ。生物の進化の歴史。地球の歴史、《宇宙史》。 コンピュータは賢者のオモチャからサルの子孫の餌に進化した。GUIはサルの子孫の餌である。この餌には毒をし込むのは簡単である、毒が入っていない保障はない。にもかかわらず、嬉々として餌に飛びつく。サルの子孫の餌のエントウ。 人々の《求める思いこみ》の無限遠点は、もとから、青く透明で輝いている。灯明を照らしても見えない。ナンデダロ？ 《サルの灯明》。 データベースと遠点灯明 データベースは、ヒトのコトバをモノとして操るモノである。ヒトの《思いこみ》を（間接的に）操るモノである。データベースは《思いこみ》を《操りつつあるモノ》である。ヒトの《思いこみ》を操るモノである。モノによって《思いこみ》を操られるヒトが在る。モノによって《思いこみ》を操られて動くヒトが在る。データに基づいて行動するヒトが在る。給与のデータに基づいて給与を支給するのだ。 GUIと遠点灯明 着ぐるみのウサギのような無気味な恐怖を感じる。 GUIオブジェクト。外見と内部構造と、イベント。 プログラムインターフェース(API)と、データインターフェースと、ユーザインターフェース(UI)。プログラマとの《繋がり》、ストレージとの《繋がり》、ユーザとの《繋がり》。 外部手順と内部手順 外部から見た《動き》と、内部から見た《動き》とは、全然違う。 モノにおいても、ヒトにおいても、内部から見た《動き》、たとえば、法律家や医者が相談や診察において考えることと、患者が専門家を見たときの専門家の《動き》、とは全く異なる。患者から見た専門家の《動き》は、現象を見る→適切なアドバイスが出力される、というだけ。専門家自身の内部からみた《動き》は、現象を見て、専門的知識を展開して、あてはめて、検証して、帰結や対策を取り出して、その対策の妥当性を検証して、アドバイスを語る。 同じモノの《動き》に対する、内部からの《視点》と外部からの《視点》。 プログラマが、オブジェクトの内部手順を考えるというのは、外部からの《視点》か？ プログラマは、《オブジェクト》にとっては外部の存在である。プログラマは、『オブジェクト』という《思いこみ》の内部に入り込む。《思いこみ》への《入り込み》。 《オブジェクト》とモノ 《思いこみ》の中のモノを《オブジェクト》と呼ぶ。 『国家』は《オブジェクト》である。 『お金』も《オブジェクト》である。 『法律』は《オブジェクト》である。 『プロジェクト』は《オブジェクト》である。 『信念』や『目標』も《オブジェクト》である。 幻の中のモノも《オブジェクト》である。 「情報処理」とバズワード シャノンの「情報量」の定義が、「情報」をバズワードにしてしまった。 「情報」は、本来、人間にとっての主観的意味と重ね合わせられた記号である。 「人間にとっての主観的意味と重ね合わせられた記号」をビットデータに還元できる、ということは正しい。しかし、ビットデータは「情報」では有り得ない。最も重要な「人間にとっての主観的意味」を捨象したビットデータは情報ではありえない。 「人間にとっての主観的意味」を「確率」に置き換えるのも賛同しかねる。「確率」を予想するのは、「人間にとっての主観的意味」が重要な場合だ。「人間にとっての主観的意味」が一定であるなら、確率が効いてくるが、通常は、「人間にとっての主観的意味」の差異のほうが大きい。昨日自分の子供が交通事故にあった確率は重要だが、きのう地球の反対側にいる名前を知らない誰かが交通事故にあった確率は、《私》にとってはほとんど重要ではない。自分の子供が交通事故に合う確率と、フォアグラを食べた確率とが同じであっても、情報の重要性は異なる。 データ管理とイトミョウ。 ヒトという名の《肉の塊》はデータ管理を欲する。 欲求分類論では？ 欲求分類リスト。認知欲求。 データ管理と認知欲求。「あれを知りたい」という、存在することは分かっているが、内容を思い出せないデータを、記憶の中から取り出す、ということへの欲求。 脳の中にあったはずの記憶装置の物体化。 ヒトは、文字を知ったときから、記憶装置の物体化を行っている。 ヒトは、「記憶係」を指名したときから、記憶装置の物体化を行っている。 コンピュータはデータ処理以上のことはしない。銃を持った兵士ロボットになると、別かも。改札口を開閉するロボットもデータ処理以上のことを行うか？ モノと名前。モノに関するデータを管理することは、そのモノへのメッセージを送信するために必要。メッセージの送信には贈り物や暴力を含む。データを管理するためにはモノからのメッセージの受信が必要。メッセージの受信には監視や贈り物や暴力を含む。従って、モノのデータの管理は、そのモノ自身へのメッセージの送受信との繋がりがあり、モノとの繋がりは、そのモノを管理することに繋がる。モノを管理するというのは、モノからのメッセージを受信し、《私》の意思・計画に従って、モノへのメッセージを送信し、《私》の意思・計画に従って、モノの《動き》をコントロールすること。 《プログラミングオブジェクト》と《求める思いこみ》、《描かれつつある思いこみ》 プロジェクトとは、《求める思いこみ》であり、その手段としての、《描かれつつある思いこみ》への《求める思いこみ》である。 最終的に求められつつあるモノは、未来のモノであり、未来の状態である。存在しないモノへの《知った思いこみ》である。存在しないモノへの《知った思いこみ》は《描かれつつある思いこみ》である。 《描かれつつある思いこみ》は『最終的に求められつつあるモノ』への《求める思いこみ》の鏡像である。プロジェクトは《求める思いこみ》の鏡像である。 プロジェクトは、《求める思いこみ》とモノたちの《アニマ》との混合であり、モノたちの《アニマ》との調和する思い込みである。《求める思いこみ》がモノたちの《アニマ》と調和するように《求める思いこみ》の鏡像を組み立てていくことがプロジェクトの実行である。 下地となるべきモノたちの《アニマ》を、拾い集めて、《描かれつつある思いこみ》のカンバスに描き写すこと。 《プログラミングオブジェクト》を《求める肉の塊》。 《肉の塊》は本当に《プログラミングオブジェクト》を求めているのか？ どのようにして、《肉の塊》は《プログラミングオブジェクト》を求めるのか？ 《プログラミング・オブジェクト》と『作りたいモノのイメージ』 《求める思いこみ》の一種。 『作りたいモノのイメージ』は《浄化球》の中にある。 『作りたいモノのイメージ』の中に入り込みつつあるモノの鏡像は《浄化球》の中にある。 『作りたいモノのイメージ』の中から実現可能性を点検しつつあるモノの鏡像は《浄化球》の中にある。 ５時までは、イメージがまとまらず。５時をすぎると、イメージそのものがなくなってしまう。 時間軸は《浄化球》の中にあり、《群生相》は《浄化球》の中にある。 《プログラミング・オブジェクト》と名前 《プログラミング・オブジェクト》は、自分の名前を知らない。《プログラミング・オブジェクト》がname属性を持つ場合には、nameを聞かれれば、その名前を答える。が、それがその《プログラミング・オブジェクト》の名前であるとは言えない。下のプログラムでは、 obakasan という名前で呼ばれたオブジェクトが、自分は orikousan だと答えている。 require phi obakasan = Phi Form.new orikousan p obakasan.name #= orikousan ディレクトリ名や、ファイル名、サービス名で、同名異体や異名同体があると、混乱する。できる限り、URI（宇宙的に同定できる名前）であるべきだが、そうでないことができる、ということは、名前とオブジェクトの関係は任意であり、状況依存的であるということ。 名前とオブジェクトとの関係が一意でなく、状況依存的だということは、（その状態のままでは）オブジェクトを語ることができないということを意味する。 オブジェクトの名前は状況依存的であるから、オブジェクトを語るためには、毎回、定義を、何を指し示すかを限定するための記述を、行わなければならない、ということ。 《プログラミング・オブジェクト》は「目に見えないモノ」である。「目に見えないモノ」は名前で呼ぶしかないのだが、名前とモノとの関係が不安定だ、というのが、困難の原因となる。 新しく買ったHDに名前を付けたのだが・・。製品名と製造番号で特定するのが良いのか？ usb接続の外づけHDなので、接続すると、/mnt/xx_USB_device-sda1 というディレクトリができて、それを通じてアクセスすることが出来るようになる。では「xx_USB_device-sda1」という名前とは何なのか？ そのHDには「xx-24」という名前を付けた。 「xx_USB_device-sda1」という名前は、USBで接続された機器、という程度の意味しかない。それが「xx-24」である可能性は、確実ではない。 「xx-24」ディスクのルートに「xx-24.id」というファイルを作成したのだが、そのファイルがあるからといって、「xx-24」である可能性は確実ではない。 一つの《プログラミング・オブジェクト》に沢山の名前を付けるといういこと。名前を付けるというのは、或る《視点》（ドメイン）のために或るモノに名前を付ける、ということ。《プログラミング・オブジェクト》は、名前が付けられない限り、見ることもアクセスすることもできない。名前を付けることによって、見たりアクセスすることが可能になる。名前を付けるということは、或る《視点》から、そのモノが見えるようになるということ。名前は《視点》のためにある。 《プログラミング・オブジェクト》の名前というのは「見えないモノを呼び出す秘密の呪文」のようなものだ。昔話の魔法の様だが、（逆に、《プログラミング・オブジェクト》のこのような性質に触発されて、昔話が改作されている可能性もある）、昔の魔法も、これと同じだったのだろうか？ 《プログラミング・オブジェクト》と《頼み合い》 頼むことと、頼まれること。 「たのむ」というのは「た（手）の（宣べる）む（状態にする）」じゃないのかな。手を合わせて、述べること。「た（手）のぶ（述べる）」か。 《プログラミング・オブジェクト》と『一切』（ｂ） 《プログラミング・オブジェクト》からの『一切』への《見通し》。有り得ない、か？ 《宇宙史》は、すべての粒子の状態パラメータの多次元座標における、一本の軌跡として表現できる。或る瞬間の宇宙は、一点で表現できる。その軌跡を表現できるマシンは、《思い描き》においては、可能である。（（実際に作るにはメモリが足りない））。 要素数やパラメータ数を減らして、『一切』をシミュレートすることは可能だろう。 問題は、モノが《極座標の原点》であること。《極座標の原点》は関数として表わすことができるだろう。《関数の群れ》を、プログラム的に表現できれば、『一切』をシミュレートすることが可能だろう。或る関数から見た世界は、その関数へのインプットの再構成である。 《プログラミング・オブジェクト》と『一切』（ａ） 《プログラミング・オブジェクト》は《思い描き》である。《思い描き》は『一切』への《見通し》と両立するのか？ 《プログラミング・オブジェクト》からの『一切』への《見通し》。有り得ない、か？ 『一切』への《見通し》の中での《思い描き》。 『ｘｘプロジェクト』の《思い描き》からの『一切』への《見通し》。 『ｘｘプロジェクト』の外部世界からの、『ｘｘプロジェクト』への噴出。ユーザは『ｘｘプロジェクト』の外部世界のモノである。完成前のプロジェクトにユーザというモノはない。完成前のプロジェクトのユーザは《思い描き》である。『プロジェクト』の《思い描き》の中の要素の一つとしての、『ユーザ』の《思い描き》である。『プロジェクト』の《思い描き》からの、『『一切』への《見通し》をもつユーザ』への《思い描き》。 《思い描き》は《見通し》を持つことができない。《思い描き》は《見通し》への《思い描き》を持つことができる。《思い描き》は『一切』への《見通し》への《思い描き》を持つことができる。『プロジェクト』の《思い描き》からの、『一切』への《見通し》への《思い描き》。は、有害無益である、か？ 全てを考慮し、全てを満足させるプロジェクトは不可能なプロジェクトであり、プロジェクトが成り立つためには、切り捨てが必要である、が、切り捨てということは、初めから見ないということではない。 『プロジェクト』への《思い描き》に溜まった《思いこみ》や、『プロジェクト』への《思い描き》に噴出してくる《思いこみ》を、《浄化球》によって切り捨てること。『プロジェクト』への《思い描き》に鏡の《視点》を起き、その《視点》から、如悪悪臭・如好好色を行うこと。 『プロジェクト』への《思い描き》が感じることができる『一切』への《見通し》。『プロジェクト』への《思い描き》の中の《視点》において、感じることができる『一切』への《見通し》。『ｘｘプロジェクト』の《思い描き》からの『一切』への《見通し》。『ｘｘプロジェクト』からの『一切』への《見通し》。 《プログラミング・オブジェクト》の外部世界の『一切』は、《クライアント・オブジェクト》と、《サーバ・オブジェクト》である。《クライアント》からの依頼を受け、《クライアント》に結果を返す。その処理の過程で、《サーバ・オブジェクト》に処理を依頼し、《サーバ》からの結果を受ける。《クライアント・オブジェクト》と《サーバ・オブジェクト》。 イベントの受信ハンドラは、《クライアント》からのイベント処理依頼の引受である。通常のメソッドによる、処理依頼と、どう違うのか？ イベントの処理依頼は、通常は、ＯＳが直接の《クライアント》である。非同期の処理依頼である。 イベントハンドラを直接呼んだ場合は？ ＯＳ等の基盤システムからの処理依頼でも受け取ることができる（能力のある）タイプのメソッドである。非同期、処理中の重複の処理依頼でも受け付けるタイプのメソッドである。 検索