Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
>>212
なるほどぉ
Cocoa BindingとかCore Dataを使えって事なのね。
ところで、ObjC Wizardの方々は、Core Data使うんでしょうかねぇ？ Lispのtypoかよw
そういうワードがあるのかと真面目に受け取ってた
あ、自分はvim派なんでelisp含め使ったことないわ
elisp wizardは変態だと尊敬してる >>216
すまんｗ
まあメッセージ式のネスト地獄もLisp様から見ればかわいいもんですｗ >>212
メソッド呼び出しに、ドット構文が使えればObjCも描きやすくなるよねぇ。
Objective-C 3.0に期待だね。
id a = [[NSObject alloc] init];
->id a = NSObject.alloc().init(); // こんな感じ！ 既にクラスプロパティとオブジェクトプロパティで実現できてるね！ObjCはすごいね！
クラスプロパティの存在を知らないんだろうなぁ、ObjCについてもうちょっと勉強してこい >>219
いや、引数あったら出来ないだろ
ところでドット構文マンセーな人ってiOSやる前は何の言語がメインの人？ >>218
obj-cの魅力ってあくまでcの拡張でありobj-cの世界は[]の中だけってスタンスであってほしいから
ドット構文?はあんまり増やしてほしくない
個人的にはElixrのパイプ演算子(|>)をobj-cに採用して欲しい。
(元ネタはElixirじゃないかもしれないけど。)
[NSObject alloc] |> [@ init]
みたいな感じで使う。Elixirの場合だと返却値を次のメソッドの第一引数に渡すって意味だけどobj-cでは@を置き換えるみたいな感じで >>223
自己レス
プロパティへのアクセスだけだた 最近ObjC ageが激しいがnukeとかvaporとか読んで腰が引けちゃった連中が多いのかな？
ああこれc++の再発明かなと思うくらい難解なコードになってきたからな
POPがあるからまだ扱いやすいが SwiftはC++っぽくて地雷にしか見えない。
闇の軍団が好きそうな言語。 Objective-Cがまぁ長年主に言語仕様を弄るんじゃなくて
外部のクラスライブラリ更新で"外"に括り出してきたタイプの問題を
2010年代になっていまさら言語仕様直接変更の繰り返しで泥沼って
そりゃ車輪の再発明ってレベルじゃねーぞっつか…
あきらかに(筋の悪い)車輪を知らないところからの使者が
「おまえら未開の蛮族にまったく新しい言語を作ってやるぜ」って
泥の中でのたうってるのを眺めてるこの感じ。 ObjCが長年プロパティ、GC/ARC, ブロック文, nillable, ジェネリクスと言語仕様追加を繰り返して泥沼を作ってる中で
Swiftという新しい泥沼を作ってくれたから皆で泥遊びをしている中、泥遊びって子供かよ・・・と高二病な感じ
一緒に泥遊びしようぜ、やってみたら案外楽しいよ >>229
Objective-Cでもジェネリクス可能なのか？
どのレベルまでできる？
1. 型汎用な関数
2. 型汎用なクラス
3. 型汎用なプロトコル
4. 型汎用なプロトコル・エクステンション LattnerがGoogle Brainに就職
やっぱり人工知能やりたいんだな Google BrainといったらTensorFlow開発してるところだから、これはいよいよTensorFlowがオフィシャルにSwift対応するかもしれん 良かったな、お前らの教祖様の就職先見つかって。
Apple「Swift」の生みの親がテスラの自動運転開発をやめてGoogleの人工知能開発チーム入り
http://gigazine.net/news/20170815-google-hire-apple-engineer/ あのおっちゃん短期で技術リーダー採用してくれる所を探してたよな
来年には再転職しそう どうせまたリスケするんでしょ、、、とか思ってるけど
それとは別にラットナー のgist記事がRustのオーナーシップモデルをディスっててワロタ
Rustライクなメモリ管理をSwift4で投入するって言って結局Swift5に持ち越したのは忘れんぞ
ファーストクラスの非同期とファーストクラスのオーナーシップモデルを並走させるのはキッツイだろうがどうするんだろうね
理論的には出来なかないだろうが時間も技術力も足りずどっちかSwift6に持ち越しすることになるんじゃねーのか オーナーシップは初めから「4には入れられないけど」「将来的に〜」ってエクスキューズしてた
オーナーシップを4のゴールに含めるなんて話は一度も出てないはずだが 思うんだけどrustのオーナーシップモデルって後付で入れられるものなの？
rustを見る限り無理そうだし、
スマホの性能もこれから上がっていく一方なのに学習コストが上がる
メモリオーナシップモデルって導入する意味あるのん？ SwiftからObjective-CのArreyを取得しようとすると、x0756846 のような、メモリーアドレス？しかとれないのですが、何か特別な変換とか必要ですか？ >>245
CManeger.mmの関係しそうなところ
@property (nonatomic, readwrite) NSArray *hoge;
データ取得関数の最後に
self.hoge = hoge.array;
dispatch_async(dispatch_get_main_queue(), ^{
[self.delegate CManager:self didCompleteWithCandidates:self.hoge];
});
とあり、ブレークポイントはって確認すると、取得したデータがhogeにある。
HOGE-Bridging-Header.h
#import "CManager.h"
Hoge.swift
let objcCMng = CManager()
let ret = objvCMng.hoge
print(ret)
出力データは
Optinal([<CCandidate: 0x170226b80> , <CCandidate: 0x170226ce0>)]
という感じになります。
ただし、デバックエリアで確認するとself>objcCMng>_hoge>_orderedSet>_array>[x]>_hogeに取得データがあることは確認できます。
型変換か何か必要なのでしょうか？ >>246
let ret = objvCMng.hogeを
let ret:Array! = objvCMng.hoge
にしてみたら？ >>247
ありがとうございます。
試しましたが、出力結果はほとんど同じでした。
[<CCandidate: 0x170226b80> , <CCandidate: 0x170226ce0>] 何がみたいのかよくわからんのだが、、
dumpだとどうなる？ 多分descriptionをオーバーライドしてなくてprintで<CCandidate: 0x170226b80>みたいに出力されるのと、型変換してなくて[AnyObject]?型のままになってるのの複合で混乱してるんだろう
前者はCCandidateのdescriptionを自分の望みどおりの出力をするようにオーバーライドすればいい
後者はSwift側で as? [CCandidate] するか、Obj-C側で @property (nonnull, nonatomic, copy) NSArray<__kindof CCandidate *> *hoge; とかすればいい >>249
some: 2 elements
- <CCandidate: 0x170226b80> #0
super: NSObject
- <CCandidate: 0x170226ce0> #1
super: NSObject
となります。
まだはまってます… 何したいのかいまいちわからんな
>>250のいう通りにすればいいだけだろとしか思えない >>250
ありがとうございます。
書き込み頂いた情報を元に、objc-cの言語仕様を調べながら触ったんですが解決せず、AnyObjectに問題を絞りこんで見ました。
結果、出力部分のコードを書き替え、データの取得が出来ました。
for i in 0..<objvCMng.candidates.count{
let ret = objvCMng.candidates[i] as AnyObject
print(ret.candidate)
}
皆様、ありがとうございました。 >>253
candidatesとhoge置き換えミスってます… let blue = #colorLiteral(red: 0, green: 0.4577052593, blue: 1, alpha: 1)
let white = #colorLiteral(red: 0.7803494334, green: 0.7761332393, blue: 0.7967314124, alpha: 1)
let orange = #colorLiteral(red: 1, green: 0.5803921569, blue: 0, alpha: 1)
let red = #colorLiteral(red: 1, green: 0.2352941176, blue: 0.1882352941, alpha: 1) 長ったらしい型名ばっかのコードは思考が阻害される
型チェックはしてるんだからべつにデメリットもない ビルドに時間がかかるようになるだろ。型推論なんて使わないほうがいい Swiftの型推論は単純だからObjCの型チェックとビルド時間は変わらないけどな
Rustくらいに賢い型推論して欲しいよ その解説だと型推論じゃなく数値型がstructであることが本質の問題だよね？
let a: Double = -(1 + 2) + -(3 + 4) + -(5)
と
double a = -(1 + 2) + -(3 + 4) + -(5);
で違いが出るならそれはコンパイラ組み込み型を常用せずstruct型扱うからでしょ
プリミティブ型削って構造体型を多用するSwiftはイマドキだよな
NSIntegerみたいに32bitなのか64bitなのか分からんことになるよりは良きも悪きもあるわな 推論に任せないで型を記述した方がコードの見通しが良い気がする 型を決定するために5cm以上目線の移動がある場合は型を記述したほうがいい俺ルール ジェネリクスみたいに長い同じ型を何度も書く羽目になるやつは
混ぜた方が見やすい Swift 3移行まだしてない人いる？
うちの会社は再テスト面倒で未だに2.4使ってるんだが。
Swift 2.4 -> Swift 4で済ませようかなって思ってる。 そもそもSwiftに移行してない(する必要がない) 自分とこは業務でSwift使うの金かかりすぎると2.2の後は3にせずObjCに移行した
メンテ工数かかるし素直に実装し直しを検討した方が良いんではないかね
1.1から2.2まで商用コードをメンテした過去の自分らを褒めたい >>266
Swift使ったことないなら参考にならないから黙ってるといいよ:D 移行してない＝使った事が無いというのは発想が貧弱ではなかろうか func sum(i:Int, i2;Int, i3:Int) -> Int{
return i + i2 + i3
-> Intが後ろの方にあるの､変な感じがするんですよ
func Int sum(i:Int, i2;Int, i3:Int)
こうしなかったのは､どうしてですか？ c++でも型推論が簡潔にかけるという理由で戻り値の後置構文が追加された。
その経緯をみて決めたんじゃないかな。 >>272
アレってtemplateの引数依存の戻り値を返したいからじゃなかったの？
コンパイラに型導出させてｳﾏｰ、っていう
template<typename T, typename U>
auto operator+(const T& t, const U& u) -> decltype(t +u) { return t + u; } >>270
C言語っぽくないことにとことんこだわったから >>270
セミコロンじゃなくてコロンだよ
引数の型の指定は xcodeが使いにくいんですがjetbrains製のideでiosアプリ開発ってできるんでしょうか 何が使いにくいのか？
慣れの問題もあるの思うが
とりあえずAppCode触ってみたら？ realmはcasecade使えるようになりましたか？ この言語仕様改定多すぎだろ。
C++が三年周期でやってることをこいつら一年単位でやってねえか？ xcode9で新規に画像がimageViewに表示されないんだが
xcode8で作成したものは9でも表示される。
iMacもMacBook Proも同じ現象なんだが俺だけだろうか どうせ画像をターゲットに入れてないとかしょうもないオチだろ 284ですが解決したので一応報告。
Xcode 9のバグでした。
画像をドラッグアンドドロップではシュミレーターで画像ファイルが
参照出来ない。
メニューから画像追加で表示されるようになりました。 >>282
Javaは今後6ヶ月ごとにバージョンアップらしいで また来年おなじことの繰り返しやで
再来年も、その翌年もずっとやで 今回Swift対応なんて無いようなもんだろ
フレームワークやX対応のほうが大変 Swift4対応のXcodeにアップグレード完了した。。 >>292
バージョンによっては速いぞ。
初期は遅かったけど。 先月Swift 3対応したばかりなのにまたSwift 4対応しなきゃならない。
Swift 2から一気にSwift 4対応したほうが良かったかな、失敗した。 >>294
昨日の会議でSwift3.1対応が残課題で有ったんだけれど、もう4になったとは言わなかった。 Objective-Cで書いときゃメンテフリーだったのに iOS 11で脱落したアプリはSDKの変更についていけなかったか費用対効果で更新をやめただけ。言語のメンテナンス性とは別の話 実質同義なんだよなぁ
せめて費用対効果がObjC AppメンテよりSwift Appメンテの方が効率悪いと言えば良いのに
ObjCならメンテフリーとかアホなこと言うから突っ込まれる
さておき、このスレでもSwift2の頃にSwift採用したPMは死ねとPG視点で大合唱だったのに
まだSwiftを商用採用する企業いるのが悲しいのう、その頃に作ったものをメンテしてるのかもしらんが辛いな >実質
>App
言語スレで言語の話をしてるのに勝手に条件を付加するなよ iOS11でObjC Appがメンテできなくてアプリが減ったと言う話をしてたのに何を言ってるんだ・・・
「Objective-Cで書いときゃメンテフリー」とは一体何を指しているのか
あと、ObjCの話をしたいならObjCスレかせめてSwiftアンチスレに行けよ
別にApple信者じゃないからSwiftマンセーしてるわけじゃないのにObjCを笑われたからってSwiftスレで絡むなw ObjC Appがメンテできなくて でなくて、メンテされてないアプリが消えただけじゃないの
ObjCだかrメンテできなくなったって、なに？ ああ、Swiftだったら簡単(？)なのにObjCだからメンテされなくなったとでも言ってるのか？？まさかだが、そう思ってるならそれはナイな
お前みたいに変なこと言い出すヤツいるから聞きたくもないObjCの話が長くなるだろうにw 開発環境の話
・Xcodeアプデ→言語VerUp→Swiftコード要メンテ
・ObjCならメンテ不要だった
ユーザー環境/ストアの話
・iOSのVerUpでObjCもメンテが必要になる
・Swiftの方が効率悪いと言えば良い
↑
前提がズレてる
・ObjCだからメンテできなくなったって
・Swiftだったら簡単とでも
↑
対偶的な意味でズレてる swudt2あたりで知識が泊まってるんだけど今のswiftはどれくらい良くなった？
俺の中でoptional型の概念とか関数型の世界を見せてくれたswiftには感謝してる。
今はtypeScriptメインだけどね swiftは良いものだがRXとかReduxはライブラリ必要で恐ろしく書きかたが変わり危険なので個人的に好きじゃない
iOSはそもそもMVCなのでMVVMいけ swiftのビルドの重さで新型Macが売れてます
ReduxとかRXのおかげでiPhoneのバッテリがガンガン減ります
結局ObCのほうが良かった、とかwww 型推論とかでビルド遅くなるなら要らないけどな
Optional型も適切にnilチェックしてれば要らない
Macとか本売りたいだけなのかな >ReduxとかRX
RXは書式が気持ち悪くて論外だが、Redux使うくらいならビジネスアプリはシンプルでライブラリレスなMVVMでしょ絶対に開発早いし
Appleはrxcocoa禁止したほうがいい xcode XくらいでAppleがMVVM的なフレームワーク出してくるかな
RXは早く死に絶えて ライブラリレスなんていう移植無視な開発なんてやらぬ ■ このスレッドは過去ログ倉庫に格納されています
