旬のフルーツパフェを食べよう
本記事について
って言われました。
自己紹介
私は食べるのが好きです。今週は有馬温泉で有馬牛のステーキとしゃぶしゃぶを食べました。どうだうらやましいだろう。他にも色々食べているからフォローして飯テロを食らえ:Instagram
好き嫌いせず食べているのに*1最近はいろんな方面からパフェばっか食べてる人と思われています。月初めに欠かさず高野のメニューをチェックしたり桃パフェを食べまくっていたりしたせいだと思います。
本記事では皆さんが私をパフェに誘いやすいようにパフェについて語ります。写真は全て今年食べたものです。パフェじゃない写真が大量に混ざっていますが美味しそうなので許されるはずです。
フルーツパフェを食す理由
世の中には甘いものがたくさんあります。中でも果物は美味しく季節を堪能できる優れものです。夏バテなどで食欲がないときの味方でもあります。
私の好きな果物は桃や洋梨などの甘くてジューシーで柔らかい果物です。よりにもよって選別や追熟が難しいものばかりです。これらは一歩間違えれば固くて渋くて食べたことを後悔します。
せっかく高い金払って買ってワクワク完熟を待ったのに!!ガリガリでエグくて部分的に痛んでた!!!
ですからお店で果物を食べましょう。私はりんごやいちごやメロンやマンゴーも好きですが、これらは追熟がっかりリスクが低いためお店では食べません。
お店で果物がそのまま出ることはあまりありません。お店ではスイーツを食べましょう。ここで乳脂肪が合わさると最強です。近年は夏に生クリームを泡立てることが難しくなっており専門店のありがたみが身に沁みます。
猛暑で生クリーム固まらず 菓子店ケーキ作れず 秋田 | NHK | 気象
果物と生クリームからなるスイーツはパフェを含めていくつかあります。
- フルーツパフェ
- フルーツサンド
- フルーツケーキ
フルーツサンドやフルーツケーキのほうが入手難度が低いです。コンビニやケーキ屋さんで手軽に買えます。しかしフルーツサンドは通年で流通する果物を使用していることが多くフルーツケーキもシロップ漬けのフルーツを使用していることがよくあります [要出典] 。
通年で流通しているキウイ*2やバナナでは旬を楽しむという目的に合いません。
↑撮影時の季節を推測させないフルーツたち
旬を楽しむことが目的なら保存食を思わせる加工や大きく食感が変わる加工がないほうがよいでしょう。生の果肉の食感を楽しめるのは旬のうちだけです。
↑カミッチュ
その点フルーツパフェなら旬の果物がそのままトッピングされます。確実に旬を楽しめるスイーツはフルーツパフェと言えるでしょう。
↑シロップ漬けではない旬の果物を使ったサンドイッチ
手軽に旬と乳脂肪を摂取する、そのためのフルーツパフェです。
↑漬けることがむしろ当然の旬
パフェシーズンとフルーツの提供時期
パフェで旬を味わえる時期は5月から12月ごろです。1月から4月はいちごやメロンが中心のため旬を味わう趣旨に合いません。4ヶ月間もメニューが変わらないなんて耐えられないよ……
お目当ては追熟がっかりリスクの高い果物であり定期的な乳脂肪の摂取です。次の図は果物がパフェとして食べられる時期をざっくり示したものです。
産地や品種が豊富な果物であれば一般に認識される旬の期間よりも長く提供されます。桃やいちごなどは何度か通って食べ比べてみるとよいでしょう。産地を味わえるのも果物そしてパフェの魅力です。
↑果物の産地がメニューに明記されているタイプのパフェ
いちごはスーパーで手軽に買えていちご狩りという最強のイベントまであります。パフェ屋さんに行く必要はありません。しかし冬場の乳脂肪不足を補うために摂取します。
↑2月のいちごパフェ
パフェに採用される果物として上記以外にもオレンジやキウイや巨峰やいちじくや柿や栗がありますが私がちゃんと認識してないのでよくわかりません。
店選びと予算
それではパフェ屋さんを選びましょう。次の表は私の独断による店の分類です。予算は東京都23区内を想定しドリンクバーや紅茶やサービス料を含みます。
店のタイプ | 予算 | 特徴 | 客層 | 利用場面 |
---|---|---|---|---|
ファミレス | 〜1500円 | 正直映えも味も劣るけど絵に描いたようなパフェで童心に帰れるのはこのあたり。各地に店舗があって回転率が良くてカロリーが正確にわかるのもファミレス(というか大手チェーン店)の強み。 | 子供でもソロでも誰でも入りやすい。 | 気楽に利用したいとき/デザート以外のメニューを狙うついで/何でもいいから近場のお店で今すぐ食べたいとき |
ファミレス(上) | 〜2000円 | ほどほどに高い価格帯のおかげで堅実な仕上がり。下手なパフェ専門店より美味しい時がある。脂質などカロリー以外の栄養成分も公開している。 | ファミレスなのに通常のファミレスより子供の数が少なめ。 | 予算を少し多めに確保できるとき |
都道府県アンテナショップ | 1000〜2000円? | アンテナショップ併設のレストラン。主役はあくまでご当地の土産に民芸品に郷土料理。スイーツのための店ではないので味はそれなり?実はあんまり行ったことないのでわからない。 | メインの客層は40代から上くらいじゃないかしら。 | 郷土料理を食べてご当地商品を物色するついで |
パフェ専門店 | 2000〜3000円程度 | 店によるから分からん。基本的には映え重視のお店が多いか。 | 店によるから分からん。女性ソロ or 女性グループ? | 冒険したいとき/流行りを確かめたいとき/映え狙い |
贈答用果物屋さん | 3000円前後 | 贈答用果物屋さんのパフェ。控えめな見た目ながら味は確か。出自が贈答用なのでデパートの中やその周辺にある。接客も丁寧。混んでるのが難点。 | 女性グループや夫婦。時々女性ソロ客や稀に男性ソロ客もいる。子供連れもいてみんなお行儀がよい(おとなしい子しか来てないとも言う)。 | 高くても混んでいてもいいから美味しいものを食べたいとき |
ホテル | 3500円〜 | 歴史あるブランドやホテルが経営するパフェ屋さんケーキ屋さん。もちろん接客は丁寧。果物自体の味は確かだが、スイーツへの解釈違いで期待と異なる味になることが稀にある…かも……。 | ソロ客はまずいない。みんないい服着てる。 | 人生で1回くらいは食べに行ってもいいかなと思ったとき/お祝いごとがあったとき/辛いこと頑張ったことのごほうび/最高の給仕を受けてもビビらない度胸があるとき |
後述するようにパフェには紅茶が欠かせないためドリンクバー or 紅茶代を含めています。お店によってはサービス料の計算も必要です。
↑サービス料が加算されるケーキ
旬の果物と乳脂肪を重要視する私のようなタイプなら3000円を握りしめて贈答用果物屋さんに行くのがよいです。塩分と油分も取りたいならファミレスでお肉とパフェを食べるとよいです。友達付き合いで食べるなら予約ができるかどうかなどの利便性を重要視しましょう。買い物を楽しむならアンテナショップも選択肢にあがります。
↑ノドグロ丼デザート付き
パフェ屋さんに行く時間
パフェ屋さんは席数が多くなく回転率も低めのお店です。おやつどきには長蛇の列になります。人気のメニューが早々に品切れしてしまうこともあります。事前にスケジュールを練って挑みます。予約?そんなものないよ(一部除く)。
私の場合、
- 開店凸する
- 平日に行く
のいずれかを行なっています。
もちろん1番確実なのは両方の組み合わせ、平日の開店凸です。有給がもったいなければエクストリーム出社パフェをします。狙い目は商業施設内の店舗です。基本的にパフェ屋さんは11時ごろの開店ですがテナントなら施設全体に合わせて10時ごろに開店します。
超人気店で数量限定のパフェを食べるなら開店凸か平日決行が必須です。ランチ時点でとっくに売り切れていることがあります。
一部のパフェ屋さんでは発券機とウェブサイトで残り時間を確認できるようになっています。便利な世の中になりました。
↑開店30分前に獲得したはずの整理券
紅茶
パフェは甘くて冷たい食べ物です。温かくて苦い飲み物で舌の感覚をリセットするためにコーヒーまたは紅茶を注文します。和風のカフェの場合は抹茶や緑茶を注文できるはずです。
↑別に抹茶の店というわけではないのでコーヒーで食べる締めパフェ
ある程度の苦みが必要なので砂糖は不要かと思います。ミルクは乳脂肪だからどばどば入れちゃう。つまり無糖ロイヤルミルクティーが最高だ。だがウィンナーコーヒーは認めない*3。
↑無糖生クリームを美味しくいただくセット
大抵の場合はパフェと同時に熱々の紅茶を給仕してくれます。冷えた舌を温めることが目的なので同時に飲みごろを出してくれるお店がよいです。
紅茶の種類?よくわかんないけどハーブティーみたいな主張の強いフレーバーでなければなんでもいいんじゃね?多分選べるほど取り揃えがないし。
↑ガチの紅茶屋さんで食べるレモンタルト
パフェのレイヤー
パフェは多層構造のスイーツです。パフェグラスに多種多様な層が積まれています。
大抵の場合は店頭でレイヤーごとの完全な説明がないため食べてからのお楽しみです。
↑説明書きを提供するパフェ屋さんのパフェ
メニューやプレスリリース上でレイヤーごとの紹介をしていることもあります。あらかじめ予習をするとよいでしょう。
「クイーンストロベリー」を真紅に輝くティアラのように飾りたてた華やかなパフェ。グラスのなかには「クイーンストロベリーシャーベット」「バニラアイス」が入っております。 https://www.sembikiya.co.jp/_bosys/wp-content/uploads/2023/03/deme_menu20230401.pdf
とか
高い糖度を誇る国産のアップルマンゴーを贅沢に使用した、季節限定の“エクストラスーパーシリーズ”。ふわふわでありながらしっかりとした「玄米卵」の生地と、口当たり軽やかな大牟田産生クリームがマンゴーの味わいを引き立てます。2層目はパッションフルーツ風味に仕上げ、見た目もより鮮やかに。香り高い濃厚なマンゴーの味わいが広がる"究極のショートケーキ"をお愉しみください。 https://www.newotani.co.jp/tokyo/press-release/2023/0428-01/
とか
トップの桃をほおばるとみずみずしい果汁が口いっぱいに広がります。グラスに食べ進むと、オレンジピールが香りのアクセントとなるオレンジピーチソースと、桃のグラニテやクリーム、ゼリーが重なります。桃のやさしい印象の中にもオレンジのさわやかさが残る夏らしい一品です。https://prtimes.jp/main/html/rd/p/000000055.000076727.html
長すぎてもはや呪文。 ていうかポエム
てっぺんの飾り
ミントや生クリームやチョコや小さいベリーなどがかわいく乗っていたり乗っていなかったりします。
素敵な飴細工やクッキーなどがトッピングされたパフェを注文したら手間暇に思いを馳せながら到着を待ちます。
↑1日に何本の飴をくるくるさせられているか考えさせられるパフェ
正直なところ ポエム 説明を読まなくてもパフェを楽しめるのですが、クリームの種類だけは忘れずに予習しておきます。生クリームだと思って植物性ホイップクリームやチーズクリームを口にすると違和感を覚えてしまいます。
乳脂肪の味を期待してクリームを口に含んだら全然違った!!!
果物&アイス
ディッシャーで球形にアイスクリームを乗せカットフルーツを立てかける部分です。素敵にカットされた主役へ目を奪われますが縁の下の力持ちアイスとしてどんなフレーバーが選ばれているかも注目です。
↑モンブランが土台にされているパフェ
桃は剥いただけだったりカットしても元の球形に戻していたりしがち。
↑手前にしか桃がないパフェとは別に値段マシマシ全周版のパフェが存在するパフェ屋さんのパフェ
地層部分
パフェグラスの内側です。グラス越しにさまざまな色を伺えます。といってももちろんゲ〜ミングな色ではなく同系色で揃えられています。
- メインの果物を使ったソース:薄めの色
- サブの果物を使ったソース:メインと同系の濃い色
- ヨーグルトやナタデココ:白色
- ゼリー:透明
- サクサク食感やふわふわ食感の何か:小麦色
↑地層という概念から脱したパフェ
もちろん高価格帯のパフェのほうがレイヤー数が多く凝ったソースになります。
↑2つのゼリーレイヤーにそれぞれ異なる果物を入れるタイプのパフェ
サクサク食感やふわふわ食感の何か
食感のアクセントのために入れたともかさ増しのために混入させたとも言われるレイヤーです。代表例はコーンフレークです。サクサクではなくふわふわスポンジ生地が入ることもあります。
ミルクボーイM1ネタ『コーンフレーク』の台本・セリフの文字起こし(M1グランプリ決勝ネタ) | エンタメラッシュ
コーンフレークは地層部分の定番レイヤーですがチープさがあるためか採用は低価格帯が中心です。中〜高価格帯では別のものが採用されたりそもそも食感レイヤーがなかったりします。
↑ファミレスではないお店で見られるコーンフレーク
パフェの撮影
パフェ最大の悩みは横からの撮影が難しいことです。Instagramにアップロードするならなおさらです。他の人や散らかった私物が入らないように気をつけます。特定を避けるために自分のバッグやコートも避ける必要があります。私のInstagramや本記事にパフェ真横からの写真が全くないのはそのためです。
↑ケーキならあまり困らない
パフェは特徴的な飾り付けが多く現在地を特定しやすい題材なので来店直後に写真をアップロードすることは控えましょう。
カロリー
私はあすけんでレコーディングダイエットを行い9kg減量した実績があります(自慢)。レコーディングダイエットとは摂取したカロリーと体重を記録することで暴食を防ぐダイエットです。欠点は記録が面倒なことです。アレンジの利いたレシピやどんな食材を使ったかわからない献立はカロリーを計算できないため挫折の原因になります。
それってパフェのことじゃん。
幸い大手ファミレスチェーン店はパフェを含む全てのメニューのカロリーと塩分を公開しています。チェーン店によっては脂肪やタンパク質の値も公開しています。
↑エネルギー/たんぱく質/脂質/炭水化物/食物繊維/糖質/食塩相当量が判明しているパフェ
私はこのパフェをお昼ごはんとして食べたので昼食の欄に登録しました:
このパフェのカロリーは468kcalです。
500kcalは、1日通して座って生活することが多い女性の1食分の目安量です。 https://www.y-koseiren.jp/column/basis/2421
あすけんも私の1日のカロリー摂取量基準値に1519kcal〜1919kcalを指定しています。パフェ1個でほぼ1食分じゃ〜ん。飽和脂肪酸に至っては1日分の限度量をわずかに超えています。一方でタンパク質や鉄などは全く足りていません。したがって他の食事で辻褄を合わせる必要があります。
- パフェは間食ではなく食事として食べる(1日3食+パフェだと食べ過ぎなので)
- お米や麺は糖質不足分だけ食べる(みんなと同じ量を食べると食べ過ぎなので)
- パフェを食べた週は牛豚鶏を控えて魚を食べる(低脂質・低飽和脂肪酸・高タンパク)
- 普段の牛乳やヨーグルトは脂質の少ないものにする(どうせパフェでたらふく食べるので)
- たんぱく質・鉄・食物繊維はサプリで補充する(不足分を補う献立を考えるのが面倒くさいので)
- 栄養が偏らない程度に毎日の献立を固定する(あすけん入力の手間を省くため)
Q.パフェはおやつに入りますか?
A.パフェは朝ごはんまたは昼ごはんです。
支払い
パフェ屋さんによってはポイントカードがあります。季節ごとにパフェを食べるとすぐポイントが貯まります。活用しましょう。でも桃パフェを規定個数食べるともらえるプレゼントフルーツパフェは季節感がないという理由で食べたことがない。プレゼントフルーツパフェを食べるよりはもう1度桃パフェを食べる。
Q&Aコーナー
Q.どの店がいいの?
A.店名を言うと私の行動範囲がバレるので直接私に聞いてください。
Q.1人で行っていいの?
A.いいよ。エクストリーム出社開店凸ソロパフェしたら他にも平日開店凸ソロ客おったぞ。考えることは一緒だな。
Q.赤ちゃん連れで行っていいの?
A.(NGな店もあるかもしれんけど)いいよ。ベビーカーに赤ちゃん置いて黙々と食べる客は珍しくないぞ。
Q.男性が行っていいの?
A.いいよ*4。1人で黙々と食べる客も2人でわいわい食べる客もおったぞ。
Q.沖縄の果物はどう?
A.珍しい果物がたくさんあるのでたのしいよ。一通り食べてみたけど甘味少なめのタイプばかりなうえ追熟が必要で私には扱いきれなかった。無難にマンゴーを食べよう。
Q.沖縄のおすすめデザートは?
A.制限エリア外のお土産屋さんもしくはエリア内のANA FESTAでブルーシールのバニラアイスを買い、制限エリア内のスタバでエスプレッソを買い、ANAラウンジ内で泡盛をコップに汲んできて全部混ぜて食うとええよ。
↑変なことをしなくても酔えるケーキ
Q.なんで沖縄とANAの話してるの
A.明日担当の人がANA修行の記事を書くかもって言ってたから…
*1:「保健所がNGを出してないものは食わず嫌いせず食べよう」がモットー。たとえそれがコオロギラーメンでも美味しく食べる
*2:正確に言えば緑と金と赤それぞれに旬があるのだが輸入品が多く感覚を麻痺させる。赤いキウイのパフェっていうのもあるのよ
*3:私は乳脂肪が取りたい。だがウィンナーコーヒーは高確率で植物性ホイップを乗せてくるので認められない。って言いながらこの店こそは乳脂肪が摂取できるかもしれないと思って今日もウィンナーコーヒーを注文する
*4:男性のみでのフルーツバイキングがダメだった時代もあるのだ…
Swiftの小ネタ
普段Swiftを書いてる皆様用にいくつか振りたい小ネタっていうか話題があるので読んでいってください。
(本当はもっと規模のでっかい話をしたかったんですが間に合いませんでした…iOSDCとか来年のカレンダーには間に合わせます!)
その1:型理論カレンダー用に書いたやつ
Swift書かない人も読むことを想定して書いたやつなので↑には結論を書いてないのですが、この記事の結論は
「Swiftで使われる 型消去
の意味は世間一般とは違うっぽいのであんまでかい声で連呼するとこっちが消されそう…」
です。
その2:tupleについて
- tupleの添字は0始まり派と1始まり派がいる。1始まり派でいうとHaskell(1990年生・
fst
,snd
)やKotlin(2011年生・first
〜)とか。0始まり派は我らがSwift(2014年生)の他にRust(2010年生)など。バージョン上がって0始まり派に寝返ったScalaとかいうのもいるので我々の時代が来ている……かは定かではない。 - 配列と違いtupleは違う型のオブジェクトを持つことができるが、配列のように
tuple[i]
などと動的に要素を指定することはできない。そりゃまあsubscript
の戻り値の型が定まりませんし。- どうにかして定まるような仕組みがあれば書けるとも言える。Scala 3にはパターンマッチにより最終的な型を決定する型が存在する("match type")。この仕組みがSwiftに欲しいかと言われると?うーん……いらないかな…
その3:[SE-0330] Conditionals in Collections
この機能地味に欲しいやつ。まあ本日時点でReturned for revisionなんですが…
私はこう書きたいって過去に3回くらい考えたことある。ありますよね?地味〜にめんどくさいじゃないですか、こう書けないせいで・・
let array = [ "apple", "banana", // ここで一旦配列の宣言を切り上げて `append("peach")` とかするのだるい #if YOU_LIKE_PEACH "peach", #endif "pear" ]
問題点はいくつかあるようで、
let ambiguous = [ #if HOGE "peach", #else "peach": 100 #endif ]
というふうに違う型が来たらどうするのか?とか、これを実現するには実装が複雑になるんじゃという懸念があるらしい。
ちなみに現在、#if
を扱っているのはlibSyntaxだそうです。導入前はAST側に #if
を任せていたとか。
(Source) -> [Parser] -+-> (AST) -> [Sema] -> ... | and +-> (libSyntax) -> [SwiftSyntax, ...]
(Integrating libSyntax into the compiler pipelineの解説 | by Yusuke Kita | Mediumから引用)
Syntax側が担うのだからなんとかなるんじゃ
とか、
#if 配列 #elseif 辞書 #endif
の場合は両者をまとめて扱える専用のノードが必要になるぞ
とか、
そもそも #if
はLexerで扱うべき
とか、
C#でこの手のことが書けるのは条件に合うほうだけを取り込んでいるから(しかし完全に切り捨てているわけでもない)
とか、
などなど。
SE-0330: Conditionals in Collections - #22 by tkremenek - Proposal Reviews - Swift Forums
ちなみにこの話は2018年ごろからあって最近復活したものっぽいです。議論の結果やいかに。
いろんな型消去
初心者です。初心者なので型システム入門を何周してもわかりません。無限に周回と挫折を繰り返しています。誰か型システム入門の攻略チャートを組んでください……
なんで型消去を選んだ
さて、型システム入門のなかで 型消去
という語が登場します。皆さんは型消去と聞いて何を思い浮かべるでしょうか。私は普段Swiftを書くのでSwiftの型消去テクニックを真っ先に思い出します。これは型システム入門で紹介される型消去とは異なります多分。どうやら「型消去」という3文字自体はあくまで型を消去するという意味しかなく、どんな形であれ型を消す作業をしていればそれは型消去となってしまうようです。さっぱりわからん。
Wikipediaの型消去のページにはC++の例とJavaの例が載っています。
型消去 - Wikipedia
Wikipediaで説明されているJavaの型消去は、恐らく型システム入門の言う 型消去意味論
の一環として行われていることだとは思うのですが、意味論として型消去について語っている資料が英語論文くらいしかないので読んでないよくわからん。
本記事では各言語における型消去の操作について整理します。そうすれば型消去意味論の意味を理解できるかもしれないから。
Swiftの型消去
Swiftにはprotocolというものがあり、何らかの機能に必要となるプロパティやメソッドを定義する。標準ライブラリでは同値比較用のprotocolやシーケンス用のprotocolなどを提供している。
protocolにはassociated typeという仕組みがあり、protocolの定義段階では仮の型名で保留にしておき、クラスがprotocolを準拠する時に具体的な型を指定できる。
protocol Container { // 具体的に何の型が取れるのかはここでは定めない associatedtype Element func take() -> Element }
associated typeの問題点は、associated typeを含むprotocol型の変数を宣言できないことにある。
class MyBox<T> { private let item: T init(_ item: T) { self.item = item } } extension MyBox: Container { typealias Element = T func take() -> T { return item } } // `MyBox` はただのクラスなのでOK let a: MyBox<Int> = MyBox<Int>(0) // protocol 'Container' can only be used as a generic constraint // because it has Self or associated type requirements // というエラーになる let b: Container = MyBox<Int>(0)
どうしても宣言したい時は型消去をする。Any(protocol名)
と名付けて使うのが慣例。標準ライブラリでも AnySequence
などが提供されている。
// Container型の変数を定義することはできないが、総称型に制約をつけることはできる。 struct AnyContainer<T> where T: Container { private let _container: T init(_ container: T) { _container = container } } let c: AnyContainer<MyBox<Int>> = AnyContainer(MyBox<Int>(0))
以上がSwiftの型消去テクニック。Swiftを書く人間がやるテクニックであって、コンパイラがどうとか実行時がどうとかという話ではない。
C++の型消去
上記のSwiftの型消去は多分C++の型消去技法に由来するのだと思う(C++を意識してないってこたぁないっしょ)。
Wikipediaでも説明があるが、C++ではテンプレートを駆使してAny型を作る。型安全を無視すればテンプレート以外の方法で型消去することも可能、らしい。
型の力を抜いて学ぶC++ - Google スライド
「C++ 型消去」でGoogle検索をして出てくるのはこのテクニックの話。次に説明するJavaだと総称型関連の話がわんさか出てくるのだが、C++の総称型は型消去と異なる手法(こちらは全展開とか異種変換とか呼ばれるっぽい)を採用しているためかテクニックの話ばかり出てくる、ように見える。
Javaの型消去
本記事で取り上げる型消去の中では2番目に型消去意味論に近そう?に見えるやつ(個人の感想です)。
Javaに総称型が導入されたのは1.5のとき。Java仮想マシンの互換性を重視したので、プログラマが型変数を書いてもクラスファイルには型変数の情報を残さない、つまり型消去することにした。実際、コンパイル&デコンパイルをすると型変数が復元されない。
元のソースコードが以下のようだとすると、
class GenericClass<T>{ private T value; public GenericClass(T value){ this.value = value; } public T getValue(){ return value; } }
javap
はこんな感じ。これは1.5で試した場合であって、今は型変数に関する情報をクラスファイルに書き残しており復元可能になっている。そうでないとデバッガが困るので。
class GenericClass extends java.lang.Object{ public GenericClass(java.lang.Object); public java.lang.Object getValue(); }
Object
型に置き換えるこのやり方は同種変換と呼ばれる。どんなものが型変数に代入されようが、Object
型なので何とかなる。ちなみにC++の異種変換は、ソースコード中で代入される型(int
とかstring
とか)へ置き換えたものを個別に用意するというもの。用意する分だけサイズが増えるが実行効率はこっちが有利らしい。
なので、Javaの場合は「同種変換という手法をとる過程で型消去して Object
に置き換えた」となるのではなかろうか。
TypeScriptの型消去
- Javaと同様に、総称型は型消去によって実現しているらしい。
- コンパイルしてJavaScriptコードを生成するときに型アノテーションを消すことも型消去と呼ぶらしい。
Google検索でざっと眺めたところでは、普通は1の用法で、稀に2の用法で使っていることがあるように見える。まあわざわざ2の話をすることはないでしょうね。だが高級言語→低級言語へコンパイルする過程で型をひたすら消去した、と見立てれば型消去意味論に最も近い気がする(個人の感想です)。
FAQ · microsoft/TypeScript Wiki · GitHub
まとめ
この辺読むと楽しいよ
理解の足りてない本記事よりこれらを当たるべき
- https://www.oracle.com/webfolder/technetwork/jp/javamagazine/Java-JA16-Generics.pdf
- https://ipsj.ixsq.nii.ac.jp/ej/?action=repository_uri&item_id=65070&file_id=1&file_no=1
- Chapter 4. The class File Format
- Type Erasure (The Java™ Tutorials > Learning the Java Language > Generics (Updated))
- erasure
- ジェネリック - C# によるプログラミング入門 | ++C++; // 未確認飛行 C
- https://www.fos.kuis.kyoto-u.ac.jp/~igarashi/papers/slides/JSSST06-tutorial.pdf
来月の技術書典にはもうちょっとしっかりまとめるつもり、論文も1本くらいは読むつもり
#iOSDC Japan 2021に参加しました
ちょっと立て込んでいて細かく書く時間がなくて申し訳ないです。取り急ぎ。
全体通して
- プロの声優さんにタイトルと名前を読み上げてくれるなんて聞いてないんですけど!どうして今年落選しちゃったの私!来年は見てろよ!
- 思わずパソコンの前で拍手してた(ニコ生コメントに
88888
と入力するのではなく)。臨場感がありすぎたのかもしれない。そしてそろそろ会場参加したいと思い始めているのかもしれない。 - 最近ずっと勉強会に参加していなかったので、発表意欲が湧いた。一応少しずつ勉強はしているんだけど纏まったものがない(落選最大の理由)。
- ここ最近はずっと型システム入門の本を読んでいる。個人的な興味があるからという理由以外に、稲見さんの発表で毎年†完全理解†してしまうのを食い止めたいという理由があった。正直言ってしまうと今年も†完全理解†したが最後まで集中力を保つことはできたし、私にとって初見の分野だったばんじゅんさんの発表を楽しめたのは成果と言えると思う。
- 来年は運営のお手伝いに復帰したいっス・・
個々の感想とか
わかる〜って言いながら見たやつ
- 大規模リファクタリングの極意 by Yosuke Imairi | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- 僕たちが『Appのプライバシーに関する質問への回答』そして『ATT』に対応するまでの物語 by FromAtom | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- 大規模なアプリのマルチモジュール構成の実践 by giginet | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
わかる〜。
あるある〜ってコメント複数あってなんか安心した、安心してないでちゃんとやらなきゃならんのだろうけど #iosdc #a
— Shigure Shimotori(技術書典11 ネットの海 cd75) (@S_Shimotori_pub) September 17, 2021
自社のプロジェクトで導入していないtipsには勉強になった。みんな便利ツールの作り込みすごいなあ。。
導入済みのtipsも面白かった。「やっぱあれ効果あるんだな」とか「導入した人ありがとう」とか思ってた。
デザイン系の話
- iOS・Androidで使えるデザインシステムをどう実装するか by ああうえ | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- 歴史のある大規模アプリに Design System を導入して開発をスケールさせる by Shunsuke Sasaki | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
デザインシステムの知見は色々聞きたかったので色々聞いてみた。どうしたもんかなあ。悩みますね。でも絶対やるべきことだと思ってるのでこうして各社取り組みが行われているのには嬉しさというか時代が来たなって思います
自分と縁遠い分野なのであえて聞いたやつ
- 初めてのハードウェア対応 by Takeshi Yokokoji | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- Network ExtensionでiOSデバイス上で動くパケットキャプチャを作る by 岸川克己 | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- 未知のファイル形式をCodableで読み書きするのに役立つテクニック 『Apple Watchの文字盤ファイル』 by ばんじゅん🍓 | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- MDMを使って業務用アプリの初期設定を自動化する技術 by oishi | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
- App Clips はどこから来たのか&何者か&どこへ行くのか by log5 | トーク | iOSDC Japan 2021 #iosdc - fortee.jp
むしろこういうやつの方が醍醐味だよね どうせ自分が普段やってる分野の話は後で見返すし。。
むずかしーって言いながら聞いたやつ
問題の稲見さんの発表。ほとんどわからんかったけど「そこは後でググればわかるだろうな」みたいな余裕を持って聞くことができたので、ここ最近の勉強は無駄ではなかったと思う。引き続き頑張っていきたい。
問題のばんじゅんさんの発表はこっち。こういうのもちゃんと理論があるんだなあ。
にゃーん
にゃーん
2020年もiOSDC Japanで色の発表をしました(「大解剖!UIColorファミリー」) #iosdc
これまでに発表した色のあれこれ
- 色の難しい話に負けない体づくり60分 by しもとり | トーク | iOSDC Japan 2019 #iosdc - fortee.jp
- 色の話についていくための基礎知識を調べてしゃべった
- 【物理本+PDF】Dark Mode対応のためのUIKit対策本 - つまみぐい本舗 - BOOTH
- Dark Modeに関する(私にしては珍しく役に立つ)内容を売った
- UIColor Cluster - Speaker Deck
- UIColorのサブクラス作成がなぜ無謀かをしゃべった
- 【New】大解剖!UIColorファミリー by しもとり | トーク | iOSDC Japan 2020 - fortee.jp
- UIColorのサブクラス18個がそれぞれどのような役割分担をしているかをしゃべった
流石にDark Modeで得たネタで終わりかと思ったのだが、
???「UIColorのサブクラス作れたりしないかなー」
の一言からUIColorのサブクラス発表が生まれた。
世の中的には「UIColorのサブクラス作成はほぼ不可能」は既知の情報だった。なぜサブクラスの作成が不可能なのかは誰も説明していなかったのでとても画期的な発表だった(役には立たない)。
今年はスタッフをしたのか
してない(ネットワークの仕事がなかったので)(当日の都合がつかなかったので)
体力的には非常に楽だったが物足りない気持ちもあり。
「大解剖!UIColorファミリー」
UIColor自体は有用でも内部実装の情報は何も役に立たないので「『役立つ情報を話します』な優良誤認をしていないか」がすごく不安だった。
SwiftUI.Color
情報がないのでこの分のネタをどうしようか微妙なところ。
今のところ不明な点:
- sRGBな
SwiftUI.Color
をCGColor
に変えるとなぜか数値がちょっとずれる- display P3はズレない。
- Asset Catalogの色をStoryboard上で使うとなぜか数値がちょっとずれる(らしい)
総合的に
オンラインなのにいつもの企業さんがスポンサーしてくださってるし、豪華ノベルティも届いたし、収録から当日まで初年度と思えないオペレーションでとてもビビった。いつも通り楽しいiOSDCだった!
(懇親会とかでご挨拶や思いがけない出会いができなかったのはざんねんだけど・・しょうがないね)
Swift evolution proposals No.268 - No.273を読んだだけ
2019年の感想:
上半期は UICollectionView
を軽くやって下半期はDark ModeをやってたのでSwiftのことはすっかり忘れました。マジで何もわからん。Swift5さえ怪しい気がする。
なのでここ1ヶ月のproposalを軽く読んでアドベントカレンダーをごまかす。
No.268〜No.273です
Refine didSet
Semantics
swift-evolution/0268-didset-semantics.md at master · apple/swift-evolution · GitHub
今のステータス:Active Review (5-9 December 2019)
今のSwiftは、 didSet
が動くと oldValue
の取得をするために毎回getしちゃうらしい。たとえ oldValue
を使わなくてもallocateしたりしちゃうらしい。
このproposalは 「oldValue
を使わない時はその辺の処理をスキップしたい!」というもの。
Increase availability of implicit self
in @escaping
closures when reference cycles are unlikely to occur
swift-evolution/0269-implicit-self-explicit-capture.md at master · apple/swift-evolution · GitHub
今のステータス:Accepted
self
の書き方が変わるっぽい。
class Test { var x = 0 func execute(_ work: @escaping () -> Void) { work() } func method() { execute { [self] in x += 1 // ← [self]って明示したからself.xって書かなくていいことにする } } }
struct Test { var x = 0 func execute(_ work: @escaping () -> Void) { work() } func method() { execute { x += 1 // ←この場合、selfはstruct(値型)なんだから[self]って明示する必要もないでしょ } } }
今は不要なところでも self.x
って書いてるし、Appleは不要なselfは書かない方針のようなので必要なところだけ明示するようにする。
Add Collection Operations on Noncontiguous Elements
swift-evolution/0270-rangeset-and-collection-operations.md at master · apple/swift-evolution · GitHub
今のステータス:Active review (December 13th...19th, 2019)
IndexSet
以外に RangeSet
を増やしたいというproposal。
numbers = Array(1...15) let notTheMiddle = RangeSet([0..<5, 10..<15]) print(Array(numbers[notTheMiddle])) // Prints [1, 2, 3, 4, 5, 11, 12, 13, 14, 15]
Package Manager Resources
swift-evolution/0271-package-manager-resources.md at master · apple/swift-evolution · GitHub
今のステータス:Accepted with revisions
一言でいえばタイトル通り。SPMなので、もちろんプラットフォームに依存しない形で。
目標をざっくり訳すと
- 簡単にリソースファイルを追加できるようにする
- リソースではないファイル(ドキュメントなど)を間違えて混入しないようにする
- プラットフォーム依存のもの(xibとか)も対応する
- ローカライゼーションも。
- package authorが好きなところにリソースファイルをおけるようにする
とのこと。
Package Manager Binary Dependencies
swift-evolution/0272-swiftpm-binary-dependencies.md at master · apple/swift-evolution · GitHub
今のステータス:Accepted with revisions
これも一言でいえばタイトル通り。
CocoaPodsみたいにクローズドソース(Firebaseとかそういうの)に対応できるようにしたいというのがモチベ。
ただ、以下のことをやるつもりはないらしい(バイナリでできたものについて詳しくないからよくわかんない。。)
- Ease of production of binary packages
- Simplicity of binary artifact distribution mechanism
- Widespread use of binary packages
あと、proposalには「最初はAppleのプラットフォーム対応だけ」と書いてあるので今後に期待する要素がそれなりにありそう。
Package Manager Conditional Target Dependencies
swift-evolution/0273-swiftpm-conditional-target-dependencies.md at master · apple/swift-evolution · GitHub
今のステータス:Accepted
targetのdependencyに condition:
が増えるらしい。
dependencies: [ .product(name: "Bluetooth", condition: .when(platforms: [.macOS])), .product(name: "BluetoothLinux", condition: .when(platforms: [.linux])), .target(name: "DebugHelpers", condition: .when(configuration: .debug)), ]
まとめ
SPMが集中してた
TaPLの2章と3章に出てくる単語を調べた(だけ)
Q なんでこんなまとめブログみたいなことしてるの
A すうがくむずかしすぎて2章と3章を読んだことがなかったから
2章
2.1
- "加算"
http://www.math.is.tohoku.ac.jp/~obata/student/subject/file/2018-7_kasan.pdf
集合から集合Bへの全単射が存在するとき, とBは濃度が等しいといい
(略)
自然数の集合と濃度が等しい集合を可算集合という. 言い換えれば, 全単射が存在するような集合が可算集合である.
- "二項関係"
https://www.hongo.wide.ad.jp/~jo2lxq/dm/lecture/02.pdf
- を整数の集合とする
- から、というの要素への関係をとする
- この場合であり、は上の関係である、という。
- "保存される"
これよくわかんなかったんだけど。。
2.2
用語
日本語 | 英語 | 式 |
---|---|---|
対称的 | symmetric | ならば |
反対称的 | antisymmetric | かつならば |
反射的 | reflexive | |
推移的 | transitive | かつならば |
↑を組み合わせたやつ
前順序 | 半順序 | |
---|---|---|
対称的 | ||
反対称的 | ○ | |
反射的 | ○ | ○ |
推移的 | ○ | ○ |
3章
3.4
- 操作的意味論
http://www.kurims.kyoto-u.ac.jp/~kenkyubu/kokai-koza/H28-hasegawa.pdf
実際にプログラミング言語の処理系が行っているような具体的な計算の規則によってプログラムの意味を与える流儀は、操作的意味論(operational semantics)と呼ばれます。操作的意味論が与えられると、コンピュータ上で動作するプログラミング言語の処理系を与えることが(少なくとも原理的には)できるので、現在では、操作的意味論は、プログラミング言語の定義を与える有力な手法とみなされています。
http://research.nii.ac.jp/~ichiro/lecture/model2003/operational%20semantics.pdf
抽象機械の例
- 表示的意味論
意味領域は,「定義されていること(definedness)」の度合いを表す順序が与えられた集合である.
- 公理的意味論
https://www.fos.kuis.kyoto-u.ac.jp/~igarashi/class/sf03w/resume5.pdf
操作的/表示的意味論を使ってプログラムの性質の議論をするためには,数学的に定義された実行関係・意味関数などを対象として,メタ言語 (日本語+集合の基礎知識) によって非形式的に議論を行なわなければならなかった.ここでは,プログラムの性質を直接の対象として扱う形式的体系 (規則による導出体系) を考える.そして,形式的体系により証明できる性質を以て,プログラムの意味を定義した,と考える,このようなプログラムへの意味付けの方法を公理的意味論と呼ぶ.
感想
4章から先の単語はプログラミング言語の話題で出てくるから初見感はない(正直まだよくわかってない)