前のトピックを表示 :: 次のトピックを表示 |
著者 |
メッセージ |
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: [草稿]Rhino 変更ログ (3つ) 投稿時間: 2005年10月06日(木) 23:55 |
|
|
以下のドキュメントを草稿にします。(ホントは 1.5R5はまだだけどそのうち ・・・)
Rhino 1.6R2 変更ログ (Rev.:1.2)
Rhino 1.5 Release 4.1 変更ログ (Rev.:1.1)
Rhino 1.5R5 変更ログ (Rev.:1.3)
|
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
件名: インタフェースメソッドとして JS 関数を渡す 投稿時間: 2005年10月18日(火) 02:57 |
|
|
Rhino 1.5R5 変更ログ
で、最初の塊が読みにくいです。
原文が言わんとしていることは読み取れたんですが、わかりやすい日本語にするのは難しいですね。
私の改定案もそのまま使える形ではないですが、多少なりと参考になれば幸いです。
1文目、2文目は意訳するしかないかなと思いました。
Quote: | Rhino は、Java のメソッドへインターフェースを指定するところに、JavaScript 関数を指定できます。それは、ただひとつのメソッドか、あるいはパラメーターの数とおのおのの型が同じ場合です。 |
Rhino は、Java のインタフェースメソッドとして JavaScript 関数を渡すことができます。
これは、以下のようなインタフェースを使用している場合に可能です。
1つだけメソッドを持つインタフェースか、すべてのメソッドの引数の型が一致するインタフェース。
4文目は、as の訳が違ってます。ような ではなく、として の方がこの場合は適切です。
Quote: | 関数は、すべての Java 引数から JS 型へ適切に変換されたものと、そして最後のパラメーターのような(Rhino が用意した)インターフェースメソッドの名前 を受け取るでしょう。 |
関数は JS 型へ適切に変換されたすべての Java 引数を受け取り、更に Rhino は最後のパラメータとしてインターフェースメソッドの名前 を渡します。 |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: Rhino 1.5R5 変更ログ 投稿時間: 2005年10月18日(火) 18:07 |
|
|
こんにちは。
Rhino 1.5R5 変更ログ, 意見を参考に少し変えてみたです。
Quote: | Rhino では、Java のメソッドへ、インターフェースを指定するところに JavaScript の関数を指定できます。 それは、1 つだけメソッドを持つインターフェースか、そのすべてのメソッドの パラメーターの数と型が一致するインターフェースです。
関数は JS 型へ適切に変換されたすべての Java 引数を受け取り、さらに (Rhino が用意した) インターフェースメソッド名を最後のパラメーターとして受け取るでしょう。 |
濱崎 wrote: | わかりやすい日本語にするのは難しいですね。 |
ですね。
最初のトコは, 「インターフェースの実装かアダプターを拡張したのを指定するところ, JavaScriptだから LiveConnectを利用できる訳だけど, ソレが今回 functionを直接指定できる」 … て話で, 詳しく書くとかえって分かりにくいかもです。(「」の中を読んでも分かりにくいと思うし)
# インターフェースメソッドとしての関数の指定は, それまでの, interfaceを newする方法で可能だったです。
で, asの「として」も変えてみたです。 その文の少し上の h3要素にもアレしました。
(前半が)関数から見ての話なので, 文の前半と後半をあわせるよう変えてみたです。
んで, 実はまだ問題点が多々あるです。(分かる方, お願いします)
○ Callable インターフェース
○ 静的なキャッシュを行わない
Quote: | キャッシュされたオブジェクトはもうスコープオブジェクトへの参照をつかんでいません〜 | の文はまだ翻訳中だけど, コレも意味が分からなかったり。
○ Context シーリングのための API
ここも微妙れす。
○ 巨大なスクリプトの改良されたサポート
「サイズと複雑さに きわめて少ない制限を持ちます」のトコが日本語になってないよーな ・・・ |
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
件名: Rhino 1.5R5 変更ログ 投稿時間: 2005年10月19日(水) 01:28 |
|
|
反映してもらってありがとうございました。上の投稿で quote されてる部分、
最初のトピックからのリンクから読めるものと文面が違いますね。
さらに修正が入ってますか?
http://hp.vector.co.jp/authors/VA014690/docs/rhino_rhino15R5.html
Quote: | インターフェースを持つものを指定するところに |
Callable について
Quote: |
…新しいインターフェース org.mozilla.javascript.Callable の実装です。それは org.mozilla.javascript.Context の新しい call メソッドによって、明示的に Context.enter() や Context.exit() を呼び出すことなく、簡単にスクリプトや関数を呼び出すことができます。 |
ちょっとした言い替えですが、
…新しいインターフェース org.mozilla.javascript.Callable を実装しています。
Callable は、 org.mozilla.javascript.Context の新しい call メソッドと合わせて、明示的に Context.enter() や Context.exit() を呼び出すことなく、簡単にスクリプトや関数を呼び出すための機能を提供します。
でどうでしょうか。call() が呼び出す run() が実行の面倒をみてくれるから、ユーザーが enter() や exit() を使う必要はないということですね。
Quote: | Rhino インタープリターは、追加の代理 Script オブジェクトに、スクリプトコードをラップすることなしに直接 org.mozilla.javascript.SecurityController へ参照を通すために、スクリプトや関数に対し Callable を使用します |
ここは、
Rhino インタープリタは Callable を使用してスクリプト及び関数への参照をorg.mozilla.javascript.SecurityController に直接渡します。
スクリプトコードを改めて代理 Script オブジェクトにラップする必要はありません。
とでもしておけば、Java が分かる人にはわかると思います。
まずはここまで。 |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: Rhino 1.5R5 変更ログ 投稿時間: 2005年10月19日(水) 22:44 |
|
|
こんばんは。
濱崎 wrote: | 上の投稿で quote されてる部分、
最初のトピックからのリンクから読めるものと文面が違いますね。
さらに修正が入ってますか? |
入ってます。
濱崎 wrote: | Callable について
Quote: |
…新しいインターフェース org.mozilla.javascript.Callable の実装です。それは org.mozilla.javascript.Context の新しい call メソッドによって、明示的に Context.enter() や Context.exit() を呼び出すことなく、簡単にスクリプトや関数を呼び出すことができます。 |
ちょっとした言い替えですが、
…新しいインターフェース org.mozilla.javascript.Callable を実装しています。
Callable は、 org.mozilla.javascript.Context の新しい call メソッドと合わせて、明示的に Context.enter() や Context.exit() を呼び出すことなく、簡単にスクリプトや関数を呼び出すための機能を提供します。
でどうでしょうか。call() が呼び出す run() が実行の面倒をみてくれるから、ユーザーが enter() や exit() を使う必要はないということですね。 |
一部反映したです。
てゆーのも, Callableにはコンテキストの指定が必要で, そのまま使うには enter()とか exit()とか呼び出さないとアレだからです。
Contextオブジェクトの新しい方の callメソッドでは, ソレを勝手に用意してくれるので大丈夫カモ。callable.call()とコード化(記述)されてるトコによって, そのインターフェース経由で呼び出すです。
濱崎 wrote: | Rhino インタープリタは Callable を使用してスクリプト及び関数への参照をorg.mozilla.javascript.SecurityController に直接渡します。
スクリプトコードを改めて代理 Script オブジェクトにラップする必要はありません。
とでもしておけば、Java が分かる人にはわかると思います。
まずはここまで。 |
σ(^^) には用語がアレで結局分からなかったりするです。分かる人に分かるのならソレで構わないので, 全面的に採用しました。 |
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
件名: さらにいくつか。 投稿時間: 2005年10月24日(月) 15:14 |
|
|
Quote: | Java のメソッドへ、インターフェースを持つものを指定するところに |
読んでいて Java の用語としてピンと来ないので、
Java のインターフェースが持つメソッドの代わりに
という代案を考えました。
それから、No static caching の最後にある
ever growing caches
というのは、増え続けるキャッシュ ではないでしょうか?
ever green が常緑樹 ( いつも緑 ) だというのと同じ意味で。
Quote: |
濱崎 wrote:
Rhino インタープリタは Callable を使用してスクリプト及び関数への参照をorg.mozilla.javascript.SecurityController に直接渡します。
スクリプトコードを改めて代理 Script オブジェクトにラップする必要はありません。
とでもしておけば、Java が分かる人にはわかると思います。
まずはここまで。
σ(^^) には用語がアレで結局分からなかった |
Orca さんに、どこがわからなかったのかはっきりしませんが、推測も交えて。
代理 Script オブジェクトにラップ については、
Java ではメソッドに渡ることができる引数の型が厳密に決まっているから、
スクリプトコードをそのまま渡すことができなくて(受け入れ側にそういう型がないため)
従来は Script オブジェクトの 文字列フィールドに代入して渡す
とか、そういう手段が取られていたのではないでしょうか?
スクリプト及び関数への参照 というのは、
Java ではポインタがない、というのが建前ですが、
大きなオブジェクトを渡す時など、値渡しだけでは不便なので、
内部では参照渡しが使われることがあります。
C にも関数へのポインタ が存在するように、
Java でも、実行できるもの(メソッド)に対する参照 は存在します。
Java Script については知りませんが、きっと似たようなものがあるのでしょう。 |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: さらにいくつか。 投稿時間: 2005年10月24日(月) 23:21 |
|
|
こんばんは。
濱崎 wrote: | Quote: | Java のメソッドへ、インターフェースを持つものを指定するところに |
読んでいて Java の用語としてピンと来ないので、
Java のインターフェースが持つメソッドの代わりに
という代案を考えました。 |
うーむ 。メソッドではなく, アダプタークラスとか無名クラスの代わりなのです。
濱崎 wrote: | ever growing caches
というのは、増え続けるキャッシュ ではないでしょうか?
ever green が常緑樹 ( いつも緑 ) だというのと同じ意味で。 |
「キャッシュが増大していた」と書いてるトコれすね。
たしかにあまり分かりやすくはないけど ・・・
「今まで増え続けていたキャッシュを終わらせ」?
あるいは「今までキャッシュが増え続けていましたが」でしょーか。
濱崎 wrote: | 代理 Script オブジェクトにラップ については、
Java ではメソッドに渡ることができる引数の型が厳密に決まっているから、
スクリプトコードをそのまま渡すことができなくて(受け入れ側にそういう型がないため)
従来は Script オブジェクトの 文字列フィールドに代入して渡す
とか、そういう手段が取られていたのではないでしょうか? |
そーいやこのよーな文脈, 訳した記憶あるです。
蛇足かもだけど, runtime.htmlてゆー(Rhinoの) 未訳のドキュメントも その変換のことを扱ってるです。
濱崎 wrote: | スクリプト及び関数への参照 というのは、
Java ではポインタがない、というのが建前ですが、
大きなオブジェクトを渡す時など、値渡しだけでは不便なので、
内部では参照渡しが使われることがあります。
C にも関数へのポインタ が存在するように、
Java でも、実行できるもの(メソッド)に対する参照 は存在します。
Java Script については知りませんが、きっと似たようなものがあるのでしょう。 |
ありがとございます。何についての説明の文なのか分かった気がするです。
ただちょっと補足とゆーか ・・・
JavaScriptでもオブジェクトの扱いは Javaとほぼ同じです。ただしプリミティブ・タイプは無いはず。
んで, 参照先を別オブジェクトに変更したりするときは配列として渡したりとか, そんなトコも同じれす。
でも, 「参照渡し」なのではなく参照が渡されるだけです。すべてが値渡しで, その内容が「参照」。
渡す内容が「参照」でないのは, Javaでのプリミティブ・タイプくらいでしょう。 |
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
件名: Re: さらにいくつか。 投稿時間: 2005年10月25日(火) 00:10 |
|
|
Orca wrote: | メソッドではなく, アダプタークラスとか無名クラスの代わりなのです。 |
完全に勘違いしてました。
Orca wrote: |
濱崎 wrote: | ever growing caches
というのは、増え続けるキャッシュ ではないでしょうか?
ever green が常緑樹 ( いつも緑 ) だというのと同じ意味で。 |
「キャッシュが増大していた」と書いてるトコれすね。
たしかにあまり分かりやすくはないけど ・・・
「今まで増え続けていたキャッシュを終わらせ」?
あるいは「今までキャッシュが増え続けていましたが」でしょーか。 |
今まで というのは忘れた方がいいと思います。
ever はここでは「同じ状態が続く」という意味で使われているので、
prevents memory leaks through ever growing caches
キャッシュが増え続けることで起きるメモリリークを防ぎます。
でどうでしょうか。
Quote: | 「参照渡し」なのではなく参照が渡されるだけです。すべてが値渡しで, その内容が「参照」。
渡す内容が「参照」でないのは, Javaでのプリミティブ・タイプくらいでしょう。 |
オブジェクトを指すものとして参照を渡すのと、参照を「値渡し」することの違いが理解できません。
Java Virtual Machine のスタックの中では、ポインタ渡しと同じ挙動をしていそうな気がするのですが…。
このあたりを解説した良い文献をご存知ないでしょうか? |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: さらにいくつか。 投稿時間: 2005年10月25日(火) 22:41 |
|
|
こんばんは。
濱崎 wrote: |
prevents memory leaks through ever growing caches
キャッシュが増え続けることで起きるメモリリークを防ぎます。
でどうでしょうか。 |
そーですね。その方が分かりやすいかもなので修正しました。
濱崎 wrote: | Quote: | 「参照渡し」なのではなく参照が渡されるだけです。すべてが値渡しで, その内容が「参照」。
渡す内容が「参照」でないのは, Javaでのプリミティブ・タイプくらいでしょう。 |
オブジェクトを指すものとして参照を渡すのと、参照を「値渡し」することの違いが理解できません。
Java Virtual Machine のスタックの中では、ポインタ渡しと同じ挙動をしていそうな気がするのですが…。
このあたりを解説した良い文献をご存知ないでしょうか? |
変数を指定しての関数呼び出しを考えると分かりやすいかもです。これらは主にプログラミング言語によって異なるです。
- その変数の値が渡される … call-by-value
- その変数の参照(アドレス) が渡される … call-by-reference
- その変数の名前が渡される … call-by-name
例えば C言語では値渡しだけど, "&"を付けることで参照渡し(っぽく?) ができる, と。
Java/JavaScriptでは, 変数に保持しているブツ自体が「参照」になってる訳で, 変数のアドレスが渡されている訳じゃないれす。 (Javaのプリミティブ型の変数が保持しているのは「参照」ではなく「値」だけど)
call-by-referenceができる言語で, 関数内部のトコで 渡された変数への代入を行うと, 元の変数の内容も換わる訳です。
文献は知らないけど, Webではここが参考になるかもです → http://java-house.jp/ml/archive/j-h-b/026214.html
追記:
翻訳に関係ないのが続くけど, 補足です。
関数内部から引数の変数に代入すると, call-by-referenceでは元の内容が換わるのは上でもアレしたとおりだけど, 書き換えられたくない場合はどーするかっつーと, 言語のサポートがなければこんな手を使って一時エリアに移したりするです。
Code: | func(param) → func(param+0) とか func(param+"") とか func((param)) など |
変数の渡し方はどれもメリット/デメリットがあるので, 使用している言語がどーゆーものかを知らないと思わぬバグが出たりするです。そこで, call-by-×× などと区別されてるです。 |
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
件名: Re: さらにいくつか。 投稿時間: 2005年11月04日(金) 21:03 |
|
|
Orca wrote: | 濱崎 wrote: | prevents memory leaks through ever growing caches
キャッシュが増え続けることで起きるメモリリークを防ぎます。
でどうでしょうか。 |
そーですね。その方が分かりやすいかもなので修正しました。
|
修正ありがとうございました。
Orca wrote: | 濱崎 wrote: | オブジェクトを指すものとして参照を渡すのと、参照を「値渡し」することの違いが理解できません。
Java Virtual Machine のスタックの中では、ポインタ渡しと同じ挙動をしていそうな気がするのですが…。
このあたりを解説した良い文献をご存知ないでしょうか? |
例えば C言語では値渡しだけど, "&"を付けることで参照渡し(っぽく?) ができる, と。
Java/JavaScriptでは, 変数に保持しているブツ自体が「参照」になってる訳で, 変数のアドレスが渡されている訳じゃないれす。 (Javaのプリミティブ型の変数が保持しているのは「参照」ではなく「値」だけど)
call-by-referenceができる言語で, 関数内部のトコで 渡された変数への代入を行うと, 元の変数の内容も換わる訳です。
文献は知らないけど, Webではここが参考になるかもです → http://java-house.jp/ml/archive/j-h-b/026214.html
|
ありがとうございました。
参照を渡すことと参照渡しは違うんですね。
C言語に参照渡しはない ことがわかっていませんでしたので、とても勉強になりました。
Quote: | 関数内部から引数の変数に代入すると, call-by-referenceでは元の内容が換わるのは上でもアレしたとおりだけど, |
call-by-reference では、渡されたものを変更しても、渡した側での値は変わらないのでは?
教えてもらった Java House での説明では、
呼び出された関数(の入口)には、値を参照するためのアドレスが渡るけど、呼び出された関数はそのアドレスを使用して取得した値のみを使用する
と読めました。 |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: さらにいくつか。 投稿時間: 2005年11月04日(金) 23:06 |
|
|
濱崎 wrote: | Quote: | 関数内部から引数の変数に代入すると, call-by-referenceでは元の内容が換わるのは上でもアレしたとおりだけど, |
call-by-reference では、渡されたものを変更しても、渡した側での値は変わらないのでは?
教えてもらった Java House での説明では、
呼び出された関数(の入口)には、値を参照するためのアドレスが渡るけど、呼び出された関数はそのアドレスを使用して取得した値のみを使用する
と読めました。 |
func(param) で呼び出したものを argument aで受け取ったとすると, "a"は paramと同じ値を持つです。てゆーか, 同じアドレスです。print(a) とかすると値を使うことができるけど, ソレに代入すると ・・・
てことで, ある意味 alias変数になるです。
百聞は一見にしかずで, 使ってみた方が早いかも。ググってみたところ, fortranがソレらしいれす。
# σ(^^) が使ってたのはもう手に入らないので |
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Rhino 1.5R5 変更ログ (Rev.:1.3) 投稿時間: 2005年11月21日(月) 23:19 |
|
|
以下のドキュメントはまだ草稿の段階れす。(ロックされてたので)
|
|
|
濱崎
登録日: 2004年1月 27日 記事: 296 所在地: 静岡県
|
件名: あ、ごめんなさい。ロックしてしまったのは私です。 投稿時間: 2005年11月24日(木) 13:25 |
|
|
完成稿フォーラムで出ていた別のページと間違えて、完成稿が出たものと勘違いしてました。
Quote: | 以下のドキュメントはまだ草稿の段階れす。(ロックされてたので) |
|
|
|
nog
登録日: 2005年10月 29日 記事: 25
|
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: REGRESSION 投稿時間: 2005年11月25日(金) 18:28 |
|
|
こんにちは。
nog wrote: |
「後退」という訳より、「退行」の方がいいのでは。 |
上の部分では「退行」にしてるのに, 下ではなぜか違ってるですね。(なぜだろ)
てことで直したです。 |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
|
|
池田
登録日: 2003年5月 22日 記事: 408 所在地: 東京
|
件名: Re: "The cached objects no longer holds〜" 投稿時間: 2006年3月12日(日) 09:56 |
|
|
Orca さん、池田です。和訳お疲れさまです。
Orca wrote: | "The cached objects no longer holds〜" の一文がアレで ・・・
# 技術文書としては読み飛ばせるトコだけど, ソレを翻訳するとなると うまく日本語にならないし (T-T) |
例によって技術的な裏付けのない(^^;
個人的な訳例ですが、二文に分けた方がいいかと。
→ キャッシュされたオブジェクトには、スコープオブジェクト(へ)の参照は保持されなくなりました。従って、これまでのバージョンの Rhino ではあらゆるアプリケーションで生じていた、ランタイム・ライブラリーのインスタンスへの参照のリークは、Context.initStandardObjects や一つの共有された ClassCache インスタンスを複数回呼び出すアプリケーションにおいても生じなくなるでしょう。
multiple calls to Context.initStandardObjects and single shared ClassCache instance の解釈は間違っているかもです。
ご参考まで。 ____________________ Mozilla Japan 翻訳部門 和訳アドバイザー |
|
|
Orca
登録日: 2004年4月 20日 記事: 511 所在地: 関西
|
件名: Re: "The cached objects no longer holds〜" 投稿時間: 2006年3月12日(日) 15:30 |
|
|
こんにちは。
池田 wrote: | 個人的な訳例ですが、二文に分けた方がいいかと。
→ キャッシュされたオブジェクトには、スコープオブジェクト(へ)の参照は保持されなくなりました。従って、これまでのバージョンの Rhino ではあらゆるアプリケーションで生じていた、ランタイム・ライブラリーのインスタンスへの参照のリークは、Context.initStandardObjects や一つの共有された ClassCache インスタンスを複数回呼び出すアプリケーションにおいても生じなくなるでしょう。
multiple calls to Context.initStandardObjects and single shared ClassCache instance の解釈は間違っているかもです。
|
この部分の上のトコで, すでに「キャッシュしません」「スコープは保持しません」とか出てるので, 言い回しを軽くしてたです。「キャッシュ(された)オブジェクト」とか二文に分けることとか。
そんな訳で, 意見を元に換えてみたです。
んで, Context.initStandardObjectsと ClassCacheについては, 前者はメソッドで, Javaから利用するときにオブジェクトの初期化でアレしたりするものれす。後者はクラスで, そのインスタンスを得たりして ・・・ でもそのインスタンスのメソッドを複数回呼び出すものなのかは分からないれす。
ClassCacheは使ったことなくて間違ってるのかもだけど, "キャッシュの共有のときに(以前は) 問題があった" のだと思ったです。
こんなんでどーでしょ。 |
|
|
池田
登録日: 2003年5月 22日 記事: 408 所在地: 東京
|
件名: Re: "The cached objects no longer holds〜" 投稿時間: 2006年3月13日(月) 08:46 |
|
|
Orca wrote: | こんなんでどーでしょ。 |
良いと思います。 ____________________ Mozilla Japan 翻訳部門 和訳アドバイザー |
|
|
|