Swift part11 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
まあObjective-CはJobsが原点回帰(NeXT系譜)した感じだな >>122
CarbonがいつC++だったのよ。Cだろ
>>123のいう根本から変わる過渡期にどうするかで出てきたCarbonなんて最初からいつか無くなる運命だし、Carbonよりも先にObjective-Cあったので切り替えでもなんでもないだろ
いつまでもOSネイティブなObjective-Cにしなかったアホが悪いでしかないのに、ゴリ押しとか基礎も結論も妄想がひどすぎ Swiftやってる連中はにわかが多いからしゃーない 旧MacOSはそういやPascal推しだったの思い出した Pascal, C/C++を拒否してObjCに強制誘導してるじゃないか、、、
同じようにSwiftも頼むよー C/C++が拒否されてるなんて全く感じたこと無いけど
C/C++でバリバリ書かれてるコードにちょっとCocoa APIをObj-Cで呼び出せばプログラムが完成するって感じだと思うけど
ObjCに強制誘導って思うのは、単にMac OS XのAPIを学びたくないからじゃないの？ 強制誘導ってアホか？
Objective-CのベースだってMac OS X/OS X/macOSのバージョンアップによってC++に書き換えられてるし、CoreはCのままだし、OS X/CocoaはほぼNEXT STEPのまんまと言っていいくらい元々Objective-Cだし、IO KitはC++で書けだし >>128
推しというか、Macの開発(ほんとの生み出す開発)はPascal/Assembleで作っていたんだなあというのは、どこぞの博物館で公開されたQuickDraw/MacPaintのソースでわかる
推すも何もそうだったらそうなるだろ、ドキュメントとか。だが、サード開発ではCが大多数(＆CでPascal形式API呼ぶのにほぼツーカーで何も問題ない)で、Appleもそれにならうでしかないな Google Search
Google Trends
Twitter
GitHub
Reddit
などなどを"X programming"っていうテンプレートで検索し、hits countsをrankingしたって事らしい。 >>130
ObjCをちょっと書かないとmacOS, iOSアプリが作れないように
Swiftをちょっと書かないとモノが作れないくらいのゴリ押しして欲しいなぁと
Appleは作りっぱなしで押さないし、信者はジョブズの聖遺物(ObjC)を崇めるし
Appleがゴリ押しした製品に寄生して銭稼ぎしようとbetaの頃に始めたのに悲しいよ 世界初のWebブラウザはObjective-Cによって産み出された
まあどーでもいいけど、いまやWeb全盛の時代にそういう言語で最新のアプリが作れる環境が与えられてんだから少しくらい感慨というものを感じてもいいんじゃないの 元々アホかなとは思ったが, >>135ぶりからアホってもんじゃねええ。Swift好きにも迷惑だと思うぞ >>130
C++を拒否というならSwiftによって／Swiftがだろうな、現在はw
macOS上のSwiftでは、まあ、Objevtive-C++でラッパー書いてそれをSwiftでだが、Linuxでぼちぼちっとじわっと使われているので、はよSwiftでC++のブリッジを(まあ、Cのインターフェースでラッパー作ればいいんだろうけど)
C++ブリッジの予定ないのかなあ Uiview.アニメーション関数を使いたいのですが、uiviewanimationoptionsの選択肢が
でてきれくれません。Youtubeを参考にしながら、optionsの部分をcurveLiniearに
したいのですが・・・cを入力しても候補が一切表示されず途方に暮れています。
どういった原因が考えられますか？助けてください。ゲーム作りたいです。 >>139
macOS/Objevtive-C++ありきのじゃね？ rustのメモリ管理の仕組みが採用されたらどんだけ幸せになれんのかな。
そもそもrustごと採用してくれれば良いのに いやそうでもないか…
言語仕様に振り回されてはいるが大概自分に原因を帰着してる
まだ信仰心旺盛なようだ でも静的にメモリ管理を解決するって
どんだけ良いものか気になるんだよね。
どうせswift5辺りで採用されんだから、先にrustに触って先行学習してても良いかもね。
多分swiftに採用されたら下位互換性また壊れるぜ Rustの元になってるC++ std::unique_ptrをどうぞ
ObjC++でも使えるゾ
>>141
下手な風評はSwift好きに迷惑だからやめろやｗ >>139
時々見る、この「つ」ってどういう意味？ >>148
c++にはなんでもあるんだね。
でも言語仕様で縛らなくても静的にメモリ管理って可能なの？c++のプリプロセッサがすごいってこと？ >>151
俺には「つ」が手に見えない。手のひら？手の甲？ >>152
オブジェクトへの参照が１個、複数の別で、
unique_ptr, shared_ptrを使い分ける。
参照するだけで、所有しないweak_ptrってのもある。
要するにリファレンス・カウント式のメモリ管理なのだ。
Objective-Cの設計をC++が取り入れたのかな？ ちなみに、俺はC++を最近全然使ってない。C++詳しい人、
unique_ptr, shared_ptr, weak_ptr
の解説、よろしこ！ >>154
ただのリファレンスカウント方式ならrustとは違うで。 逆だよ、C++のshared_ptrをObjCのARCに文法糖衣で取り込んだんだよ
>>152
unique_ptrは元々C++ boostのライブラリとして提供してたから出来るでしょ
ObjCもSwiftもそういう機能はライブラリじゃなく文法で取り込みたがるから言語更新待ちになるだけで リファレンスカウントは全然静的に解決しているメモリ管理機構じゃない。
rustのやり方はコンパイル時に指摘してくれるけど、リファレンスカウントはけっきょく動的に解決するわけだし。
それならとっくにswiftで実現してるし。ARCだろ。 >>157
Boost Software License - Version 1.0 - August 17th, 2003
って事は、Boostの方が歴史が古そうですなぁ。ObjCよりも。
俺、誤解してたわぁ。 Apple Inc. deploys ARC in their operating systems, such as macOS (OS X) and iOS.
Limited support (ARCLite)[5] has been available since Mac OS X Snow Leopard and iOS 4,
with complete support following in Mac OS X Lion and iOS 5.[6] Garbage collection was declared deprecated in OS X Mountain Lion,
in favor of ARC, and removed from the Objective-C runtime library in macOS Sierra.[7][8]
ref. en.Wikipedia://ARC
ARC Liteの出現は、2009, Snow Leopardからみたい。 rustのメモリ管理の仕組みを見てきたけどプリプロセッサで何とかなるというものじゃなかったから、
c++ならあると言うものじゃなかった。
言語仕様から改変か必要なものだったよ。
簡単に言えば、メモリの参照は一箇所に制限されて、そこからしかアクセスできないようにする。
たから、もしswiftでrustのメモリ管理機構が導入されたら、
100%既存のコードでは動かないし単純に変換もできない。
ロジックの見直しが必要だからね。
例えば配列にループアクセス中は
配列に対する変更操作はすべてコンパイルエラーになる。とか。 いやownership manifesto読めよお前ら
全部書いてあんのに >>148
https://github.com/sandym/swiftpp
これじゃねえの？XcodeありきObjective-Cありきだろ？
これじゃねえ、どれやねん？ >>161
「メモリの参照は一箇所」
まあ、そうかもしれんけど、俺の理解では参照カウントを１以上に上げない
様なメモリ管理ポリシーを実践する事で、メモリリークは防げると思う。
それから、Instrumentsとdebuggerを活用するのが吉。
最近気がついたのが、command+IでInstruments leaksを起動して捕捉出来なかったメモリリークが、不思議な事に、break pointで一旦止めてdebuggerからInstruments leaksを起動すると捕捉できるんだよねぇ。 =ア 【はい】
こういうのも👉に見えてなかったとか… >>153
手の平。
https://nanapi.com/ja/25657
https://m.chiebukuro.yahoo.co.jp/detail/q1410591729?__ysp=MmNoIOOBpA%3D%3D
[つ]は手を表現しています。
例えば、[（ ・∀・）つ旦]というAAでしたら
旦はお茶のAAですので、
お茶をハイ、と差し出している様子を表しています。
２ちゃんねるでは省略形をよく用いますので
顔文字が省略されて[つ]のみで使用されます。
>>165
まじっす！ >>170
そんな、補足説明が必要なAAなんて、不要だわぁ。 >>135
つまりは皆が出来ないうちに自分だけはSwiftを沢山書けるようになっておけば、Swiftがゴリ押しされたときに先行者利益を得られると思ったけどそうはならなかったから悲しいってことだろ？
別にAppleが推してないなんてことないと思うし、Obj-Cを崇めてる奴なんていないと思うし、Swiftはまだまだバージョンごとに変更がある割には十分普及してると思うけどな
大体Swiftをちょっと書かないと作れないぐらいのレベルだったら大してSwiftの知識もいらないと思うし銭稼ぎできるようなもんでもないと思うんだけどな
はじめにObj-C使わなきゃいけなくなったときに本1,2冊ぐらいしか買ってないし、Swiftに関してはお金まったく書けてないし、金稼ぎできる要素がある気がしない
>>138
C++をブリッジするとなるとC++の複雑な機能全てをブリッジ出来なきゃ有用性が落ちそう
限定された機能で書かれたC++コードだけブリッジしてくれるとかだと結局C++側がそれ以外の機能使ってたらラッパー書かなきゃいけなくなるし、落とし所が難しそう Swiftの完成度が最初から高ければ状況は違ったかもな
あとむだにWithout Cに走ったのは筋が悪かったと思うわ C++ブリッジってそれもうwith C++だからな
テンプレート除けばそれなりに出来るだろうけど
テンプレート除いたC++に対応したところでだから何なのって話になるし Without Cをぶち上げたんだからもうCに関わるなよ
韓国人かよ... Cライクforもインクリメント、デクリメントもなくす無駄な徹底ぶりだからな なんかswiftどんどん構文追加して複雑になってないか？
phpみたい >>176
マルチプラットフォーム化に加えて
膨大なossがcやc++で書かれてるんだから無視は不可能だ。 むしろ、Objective-Cの「インスタンスは母体クラスに［おまえのインスタンスを作れ］命令で作成します」とか
「クラス間の通信はクラス［命令:引数］で明示的に他のクラスに実行させてるとわかります」が好きだったので
そのあたりswiftが「退化」しちゃったのが嫌。
言語仕様とクラス仕様が分離しててクラスライブラリだけ進歩してくとか
ソース内で自他の表記がしっかり別れてて「ここであいつがこれやって次…」
と読めるのが気に入ってたのに
他のグチャグチャモダン言語と同じ言語仕様変更地獄と
ソースになんだかわからない誰かが作った記号が普通に混じりますって
これ、ずっとプログラミング文化の発展阻害してた奴だ…と >>183
>明示的に他のクラスに実行させてるとわかります
Swiftでは分からんの？ >>183
>ソース内で自他の表記がしっかり別れてて
これ何のことを言ってんの？
自他の区別がつかない言語なんてあんの？
そんな精神病みたいなプログラムあっても実行できなくね 多分全部staticで書いてんだろ
おそらくインスタンスとクラス、動的メッセージと静的メソッドの違いがわかってない $
↑こいつ
今までの理念をぶちこわすような暴挙
itでもなんでもよかったのになんでこれにした 一方俺は、ObjCの言語仕様にクラス変数が追加されて、既存フレームワークのクラスメソッドがクラス変数に変わって発狂していた
>>188
$0, $1, etc.として複数引数の場合でも引数記述を省略させるためでしょ
シェルスクリプトを書いたことないとなんぞこれってなるが、it0, it1よりはスマートだと思うが >>181
なので普通に考えるとObjective-C 3.0として改良発展させるのがよかったと思うんだよね... >>189
いちいち引数に名前つけさせて、
省略できるのはひとつまでって感じで今まできてたじゃん！
ここにきてこれ
itですら多少は意味があるが、$ってなに？
なんで急にドル記号が出てくんの itの方がマシというのは別に否定しないけど
「今までの理念」というのはSwiftには無くね 俺はitより$nの方がマシだと思うけどね
「名前を省略する」ためのものに「名前をつけた気になる」ために$nをやめてitにするってかなり本末転倒じゃない
どうせ具体的な名前が無いなら、極めて曖昧なitなんて単語じゃなく、どこまでも記号的な$nでいい
敢えて単語にするならanonymousArgumentとかclosureArgumentとかにして、クロージャの名前がない引数であるという意味を表さないと
itなんて、$nと同じぐらい何も意味を表さないのに、無駄に単語の体をしてるだけタチ悪いと思うわ
逆にwillSetの引数名省略時のnewValueみたいに、最低限あらかじめ意味が限定されてるところでは、$nでもitでもなくちゃんと最低限の意味を表す省略形になってる どーでもいいけどいい加減syntaxのセンスがクソ過ぎやしないか？ 本音をいうと省略させたくない
書き方増やしてどうする 俺も書き方のバリエーションが増えるのは反対だな。誰が書いても同じ文法で、誰が書いたコードでも誰でもさっと読めるのが理想だったな。 swiftでrxSwiftさわったらすごくRxがわかりやすくなったのは良い思い出。
objcだとわけわかめだった。
構文って結構学習コストに関わるんだなって理解した瞬間でした。 >>198
Haskellが普及しないのは、その理想を追い求めすぎてるからだけどね >>200
書き方のバリエーションの少なさでいったらgoがいい感じではないかと。
中括弧の位置すら強制するからね。 objCは文法に多様性がありすぎて俺には理解できなかった Blocks構文は「それそういうクラスじゃいかんの？Cに付け足す理由は…？」といまだに >>199
ObjCにはCocoa Bindingがある。 >>204
双方向バインディングとRxを一緒にするない。 >>202
メッセージ式は面食らったが、CとJavaをやってたからあんまり覚えることなかったけどなObjC >>183
> クラス［命令:引数］
スレチ引っ張って悪いけど、ObjCにこういう記法あったっけ？
[クラス 命令:引数] とかだと思ってたのだが… レベルに合わせた書き方すりゃいいじゃんよ
generics,typealias,operator overload この辺は無理して使うことない
boilerplate無くしてえなーもっとコードを直感的に書きてえなー、そもそも今までの書き方飽きたから違った書き方してえなー
という欲求が生まれた時に導入すれば良い。そうすりゃObjCとも大して見た目変わらんしな >>209
なるほどぉ。
ところで、Swift -> ObjCへ移行する時に、RxSwift相当のFramework
って、ReactiveCocoaって事になるのかなぁ？ Swift一発屋になってんじゃねえか。
ピコ太郎だってもっとまともにやってるぞ。
もっと頑張れよApple。熱くなれよ！ >>210
言っておくけど、Rxとobjcは全く相性が悪い。
なんでかというとあのobjcのメッセージ式
Rxってメソッドチェーンが無いとかなり実装しづらいのに
objcでは書けないのだよ。
[]のネスト地獄を味わう事になる >>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では@を置き換えるみたいな感じで ■ このスレッドは過去ログ倉庫に格納されています
