Grails React Scaffoldを目指すざます
これはG*Advent callender 2016の記事です。 前日は@Ziphilさんの記事でした。明日は@ hikariruさんの記事です。
去年のG*Advent Calendarでは、本ブログではReact Meets Grails 〜ReactはエンタープライズSPAの夢を見るか？〜 - uehaj's blogと題して、バックエンドを「GrailsのRestサーバ」+「React SPAによるフロントエンド」という組合せをボイラープレート(雛形)として実装してみました。
今年もこの路線を拡充してみます。
背景
GrailsにはScaffold機能、すなわちCRUD操作を行なうためのWeb画面の自動生成機能があり、確かに便利なものではあるのですが、以下の点では不満がありました。
- ページナビゲーション・ルーティング機能不足
- 業務Webアプリ開発で必要になることが多い階層メニュー選択やページナビゲーション機能がそのままではサポートされません。 React Routerのように画面構築と連動したルーティング機能が利用できません。
- ページ遷移ベースであること
- データの各操作1つ1つ(テーブルのレコードを参照、編集、削除...)などにすべてページ遷移が伴ないます。
- 2-way編集の困難さ
- Scaffoldで生成されたGSPやコントローラを何らかの理由で手で修正してしまうと、ドメインクラスを修正したときの再生成に問題がおきたり、もしくは手動での取り込みが必要になります。かといって動的Scaffold、Fieldsプラグインなどでカスタマイズしようとすると後述のカスタマイズの困難さに直面します。
- カスタマイズの困難さ
- Scaffoldの元になる「テンプレート」や部品のレンダリングテンプレートを修正することができますが、GSPはもともとHTMLを生成するテンプレートのようなものなので、「HTMLを生成するテンプレート(GSP)を生成するテンプレート」を書く必要があり、さらに分離されたJavaScriptのコードは生成の埒外なので、それとの連携を考えると3段階を考慮したプログラミングとなり、難易度が高く保守性の低いものとなります。結果的に、たとえば「顧客ごとにカスタマイズした別ビュー」を提供するなどが難しくなります。
- JavaScriptと連携したときの再利用の困難
- GSPにある「ページフラグメント」「タグライブラリ」などは単純なHTML断片を共通化するのには有効なのですが、動的なDOM構築が必要になったときに破綻します。JSを組合せたとき、画面部品の再利用や、保守性の高い構造を達成し保守するのが困難です。(サーバでのHTML生成がかかえる本質的な困難)
- jQueryの問題
- そもそもjQueryベースだと保守性を高くすることが難しい
- GUIの自動試験のしにくさ
- RESTfuul APIならコントローラも試験しやすくなる。またクライアントサイドのJSで利用できるReact Storybookなどの便利な画面部品試験ツールが利用できない。
- クライアント・サーバ間の密結合
- ビューだけの修正時にもアプリのwarパッケージの生成・再デプロイの必要がある。その結果、ライフサイクルが不一致な場合(たとえばiOSのビューを修正するときにAndroid版も止めなければならない)などの問題がある。
- Webアプリとネイティブアプリ(モバイル+デスクトップ)間でのコード再利用・共有が困難
- React NativeやIonic2のような仕組で共有することはできない。
これらのほとんどは、GrailsのScaffoldの問題であると同時に、一般にページ遷移ベースそのもの、そしてアプリに自動生成を適用することの問題でもあります(つまりRailsなどでも同様)。結果として、Scaffoldの実システム開発での利用は管理画面(admin ui)などに留まり、コンテキスト依存サンプルコードとして有用ではあるものの、限定的でした。
解決策
前述の問題は一般的であるが故に、各所でSPAフレームワークやツール等が解決しようと努力なされてきました。その混沌たる候補の中から、ここ数年で突破口が見えてきた気がします。すなわち
上記により多くが解決・改善されます。このことを踏まえて、GrailsのRESTfulサービス開発機能を併用し、開発のベースとなるようなReactとの連携コードサンプルを提供するのが今回記事で紹介している「React Grails Boilerplate」の目的です*1。
上記のような課題を克服することで、実世界アプリ開発を楽にできるようにすることを目指しています(将来的には!)。
作ったもの
以下画面です。
ソースはこちら。
実行方法
% git clone https://github.com/uehaj/grails3-react-boilerplate.git % cd grails3-react-boilerplate % ./gradlew bootRun
bootRunではサーバとクライアントは別プロセスになっていて、並列に動作させています。個別に起動する場合は以下のとおり。
% cd server % ./grailsw run-app & % cd ../client % npm start
去年からの進展
主には以下のとおりです。
- Grails2ベースだったのをGrails 3.2.1ベースへ
- Grails Raect Profileベースに。
- ract-forms-jsonschemaでフォームの自動生成
- react-bootstrap-tableバージョンアップによりjQuery依存の完全排除
- 他、細かい調整いろいろ
特徴
売りとしては、JSON-schemaをGORMドメインクラスから自動生成することで、以下を可能としていることです。
- json-schemaを扱えるフォームライブラリreact-forms-jsonschemaにより、入力フォームの自動生成
- GORMのドメインクラスの制約(constraints)をクライアントサイドの入力フォーム自動バリデーションに自動変換
- ドメインクラスやフィールドの変更追加に対して自動追随
つまりどういうこと?
DBのフィールド増減の際に何箇所も直してまわったり、バリデーションに関しての同じ処理をサーバとクライアントの二箇所で別言語で書いたり*2、整合性を失なうようなことを避けることができます。 もっともこれは従来のScaffoldでも一部できていたことで、JSON-Schemaで汎用的に簡単にできたよ、ということです。
加えて、ドメインクラスの一覧をページ表示時に動的に取得し、対応するメニュー項目、react routerのRoute階層などを自動生成します。
JSONSchemaとは
JSONデータ用のデータスキーマです。バリデーション情報を含んでいます。これにFORMなどの見た目情報を追加する、uiSchemaというものも定義されています。
{ "title": "Example Schema", "type": "object", "properties": { "firstName": { "type": "string" }, "lastName": { "type": "string" }, "age": { "description": "Age in years", "type": "integer", "minimum": 0 } }, "required": ["firstName", "lastName"] }
このスキーマをフォームとして表示、入力、バリデーションができるReactのライブラリが ract-forms-jsonschemaです。
今後やりたいこと
- grails application profile化
- 関連の実装
- 国際化
- pageneteをきちんと実装してレコード数の制約を解除(今はクライアントサイドに一気読み込みのなんちゃってページネーション)
- webpackのhot module replacement対応
- grails constraintsに対応付かないJSONSchema、および uiSchemaをドメインクラス側で明示的に指定するための仕組みの追加。カスタムconstraintsを追加する、生のJSONScehma/uiSchemaを返すためのメソッドをサポートするなど。
まとめ
私がReactに注目しはじめたのは2014年頃とやや遅かったのですが、かれこれ2年たち、Reactは順調に発展・普及し、成熟してきました。今後もますます業務開発で採用される機会も増えてきた/来るのではないでしょうか。 Reactは本来的にはプログラマにとってとっつき易いものですが、それなりの構造を作るのはやはり難しいので、このボイラープレートがサーバサイドプログラマがフロント開発をするための役などにたてば嬉しいです。
ではみなさん、メリークリスマスイブイブ!
WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用
posted with amazlet at 16.12.22
入門 React ―コンポーネントベースのWebフロントエンド開発
posted with amazlet at 16.12.22
Frankie Bagnardi Jonathan Beebe Richard Feldman Tom Hallett Simon HØjberg Karl Mikkelsen
オライリージャパン
売り上げランキング: 46,989
オライリージャパン
売り上げランキング: 46,989
ParrotブランチでGroovy3を垣間見る
これはG*Advent callender 2016の記事です。 前日はわたし@uehajの記事でした。明日は@mshimomuさんの記事です。
はじめに
Groovyの構文解析処理には初期からANTLRというパーサジェネレータのバージョン2(antlr2)が長らく使われてきたのですが、最近Daniel SunさんによってANTLRのバージョン4(antl4)への書き直しがなされました。この新パーサーは"Parrot"と呼ばれています。ParrotのGroovy本体への組込みは、Groovyソースコードの'parrot'ブランチで作業が進められています。
Parrotでは従来との互換を損なわないように全構文が実装されていることに加え、構文レベルでの新たな機能追加がなされており、本記事で紹介します。
Parrotは、構文解析の結果として従来と互換性のある中間コード(抽象構文木)を吐くように設計されており、parrotブランチではすでに実際に新パーサでGroovyコードを実行できるようになっています。
構造上parrotは旧版パーサとコンフリクトせずに同時に組み込んで、システムプロパティで切り換えて使うことができるようになっています。またsubprojectとしてモジュール化され分離されています。parrotが実際にGroovyに組込まれる予定はわかっておりません。記事タイトルは「Groovy 3」としましたが、利用可能になる時期はひょっとしたらもっと早いかもしれません。
Parrotブランチのコンパイル
以下の手順でParrotを試すことができます。
$ git clone https://github.com/apache/groovy.git $ git checkout parrot $ ./gradlew -PuseAntlr4=true -x groovydoc -x test installGroovy $ export GROOVY_HOME=$(PWD)/target/install $ export JAVA_OPTS=-Dgroovy.antlr4=true $ $GROOVY_HOME/bin/groovy $ $GROOVY_HOME/bin/groovysh $ $GROOVY_HOME/bin/groovyConsole
警告
parrotはα以前の段階ですし、将来リリースされたときに仕様が本記事のままである保証は全くありません。また、さらに多数の機能拡張がなされていくことも予想され、期待されます。
do-whileループ
まずはこれ、Javaにはあるdo-whileループが従来Groovyにはありませんでしたが、利用できるようになってます。
groovy:000> do { println i++ } while (i<10) 0 1 2 3 4 5 6 7 8 9
do-while結構使いますよね。待望の、という感じです。
Java8構文
ParrotはJava 8で拡張された構文のいくつかに対応しています。
ラムダ式の記法
筆頭としてラムダ式です。Groovyでラムダ式の記法が使えるようになりました。*1
def list = [2, 3, 1] Collections.sort(list, (n1, n2) -> n1 <=> n2) assert [1, 2, 3] == list
今のところ、セマンティクスは従来のGroovyクロージャと同様です。parrotでのラムダ式のような記法「(a,b,c) -> body」は、クロージャ「{a,b,c -> body}」のシンタックスシュガーと思えばよいでしょう*2。
それを確認するためにGroovyConsoleでinspect ASTしてみます。
上記のように、コンパイル処理の早期段階である「conversion」ですでにクロージャに変換されていることがわかります。
なので、たとえばラムダ式記法を囲むメソッドのローカル変数をクロージャ中から変更することができますし、.apply()とか呼ばなくても()で呼べますし、delegateも機能しています(今のところ)。また、Java8のラムダ式のようにinvokeDynamicに変換されるということも(今のところは)無いでしょう。
細かい話1
Groovyのラムダ式は基本的にJava8のラムダ式に対して構文的には同等もしくは上位互換です。 たとえば、Groovyでも本体ブロックの括弧を省略したりできますし、さらにGroovyの特性としてreturn省略もできます。
(a,b) -> { return a+b } (a,b) -> { a+b } // Groovyの仕様により許可(Javaではreturnが無いと怒られる) (a,b) -> a + b // これならJavaでもreturn無しにできる。もちろんGroovyでもOK。 (int a, int b=0) -> a+b // デフォルト引数はGroovyならでは
しかしながら、わずかに例外もあります。 Javaでは引数が1個の場合、引数の括弧を省略できます。
(a) -> a+1 a -> a+1 // こう書ける。
しかし、parrotでは引数が1個でも括弧を省略できません。理由は、「{ a-> a+1 }」が、「クロージャ」なのか、「ラムダ式を含むブロック」なのかが構文解析上判別できなくなるからだそうです。=>なら区別できただろうに、先見的に->を使ってたのがかぶったという…。
細かい話2
クロージャで使えた暗黙の引数「it」はラムダ式では使えません。
groovy:000> [1,2,3].each ()->System.out.println(it) ERROR groovy.lang.MissingMethodException: No signature of method: groovysh_evaluate$_run_closure1.doCall() is applicable for argument types: (Integer) values: [1] Possible solutions: doCall(), findAll(), findAll(), isCase(java.lang.Object), isCase(java.lang.Object) groovy:000> [1,2,3].each (it)->System.out.println(it) 1 2 3 ===> [1, 2, 3]
穏当です。
メソッド参照の記法
Java8のメソッド参照の記法が使えます。こちらも同様に、Groovyの.&演算子の適用のシンタックスシュガーで、つまり「System.out::println」は「System.out.&println」と同様です*3。
ところで細かい話ですが、 Java8のメソッド参照で「クラス::インスタンスメソッド」と指定すると、第一引数がそのメソッドのレシーバであるような関数を返すのに、 今までのGroovyでは.&演算子で「クラス.&インスタンスメソッド」を指定したとき、そのメソッドに対してレシーバを渡す方法がなく呼び出すことができない、という違いがありました。
具体例を挙げます。Java8のメソッド参照では「クラス::インスタンスメソッド」を指定すると、
a = String::toUpperCase
assert a("abc") == "ABC"
のようにレシーバを第一引数で与えるように変換した関数を返すので、高階関数に渡したりするのにたいへん便利です。 しかし従来のGroovyでは「クラス.&インスタンスメソッド」を指定した場合、
groovy:000> a = String.&toUpperCase
===> org.codehaus.groovy.runtime.MethodClosure@2f67b837
groovy:000> a()
ERROR java.lang.IllegalArgumentException:
object is not an instance of declaring class
groovy:000> a("abc")
ERROR groovy.lang.MissingMethodException:
No signature of method: java.lang.String.toUpperCase() is applicable for argument types: (java.lang.String) values: [abc]
Possible solutions: toUpperCase(), toUpperCase(java.util.Locale), toLowerCase(), toLowerCase(java.util.Locale)
のようにエラーになって呼び出せませんでした。「インスタンス.&インスタンスメソッド」「クラス.&静的メソッド」は可能なのですがね。
parrotでは、Java8のメソッド参照形式でも「インスタンス::インスタンスメソッド」は当然できるし、ついでにGroovy形式の.&で「クラス.&インスタンスメソッド」を指定したとき
a = String.&toUpperCase
a("abc") == "ABC"
が可能になります。つまり.&はJava8のメソッド参照と同様のものになったということです。
コンストラクタ参照
こちらも可能となりました。勢い余ってかメソッド参照(.&)でも同じことが可能になりました。
groovy:000> s = String::new("abc")
===> abc
groovy:000> s = String.&new("abc")
===> abc
default method
これもかなりインパクトのあったJava8で導入された機能でした。
groovy:000> interface Foo { default getName(){ "foo" } }
===> true
groovy:000> class Bar implements Foo { }
===> true
groovy:000> new Bar().getName()
===> foo
groovy:000>
traitと同時にimplementsしたときどうなるのか、とか興味深いですが試してません。 ちなみにJava8ではインターフェースでstaticメソッドが定義可能になりましたが、それはまだ実装されていないようです。
Java7対応
try-with-resources
できます!
% cat a.groovy
class Resource implements Closeable {
void close() { println "close" }
}
try (r = new Resource()) {
println "hello"
throw new Exception()
} catch (Exception e) {
println "catch"
}
% $GROOVY_HOME/bin/groovy a.groovy
hello
close
catch
新しい演算子たち
等値演算子(===, !==)
意味的には、===はObject.is(Javaでの==)、!==はその否定ですね。
groovy:000> "a"+"b"=="ab" ===> true groovy:000> "a"+"b"==="ab" ===> false groovy:000> "a"+"b" != "ab" ===> false groovy:000> "a"+"b" !== "ab" ===> true
エルビス代入演算子(i.e. ?=)
xx = xx ? : 3
の略記法として、
xx ?= 3
と書けます。「変更しようとする変数に値が設定されていなかったら設定する(先勝ち)」です。こんな動きをします。
groovy:000> def foo(xx) { xx ?= 3; println xx }
===> true
groovy:000> foo(null)
3
===> null
groovy:000> foo(5)
5
===> null
groovy:000> foo(0)
3
===> null
GroovyTruthで判定するので0は負けます。
!in, !instanceof
これは、私にとって今回の一番のお気にいり演算子です。
groovy:000> 3 !in [1,2,4] ===> true groovy:000> 3 !in [1,2,3,4] ===> false groovy:000> "a" !instanceof Integer ===> true groovy:000> "a" !instanceof String ===> false
読みやすく書きやすい。
参考資料
以下の前者は記事をほぼ書きおわった後発見してちょっとショック。
まとめ
Groovyは本来Javaの上位互換言語であり、「任意のJavaコードは(ほぼ)Groovyコードでもある」が売りの一つでした。今回のパーサで導入されたJava8、Java7 の互換向上機能は、しばらくの間、いくぶん損なわれてしまっていたそれらのメリットを再度取り戻すものであるでしょう。また、今後の機能拡張の基盤ともなるものです。
コミッターも増え、Apache Groovy開発が活性化してきております。来年の発展が楽しみです。
プログラミングGROOVY
posted with amazlet at 16.12.15
List.collectManyで非決定計算
これはG*Advent callender 2016の記事です。 前日は@Ziphilさんの記事でした。明日はまた私@uehajの記事です。
出オチでタイトルオンリーです。
すごいHaksell楽しく学ぼう(以降H本)にも書かれているように、リストはモナドとみなすと「非決定計算」をあらわすものとみることができます。
つまりたとえばリスト[1,2,3]を「1か2か3のどれか」、リスト[2,3]を「2か3のどれか」をそれぞれあらわすもの、と見るってことです。その上で、[1,2,3] * [2,3] という操作を何等かの方法で表現すれば、「1か2か3のどれか」に「2か3のいずれか」を掛けたものという意味になり、結果として「1*2,2*2,3*2,1*3, 2*3,3*3]すなわち「1か4か6か3か6か9のどれか」を得ることができます。
さて、Groovyのリスト(厳密にはIterable)には、collectManyというメソッドがあって、これは上記のようにリストを非決定計算と考えたときの、任意の計算を「何等かの方法」で適用すること*1に相当します。
やってみます。
H本の例
ghci> [1,2] >>= \n -> ['a','b'] >>= \ch -> return (n,ch) [(1,'a'),(1,'b'),(2,'a'),(2,'b')]
ここでは「1,2のどっちか」と「'a','b'のどっちか」をタプル化操作したもののどれか( [(1,'a'),(1,'b'),(2,'a'),(2,'b')] )を得ています。 これをGroovyで考えると以下のようになります。
groovy:000> [1,2].collectMany{n -> ['a','b'].collectMany{ ch -> [[n, ch]] }} ===> [[1, a], [1, b], [2, a], [2, b]]
Haksellと同様の結果が得られます(Groovyにはちゃんとしたタプルが無いのでリストで代用)。
ピタゴラス数を求める
次に同様にcollectManyを使ってピタゴラス数を求めてみましょう。
ピタゴラス数とは、a^2 + b^2 == cを満たす3つの数です。aが10までの範囲で求めてみます。
(1..10).collectMany{ a -> (1..a).collectMany{ b -> (a..a+b).collectMany{ c -> return (a**2 + b**2 == c**2) ? ["a=$a, b=$b, c=$c"] : [] }}}.each { println it }
実行すると
a=4, b=3, c=5 a=8, b=6, c=10
を出力します。
覆面算を解く
もう一つ応用例です。以下のような有名な覆面算を解いてみます。
SEND +) MORE ~~~~~~~~~~ MONEY
上記を成立させるように、アルファベットに重複せずに数を割り当てる問題です。
この問題は、Sが「1〜9のどれか」Eが「1〜9のどれか、かつSではない」…という可能性をもった非決定的な数同士であり、それらがある条件を満すかどうかを判定する非決定計算の問題とみることができます。 これをcollectManyを使って解くと以下のようになります。
def digits = 0..9 as List def isAnswer(S,E,N,D,M,O,R,Y) { (S*1000+E*100+N*10+D) + (M*1000+O*100+R*10+E) == (M*10000+O*1000+N*100+E*10+Y) } (digits-0).collectMany { S -> (digits-S-0).collectMany { M-> (digits-S-M).collectMany { E-> (digits-S-M-E).collectMany { O-> (digits-S-M-E-O).collectMany { N-> (digits-S-M-E-O-N).collectMany { R-> (digits-S-M-E-O-N-R).collectMany { D-> (digits-S-M-E-O-N-R-D).collectMany { Y-> if (isAnswer(S,E,N,D,M,O,R,Y)) { return ["""\ $S$E$N$D +)$M$O$R$E $M$O$N$E$Y """] } return [] }}}}}}}}.each { println it }
上記は以下を出力します。
9567 +)1085 10652
メタクラスさん登場
collectManyがちょっと字面上うるさいという場合、
List.metaClass.rightShiftUnsigned = { x->delegate.collectMany(x) }
のように演算子「>>>」に割り当てても良いかもしれません。
List.metaClass.rightShiftUnsigned = { x->delegate.collectMany(x) } def digits = 0..9 as List def isAnswer(S,E,N,D,M,O,R,Y) { (S*1000+E*100+N*10+D) + (M*1000+O*100+R*10+E) == (M*10000+O*1000+N*100+E*10+Y) } ( (digits-0) >>> { S -> (digits-S-0) >>> { M-> (digits-S-M) >>> { E-> (digits-S-M-E) >>> { O-> (digits-S-M-E-O) >>> { N-> (digits-S-M-E-O-N) >>> { R-> (digits-S-M-E-O-N-R) >>> { D-> (digits-S-M-E-O-N-R-D) >>> { Y-> if (isAnswer(S,E,N,D,M,O,R,Y)) { return ["""\ $S$E$N$D +)$M$O$R$E $M$O$N$E$Y """] } return [] }}}}}}}}).each { println it }
現場からは以上です。
余談
あとは余談ですが、「}}}}}}}}.each {」の閉じ括弧の連続が嫌ですね。これはGroovyのクロージャの記法{->}の作りが良くなくて、今回の用法ではネストが必要になるので、複数の閉じ括弧が必要になるというわけです。ここをJava8のラムダ式の記法で書ければ良いと思いませんか? つまり
( (digits-0) >>> (S) -> (digits-S-0) >>> (M) -> (digits-S-M) >>> (E) -> (digits-S-M-E) >>> (O) -> (digits-S-M-E-O) >>> (N) -> (digits-S-M-E-O-N) >>> (R) -> (digits-S-M-E-O-N-R) >>> (D) -> (digits-S-M-E-O-N-R-D) >>> (Y) -> { if (isAnswer(S,E,N,D,M,O,R,Y)) { return ["""\ $S$E$N$D +)$M$O$R$E $M$O$N$E$Y """] } return [] }).each { println it }
と書く。やってやれないことはない、どうしたら良いのか?ということは明日の記事に回したいと思います(伏線)。
参考
すごいHaskellたのしく学ぼう!
posted with amazlet at 16.12.15
JWTトークン認証つきのWeb APIを作るのはGrails+Spring Security REST Pluginを使えば非常に簡単である件
先日のJGGUG WSでのLT資料を公開します。「JWT」は、ついジェーダブリュティーと読んでしまいましたが、正しい発音は「jot（ジョット）」だそうです。
ちなみに、上記デモで使用する認証スキームBearerというのがあるんですが、この由来は「持参人払い小切手(Bearer Check)」から来てるそうです*1。「持参人払い小切手」とは、自筆の署名(サイン)がしてある小切手を銀行窓口に持ってきたならば、その持ってきた人が誰であるかにかかわらず、現金を支払う、というものだとのことです。たしかにBearer認証スキームと同様ですね。
Web API: The Good Parts
posted with amazlet at 16.05.19
*1:帰りに杉本さんに教えていただきました。ありがとうございました
Grails 3ってどうよ+ ＬＴ大会 - 日本Grails/Groovyユーザーグループ
連休明け5/13に、JGGUG(日本Grails/Groovyユーザ会)より、上記イベントがございます。
Sring BootをGSPとscaffold、GORMなどでさらに使いやすくしたフルスタックフレームワーク、Grails3について、実務適用している人たちとの情報提供、議論を行います。また恒例のLT大会も行います。
ふるってご参加ご検討ください。
Javaにも不変データ構造に基づいた(Cons セルベースの)リストがあるのだよ
TL;DR
JDK(tools.jar)中、com.sunパッケージ配下に、javacが内部的に使っている「com.sun.tools.javac.util.List 」が含まれており、これは不変データ構造としてのリストのように(Cons セルベースのリストのように)利用できる。
はじめに
ScalaのコードをGroovyやJavaなどに移植する際に、いつも悲しい思いをするのが不変データ構造に基づいたリスト処理ライブラリが見あたらない、ということでした。JDKの標準コレクションライブラリには、Scalaのscala.collection.immutable.Listのような、不変データ構造を用いて実装されているリストがありません。
ここで言う不変データ構造に基づいたリストとは、JDKのjava.util.Collections.unmodifiableList()等で取得できるような変更禁止ビュー、つまり「要素追加などを禁止するバージョンのリスト」のことではなく、あるいはGrooovyの@Immutableによるイミュータブル指定でもなく、
「要素の追加は可能だが、その意味は、元のリストの変更ではなく、要素が追加された新しいリストを返す」
というもので、さらに実装として「リストを丸ごとコピーして追加して返す」のではなく、「追加前のリストと実体を共有することによって、メモリ利用効率を下げない(そして追加前のリストは不変であることも保証される)」ことが期待されます。もう少しぶっちゃけて言えば、Lispの「ConsセルベースのList」が欲しいのです*1。
もちろん、サードパーティ製のものもあるにはあるでしょう。Functional javaのとか、Clojureのを使うとかはできるのかな。しかし基本的にはやみくもには外部依存を増やしたくはないものです。自分で作りたくもない。
com.sun.tools.javac.util.List
最近知ったのですが、少なくともjava8までのJDKには、com.sunパッケージ配下に「com.sun.tools.javac.util.List 」というクラスがあり、これがまさに求めるものです。ただし、com.sunパッケージにあることから判るように標準APIの一部ではなく、将来的に使える保証はありません。もし使う場合は、将来使えなくなるリスクを覚悟して使う必要があります。さらに、rt.jarではなくtools.jarに含まれているので、JREとしては使用できずJDKの元で使えるものです。javaコマンドから利用する場合、tools.jarをクラスパスに指定することが必要となるでしょう。
※ @kmizuさんにご指摘いただきましたが、これはコメントに記載があるようにGJCつまりGeneric Java Compiler由来のもので、確かこれはScalaのMartin Oderskyさんの関わっていたプロジェクトではないですか。ある意味ご縁があるわけです。
@uehaj なるほどー。知らなったのですが、"List is the main container class in GJC. Most data structures and algorthms in GJC use lists rather than arrays."
使い方
com.sun.tools.javac.util.Listの機能としてはこんな感じ。
| 意味(適当な表記) | 書き方 |
|---|---|
| nil | List.nil() |
| car(a) | a.head |
| cdr(a) | a.tail |
| cons(a,b) | b.prepend(a) |
| [a,b,c] | List.of(a,b,c) |
使用例
これを使えば、例えば2リストキューを用いた非破壊的キューもほらこのとおり(cf.20分でわかるPurely Functional Data Structures)。
import com.sun.tools.javac.util.List; import java.util.function.*; public class Queue<E> { public static class Tuple<E> { E value; Queue<E> queue; Tuple(E value, Queue<E> queue) { this.value = value; this.queue = queue; } } private List<E> front; private List<E> rear; public Queue(List<E> front, List<E> rear) { this.front = front; this.rear = rear; } public Queue() { this(List.nil(), List.nil()); } long size() { return front.size() + rear.size(); } public String toString(){ return "front<"+front+rear.reverse()+">rear"; } public Queue<E> add(E e) { return new Queue<E>(front, rear.prepend(e)); } public Tuple<E> remove() { if (front == List.nil()) { if (rear == List.nil()) { return new Tuple<E>(null, this); } return new Queue<E>(rear.reverse(), List.nil()).remove(); } else { return new Tuple<E>(front.head, new Queue<E>(front.tail, rear)); } } }
Groovyでさらに
Groovyでは以下の点で使いやすいです。
- tools.jarは標準でGroovy実行時のパスに入っている
- 名前のかぶるListではなく、「import com.sun.tools.javac.util.List as ConsList」のようにリネームしてインポートできる。
なお、残念ながらGroovyでは右結合の演算子をオーバーロードできないので、ScalaやHaskellの::のようにカッコなしで要素繋げる表記を使用することはできません(AST変換を使わないかぎり)。
もっと、もっと…欲しいんじゃっ…!
連想リストのマップっぽく使えるようした物が欲しいですが、それは見つけられませんでした(実装するのはたぶん難しくない)。
Purely Functional Data Structures
posted with amazlet at 16.05.25
Chris Okasaki
Cambridge University Press
売り上げランキング: 50,281
Cambridge University Press
売り上げランキング: 50,281
Purely Functional Data Structures
posted with amazlet at 16.05.25
Chris Okasaki
Cambridge University Press
売り上げランキング: 242,093
Cambridge University Press
売り上げランキング: 242,093
