『try! Swift: Type Erasureのユースケースを考えてみた話』
try! Swift: Type Erasureのユースケースを考えてみた話 | サイバーエージェント 公式エンジニアブログ こんにちは Ameba事業本部でiOSエンジニアをしている @tasanobu です。 先日(3/2～4)、弊社にて try! Swift を開催しました。 try! Swift 世界中のSwiftデベロッパーが一堂に会し、知識や技術を互いに共有し高め合うことを目的としたカンファレンスです。 各セッションは国内外の著名なエンジニアがスピーカーを務めたこともあり、深い話が多く、満足度が高かったです。 反面、一度聞いただけでは使いどころがイメージできないものがありました。 そこで、このエントリではGwendolyn Westonさんによる Keep Calm and Type Erase On にて解説されていた Type Erasure を題材とし、具体的なユースケー
Swiftのジェネリックスについてのメモ - Qiita
自分がジェネリックスという単語自体が初めて聞く言葉であり、 よく理解できてないのでまとめてみた 参照：The Swift Programming Language (iBooks) Genericsとは クラスや関数を使う側が扱う型を指定できるようにする仕組み これにより、抽象的なコードを記述することを可能にする 関数でのGenerics 関数内で使用する任意の型を定義できる 1. 型制約なし 型の制約がないので、どんな型の場合でも使用することができる 任意の型は名前は自由(ただし、UpperCamelCaseであること) func repeat<ItemType>(item: ItemType, times: Int) -> ItemType[] { var result = ItemType[]() for i in 0..times { result += item } return
Swiftのジェネリックなプロトコルの変数はなぜ作れないのか、コンパイル後の中間言語を見て考えた - Qiita
導入 Swiftでは通常のプロトコルは変数の型として使用することができますが、 型パラメータ(associated type)を持つジェネリックなプロトコルの変数は作れません。 非ジェネリックな例 protocol Hogeable { func hoge() -> Int } struct HogeCat: Hogeable { func hoge() -> Int { return 1111 } } let cat = HogeCat() let hogeable: Hogeable = cat // コンパイルOK protocol Fugable { typealias Element func fug() -> Element } struct FugaDog: Fugable { func fuga() -> Int { return 2222 } } let dog = Fu
Swiftの強力な機能であるstaticメソッド制約の紹介と、Kotlin, TypeScript, Java, Scala, C++との比較 - Qiita
Swiftの強力な機能であるstaticメソッド制約の紹介と、Kotlin, TypeScript, Java, Scala, C++との比較C++ScalaKotlinTypeScriptSwift 先に結論 Swiftのstaticメソッド制約はちょっとしたシンプルな機能に見えるけど便利で深い Kotlin, TypeScript, Java で同じことをすると冗長で間接的なコードになってしまう TypeScriptのstaticメソッド注入は独特のテクニックで面白い 提示するJavaの実装は「T を new する」方法でもあるので参考にして Scala は間接的ではあるもののKotlinより良い形でかける SwiftはScalaの形をさらにより良くした形とみなすことができる C++はSwiftと同じ事ができるがわかりにくい書き方になってしまう 導入 Swiftはprotocolという
Keep Calm and Type Erase On
About the content This talk was delivered live in March 2017 at try! Swift Tokyo. The video was recorded, produced, and transcribed by Realm, and is published here with the permission of the conference organizers. Just when you thought having unambiguous types was the one true way of Swift, it turns out that sometimes it is necessary to erase types. In this talk from try! Swift, Gwendolyn Weston e
Swift 型消去 (Type Erasure) - タコさんブログ
try! Swiftで発表のあった型消去の話。 この例ではSwiftにおける型消去技法を使用して、結城さんの 増補改訂版Java言語で学ぶデザインパターン入門 Iteratorパターンを愚直にSwiftで実装する。 前提知識 [増補改訂版Java言語で学ぶデザインパターン入門] Iteratorパターン Swift ジェネリクス・プロトコルの基礎 環境 Xcode 7.2 Swift 2.1 Iteratorインターフェース 要素の数え上げをするインターフェース。 protocol Iterator { typealias Element func next() -> Element? } Aggregateインターフェース SwiftではJava版のように、以下のようにAggregateを定義することはできない。 protocol Aggregate { func iterator()
try! Swift 聞き起こし 平常心で型を消し去る #tryswiftconf Day1-5 - niwatakoのはてなブログ
twitter.com 型を明確にすることがSwiftらしいやり方であると気づいた時、同時に時には型を消す必要があると分かります。この講演では、型とは何か、型を消すことが何を意味するか、なぜそうしたいかについて解説します。 型消去の話をします 怖い？ どういうこと？ 型とは何？ 最高の定義はWikipediaで見つかりました。型とは、分類であり、値の集合とその値に対する有効な演算を定義するものであるということですね。 Swiftコンパイラにとってこれらは便利な考え方です。 StringにIntを入れることは有効ではないわけです。しかしすべての型が平等なのではなく、コンパイラがチェック出来ない型が有ります。 ここで具象型と抽象型を考えます。具象型はダイレクトにインスタンス化でき、明確なデータを持っていて、オブジェクト間でやりとしして情報共有がなされます。 一方抽象型は不完全な実装になります。
Swiftでenumとジェネリクスを活用したかっこいいAPIクライアントを書く - Hatena Developer Blog
この記事ははてなエンジニアアドベントカレンダー2014の16日目です。昨日はid:nobuokaによる「【Retrofit を読む】 利用者が定義したインターフェイスに実装を提供する Java ライブラリの作り方 【リフクレション】」でした。 こんにちは。はてなアプリケーションエンジニアのid:cockscombです。 Webと連携するスマートフォンアプリを開発するとき、Web APIを抽象化したAPIクライアントを作ることがよくあります。これはWeb APIのエンドポイントとメソッドを紐付け、パラメータに名前をつけて、返ってくるJSONのレスポンスを何らかのクラスに当てはめ型付けする、といったようなものになります。 Swiftのモダンな言語機能を利用して、このAPIクライアントを書きましたので、以下に詳解します。例としてGitHubのStatus APIを取り上げています。 またネットワ
キュー構造をJavaで実装してジェネリック型を理解する
キュー構造をJavaで実装してジェネリック型を理解する：【改訂版】Eclipseではじめるプログラミング（19）（3/3 ページ） 【第3改訂】Java APIのジェネリック型も使って実装 ところで、Sample03.Queueクラスで、なぜ「Object[] values = new Object[SIZE+1];」を「T[] values = new T[SIZE+1];」としないのか疑問に思った読者もいるのではないでしょうか。 ジェネリックスでできないこと 実は、ジェネリック型の中では、型変数Tのインスタンス生成や、型変数を指定した配列のインスタンス生成ができません。また、staticフィールドやstaticメソッド内、static初期化子でも型変数は使用できませんやstaticメソッド内、static初期化子でも型変数は使用できません。 これは、クラスとして生成されるのはSampl
new T()したいケースへの対処法 - プログラマーの脳みそ
Javaのジェネリクスの話題のひとつにnew T()したいができないので困る、というテーマがある。 先日のセッションではこの対策についても簡単に述べたが今日はそのまとめ。 まず第一に疑うべきは本当にnew T()する必然性があるか？というのが持論だが、ある種のフレームワークではその必然性がある。 O/RマッピングのフレームワークでPOJOにデータを詰めて返したい WebフレームワークでHTTPリクエストをPOJOに詰めてControllerクラスに渡したい （このあたりの議論はJavaのジェネリクスで，T.class や new T() ができず悩んだ話 （型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ） - 主に言語とシステム開発に関してによくまとまっている） ここで、これらのPOJO(Plain Old Java Object - 端的に言えばデータを格納する
Javaのジェネリクスで，T.class や new T() ができず悩んだ話 （型パラメータのインスタンス化に関し、フレームワーク設計からケーススタディ） - 主に言語とシステム開発に関して
Javaのジェネリクスで，型パラメータ T のインスタンスが欲しくなったことはあるだろうか？ 昨今のオブジェクト指向プログラミングにおいて，ジェネリクスは必須の基本文法だ。 扱う対象のクラスが抽象化されて汎用的になりつつ，なおかつ型安全性が確保される。 そのおかげで，処理の重複や分岐をコーディングする必要が無くなり，コード量が驚異的に削減される。 そういう基本的な原則を踏まえると， 「型パラメータのインスタンスが欲しい」 というシチュエーションは，Javaのジェネリクスの本来の導入目的に真っ向から逆らう。 なぜなら，ジェネリクスは型を抽象化して透過的に扱えるようにするための機構なのだから， せっかく抽象化した物をわざわざ具体化してどうするというお怒りを生む事になるのだ。 頑張って詳細なクラス情報を「T」でパラメータ化して具体性を隠ぺいしたにも関らず， その T に対して .class で具
ジェネリックな設計 再帰編 - プログラマーの脳みそ
11/10に開催されたJJUG CCC 2012 Fallでジェネリクスについてセッションを行いました。 このエントリはセッション内容を補足するものです。基礎的な内容は Javaジェネリクス再入門 - プログラマーの脳みそ ジェネリックな設計 基礎編 - プログラマーの脳みそ などを参照してください。 再帰的ジェネリクス public class Hoge<T extends Hoge<T>> このように、型変数Tに対して境界を宣言したクラスHoge自身にした型変数をもつかたちを指して再帰ジェネリクス・再帰的ジェネリクスなどと呼びます。 このような型変数Tはパラメータ化された型として変数宣言に用いようとすると Hoge<?> hoge; といったようにワイルドカードを用いないと宣言できません。また、newによって型をバインドしようとしても型をバインドすることができません。 再帰的な型変数を
ジェネリックな設計 基礎編 - プログラマーの脳みそ
11/10に開催されたJJUG CCC 2012 Fallでジェネリクスについてセッションを行いました。 このエントリはセッション内容を補足するものです。本セッションはジェネリックなクラスの設計を行えるようになって欲しいという狙いで話をしました。ジェネリックなクラスを利用できるというのは前提条件として書いてます。入門的な内容であれば Javaジェネリクス再入門 - プログラマーの脳みそ を参考にしてください。 セッション資料はこちら ジェネリクスの基礎と応用 JJUG CCC 2012 Fall ジェネリクスのスコープ まずジェネリクスのスコープの話から入ります。Javaのジェネリクスには2つのスコープがあります。 メソッドをスコープとした型変数 インスタンスをスコープとした型変数 後者はおなじみの public interface List<E> などの型変数です。 これに対して pub
ジェネリクスによるVisitorパターン拡張の考察 - プログラマーの脳みそ
先日twitterで "Expression Problem" という問題を知った。 静的な型付けの下で、場合分けのデータ構造に対して、新しい場合分けとその場合に対する新しい処理を、元のソースコードに手を加えることなく拡張定義すること 2009-05-16 この問題が意図するところを語るにはまずオブジェクト指向から流れを辿らねばなるまい。 オブジェクト指向のポリモーフィズム Javaのようなオブジェクト指向の言語で、ある特定のメソッドがあることを抽象クラスHogeで保証するとしよう。 public interface Hoge { void hoge(); } このとき、機能性、つまりメソッドというのは増えることがない固定のものだが、継承して実装されたクラスというのは自由に増やすことができる。そして、抽象型Hogeを扱っている既存コードは修正する必要がない。 これはいわゆる開放/閉鎖原則(
Java総称型のワイルドカードを上手に使いこなすための勘所 - 達人プログラマーを目指して
Java5以降では総称型（generics）がJava言語に導入されています。総称型自体は、最近の静的な型付けのプログラミング言語で珍しいことではなく、現在の最新版では.NETのC#やVisual Basicにも導入されています。一般的には総称型をサポートするクラスライブラリを自分で正しく定義することは非常にスキルがいるが、事前に定義されたクラスを使うだけであれば、それほど難しくないとされています。しかし、Java言語の総称型は本エントリで説明するように特殊なところがあり、単に利用するだけでも他の言語に比べて遥かに難しいところがあるというのも事実です。特に総称型をパラメータ化する際に指定するワイルドカード型（List<? extends Serializable>など)の意味を正しく理解して使いこなすことは簡単なことではありません。その結果、昔のJDK1.4までのように型パラメーターのない
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ジェネリクスの基礎と�クラス設計への応用