blogインタープリズム株式会社の開発者ブログです。inlineこんにちは、andoです。Javaとしてとても使いやすく弊社の開発でも採用が増えています。Javaから多くの改善が行われていますが、Javaとの相互運用のため制限となっている機能もあり、その一つに型消去があります。型消去については詳しく書きませんが、Javaでは総称型のメソッド、コンストラクタの実行時に型パラメータの情報を取得することがでません。Kotlinの場合、関数については具象化された型パラメータを用いることで実行時に型情報を取得できるのですが、コンストラクタについては具象化された型パラメータは使用できないため、型情報を取得できません。今回はそのコンストラクタ(っぽい)で型情報を取得してみたというお話です。関数編O/Rマッパーにありそうなレコードを取得するselect()の定義を考えてみます。テーブルの型や型制約については本題ではないので省略させてください。できればこう書きたいこの記述で動作すればシンプルで良いのですが、型消去により関数の実行時に呼び出し側からTの型情報が渡されないためコンパイルエラーとなります。select<String>()}Javaっぽく書くJavaでは引数にClassを渡すのが定石です。関数の定義は冗長ですが、呼び出す側の型パラメータは型推論により省略できます。select(String::class.java)}具象化された型パラメータreifiedを使用します。reifiedを使用する場合はinlineも宣言する必要があります。methodとなるためJavaから呼び出すことはできなくなります。select<String>()}コンストラクタ編O/Rマッパーにありそうなカラムの値を取得する委譲プロパティの定義を考えてみます。getValueをinlineにして引数と戻り値の型をreifiedとしています。person.id}もう一つ型引数を追加すると、、、getValueに型パラメータを追加してもレシーバと戻り値以外は型推論できずコンパイルエラーとなります。そのため、型パラメータをコンストラクタに追加してみますが、関数の場合と同様にコンストラクタの実行時に呼び出し側からTの型情報が渡されないためコンパイルエラーとなります。PropertyDelegate<String>()}具象化された型パラメータコンストラクタは具象化された型パラメータを扱えないため、いずれもコンパイルエラーとなります。inlineの宣言がありません。コンストラクタにinline修飾子は適用できません。classは記述できますが別の機能です。PropertyDelegate(String::class.java)}ファクトリ関数経由で簡潔にKotlinらしくなりました。delegate()}ファクトリ関数の名前をクラス名と同じにする大文字始まりの関数名はKotlinでは一般的ではないこと、また、クラス名と名前空間が異なるため、IDEのリファクタリング機能でクラス名を変更しても関数名は変わらない点に注意が必要です。PropertyDelegate()}ファクトリ関数をコンパニオンオブジェクトに定義するファクトリ関数をコンパニオンオブジェクトに定義し、Invokeを演算子オーバーロードすることで呼び出す際の関数名を無くします。PropertyDelegate()}最後になんとかコンストラクタっぽくなりましたが、実体はコンパニオンオブジェクトに対するinvokeの演算子オーバーロードであることに留意してください。ほとんどのケースはファクトリ関数で十分なはずです。トリッキーなコードは可読性、保守性が低下しますので、使用するにはそれなりの理由、根拠が必要ではないでしょうか。KClassがより適切ではないかと思います。S.K案件配属後1ヶ月が経ちました。グラフDBに関する案件に関わっています。言語はKotlinとTypeScriptを使っています。どちらも初めての言語でしたが、研修で学んだJavaやJavaScriptと関係があるので、基本文法などの習得はスムーズにできていますが、Vue.jsなどのフレームワークに苦戦しています。実装は先輩社員に教わりながらしています。1日でも早く戦力になれるように頑張りたいです。グラフDBについてもよくわかっていないので、勉強したいと思っています。Y.O配属されて1ヶ月が経ち、ようやくプロジェクト全体の方針がぼんやりと理解できたような気がします。配属された案件はサービスが3つあり、おおよそ同じ処理をするのですが、各々で別の処理やメソッドがあるため、なかなか理解することが難しく感じます。そのため、1つのことをやった後に、次に別のサービスについて見ると異なっている部分がすぐには分からず、頭の切り替えがついていかないこともあります。今のところ、プロジェクト全体の観点や特定のサービスの観点や、他の処理との兼ね合いから「こうあるべき」という判断はできません。理解が足らない部分があるため、質問や現状報告の際にうまく表現できないことがあるのが問題です。そこで、分からない部分があればその度に少しづつ先輩に質問して、それぞれのサービスの特徴を理解に努めたいと思います。使用している言語やツールには少しずつ慣れてきたので、手すきの時間にそれらの勉強もしたいと考えています。研修内容とはガラリと変わり、まだまだ戸惑う部分が多いですが、新しいことを知る絶好の機会だと捉えて、プロジェクトの理解を進めたいと思います。今回、GitLabを別のサーバーに移し替えたのですが、GitLabのデータを一旦バックアップしてその後新サーバーでレストアするという手順を踏みました。それなりにハマりポイントがあったので作業ログとして残します。原則としてここの手順を元に作業しました。時間が惜しい人はこれで。dbcache情報ソースが知りたい場合は続きをどうぞ。Calendarを愛しています。