Swift part10 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
さすが、>>96のシンプルな表記がクッソごちゃごちゃな表記になるね
でもエレガントなのさ
Swiftだからね >>99
素晴らしい！
import Foundation
var a = NSNumber(value: 1)
var b = NSNumber(value: 2)
var ar = NSMutableArray()
ar.add(a)//, b])//(array: [a, b])
ar.add(b)//, b])//(array: [a, b])
a = 3
print(ar)
print(a)
NSNumber使えばできるのか？と思いきや、失敗！ UnsafePointer周りの公開IFは2.0から3.0までですら二転三転したから信用して使わない方が良いぞ、多分また変わる
Xcodeの自動コンバートでサポートしきれない変更だったから毎度手間だった
その覚悟をもって遊ぶなら楽しいオモチャではある
すごく日曜プログラマ向け そもそもSwift自体が意識高い日曜プログラマー向けなんだから気にしない気にしない >>78
他の言語は基本後方互換はそのままだから
別にいいんだけど
swiftは後方互換がなくなるからな
そこは根本的に違う どの言語もメジャーバージョンアップ時には完全後方互換じゃない気がするが
ただ、頻度が少ないだけで 完全広報五感の縛りは進化を妨げる
ツールでコンバートさせるswiftとアプローチは正解
さすが至高の言語swich はっはっは
マイナーバージョンアップで互換性を壊すのがswiftだ
そんじゃそこらの言語と一緒にして貰っちゃ困るぜ？ ExpressibleByIntegerLiteral使えばもうちょいシンプルにできる？ >>96
名前でのアクセスとインデックスでのアクセスを両立したいってことかな？
俺だったら、名前→インデックスの辞書を持つ専用のクラスを作る 正直Swift熱は若干冷めてきたように思う
サーバーサイドSwiftとかもちっと頑張ってくれんかなあ 2.0, 2.1くらいまではまだswiftが業務に利用できると騙された奴がいたけど、さすがにもう居ないから...
こんな不安定な言語とランタイム、信仰心/遊び心以外で使うのは無理だよ
5になってAPI, ABIが安定したら再燃することを祈ってる
>>115
swift
他の信仰言語は文法,API,ABI他諸々が下位互換を保証するフェーズにまで枯れて冷めてる >>115
はあ？
最もエレガントかつモダンでいらっしゃる超絶至高言語Swift様に決まってんだろ
馬鹿なの死ぬの？ ブームは確かに去り始めてる気はする。
けど言語はまったく枯れ初めていないっていう現実。
ところで今年のtryswiftはどうだったの？
相変わらずswiftと関係ない話題ばかりだった？ >>115
Scala, Groovy をミックスした、Android用のJVM言語、Kotlin 3への移行がダルすぎる
みんなもうやったんだろうな、、
2、3と共に生きるわ RxSwift3.20に付属のPlayground重すぎ。特にCombining_Operatorsが。
マシンパワーが不足なのか？特にCPU Power。メモリ搭載量(16GB)には問題無いみたいだが、IvyBridge世代のcore i5 2coreには辛いのか？
同じ感想の人入れば、レスお願いします。 RxSwift3.2.0を動かしてます。SubjectはObservableかつObserverだと言うので
次のコードをiOSアプリ内で動かしてみました。
import RxSwift
let sb = BehaviorSubject(value: 100)
let v = Variable(2000)
_ = v.asObservable().bindTo(sb)
print(v.value)
_ = sb.subscribe{print($0)}
// 2000
// next(2000)
このコードがPlaygroundで動きません。ObservableはbindToメソッドなんて
持ってないよ！と怒られます。どうやれば、Playgroundで動かせますか？ ちなみにmacOSアプリ内でも動きました。
Playground内だけで動きません。ウェーン！ >>126
import RxCocoaを追加すれば動いたよ >>128
まじっすか？
Playground execution failed: error: MyPlayground2.playground:1:8: error: no such module 'RxCocoa'
import RxCocoa
当方では、moduleを見つけてくれないです。 もしやRxCocoaをbuildしないといけないのか？もう一回！ みなさん、あんがと！
bindToが動きました。
no such module when openning playground
でヒットしました。 RxCocoa-iOSのbuild時間 46.837sec
でした。
結構、時間かかります。 >>133
Java, C++には遠く及ばないんだよねぇ。
おれ、Java嫌いなんだよねぇ。けど、TIOBE Programmer’s Indexでは1stなんだよねぇ。 Swiftの敵は、Java、C++じゃなくて、Objective-Cだから っていうかObjective-Cを初めて上回ったっていうのが驚きだわ
感覚的にはObjective-Cはとうの昔に終わってて
もうみんなSwift使ってるとおもってたんだが ん？
記事には、「2015年12月にはObjective-Cを初めて上回り」
って書いてあるが
文盲かな なぜSwiftを使うのか
それはApple様御用達だからである
つまり超絶至高言語であることが生まれながらにして確定している言語
後光なんかも射しちゃってるレベル ちょいちょい順位ネタ貼られるよね
そんなに「宣伝」しないといけないほどひどい言語なの？Swiftって 俺にとってはSwiftはRubyの皮を被ったC++
Generics標準ライブラリが充実してるのがGood。
文字列Stringが最初から標準ライブラリに入ってるのもoK. >>143
言い方悪かった。
文字列の扱いがStringに統一されているのが良さげ。
参考：Visual C++
char 型のナロー文字リテラル。たとえば 'a'
wchar_t 型のワイド文字リテラル。たとえば L'a'
char16_t 型のワイド文字リテラル。たとえば u'a'
char32_t 型のワイド文字リテラル。たとえば U'a'
もう、ワケワカメ！
このほかにもCStringとStd::Stringもある。 C言語ってやっぱり高級感のバランスがいいと思うわ
で、その良さをそのままにオブジェクト指向を導入したObjective-Cは...
おっとここまでにしておかなくては >>144
C++11でstd::stringが標準ライブラリに入ってるんだよなぁ
未だに拡張文字列ライブラリしか見てない時代遅れ乙 >>142
Rubyとは普通に違う気がするが…
Groovy（Kotolin）が見た目の文法は一番近い
Swiftは関数のラベルのところが独特 >>147
C++98な
VC++6.0のときからある
当時はTCHAR対応でtstring使ってたけど collection.map { ..... }
の書き方は
collection map {....}.
ってかくsmalltalkの書き方の真似だよ。
rubyでは{...}がオブジェクトじゃないからこうするんだけど
swiftは{...}がオブジェクトだけど関数の()が省略できないから
という理由でこうするのだろうね。 >>152をもしよむには、そこの間に:忘れたから各自補っておくように。 >>152をもしよむには、Smalltalkのブロックが [ ] になってないからこれも各自脳内置換するように。 >>152
それ単にブロックを受け取るキーワードメッセージを一番最後に持ってきてるだけでしょ。
ブロック引数を特別扱いして不完全だけど有用な文法を作り出したrubyが真似たと言うにはちょっと… >>152
Swift や Ruby のメソッド map に相当する
Smalltalk のメッセージは collect だよん
まとめよう
[Swift]
・collection.map({ ..... }) // 一般的(常識的？)な書き方
・collection.map() { ..... } // クロージャを引数リストの直後へ移動できる
・collection.map { ..... } // さらには丸カッコ () も省略できる
[Ruby]
・collection.map(lambda { ..... }) # Ruby だと一般的ではない
・collection.map() { ..... } # ブロックを引数リストの直後へ移動できる（ブロック付きメソッド呼び出し）
・collection.map { ..... } # さらには丸カッコ () も省略できる（これが普通の Ruby らしい書き方）
[Smalltalk]
・collection collect: [ ..... ] "書き方はこれだけ"
たったこれだけで Swift の Tailing Closure は「smalltalkの書き方の真似」って言い切っちゃう>>152さんて素敵(棒 よくわかんないけど
だからSmalltalk系譜のObjCは最高！Swiftはクソ！！
っていう荒らしの流れでおk？
swiftがperlとpyhtonとrubyとphpとjavaとc/c++とkotlinとgoとrustとetc....に似てるって
swift betaが出た当初から言われてたのに「SwiftはRubyの皮を被ったC++ 」とかヘソで茶が沸くよね
あっちこっちの言語から文法パクってるのに自分が知ってるRubyだけしか注目できてないだけじゃねーかw rubyの言いたいことはメソッドの定義をメソッドの使用する形で書けるようにするって
事で、
smalltalkの言いたいのはオブジェクトの定義をオブジェクトにメッセージを送る形で
書きたかったということだから発想は同じ。
例えばC言語だと定義はint f(){}の形だけど使うのはf()の形だから同じじゃないからね。 >>157
せっかくSwift と似ている言語として「perlとpyhtonとrubyとphpとjavaとc/c++とkotlinとgoとrust」を
挙げてくれたのだから、各言語ユーザが自分の知っている言語に注目して、似ている所をカキコすれば
いいのではないかと思われ
たとえば、もし仮に Swift で内包表記が採用されていたなら、
「Swift は Pythonから内包表記をパクった」と主張できるよね
あるいは「Swift の Tailing Closure と似ている言語は XXX がある(Ruby だけじゃない)」といふ
意見が出てくれれば嬉しい限りですねえ Haskellにも似てるらしいぞ
CPUの歓声が聞こえてくるところが >>151
その程度の類似でRubyの皮を被ったとは言わんだろ >>156
どうてもいいけどRubyはcollectの別名がmapだよ
普通はmapのほうを使うけどね 他の言語の影響受けてるのは明言してるんだし
パクッてオリジナル主張してるわけじゃないから何に似てようが別に良くね
話の発端っぽい>>142も「俺にとっては」とあるから
単に当人が知ってる範囲内での感想だろう 別に良いよ、Swiftの世間話として談笑してるだけだよー
SwiftはPythonから関数引数の順不同指定可をパクった
・・・が2.xのいつぞやのタイミングで仕様ドロップと相成って悲しい
確かにSwiftで使うメリット少なくて利用者いなかったかもしれんけど、わざわざ実装したのに勿体ない >>166
名前付き引数の順不同化はSmalltalkのメッセージ式を見たら誰でも最初に思いつくアイデアだけど
似たようなObjective-Cのやり方を内部的に引きずっていたらきっと難しいだろうね
ちょっと試すくらいなら簡単だけど、すぐに破綻をきたす >>165
話の発端「Rubyの皮」、の発言人です。
Pascal, Clang, Fortran, Lisp, Ruby, Visual Basic, C++を触ってきた経験からの
感想です。Rubyの皮を被ったC++ってのは。
Swiftはいろんな言語の影響を受けてる事が判りました。
今はJavaScriptを触りたいけど、時間が無い。 >>171
プログラミング言語の黎明期に名を馳せた大御所だから
言語の歴史と発展を語る上でその存在は無視できない >>173
では、その大御所は現代のプログラミング言語にどの様な、影響を与えているのでしょうか？ 影響というより、その冗長性と非モダンな特徴からくる反面教師としての側面の方が大きいかな
COBOLを知っていないと実感をもって指摘はできないだろうけど >>176
まあまぁ、そんな過激な事言わずに！
ってか、ボキャ貧すぎる。 C言語系やっていてK&Rを知らないってどういう事？ >>179
日本人やってるけど原文で源氏物語スラスラ読める奴少ないだろ？
既に古典なんだよ スラスラは読めないけど、作者と大体のあらすじは知ってるわな >>183
草書は無理だけど行書は読めるんでない？ 文法もわからんしAPI仕様書もない、ムリゲ
しかし、日本語の大御所で基礎の基礎だから読めないヤツは日本語を話る資格ないのか
これからは日本語でおkとか言えないな、、、 コンパイラなんてそんなもんだよ
ソースが同じでもテキストフォーマット変わればコンパイル通らないし
同じ言語でも世代が違えばコンパイル出来なかったり動作が変わったりする >>193
Ruby1.8, 1.9しか知らんのだけど、今時の2.4ってのは全然動作が違うのかね？
osx El CapにはRuby2.0搭載なので、極タマに使ってみて、あんまり変化の無い
事に安心してるんだが。 >>191
「日本語でおkとか」の「とか」は、「日本語でおk」以外の何？ とか
1.
《副助》例をあげて並べるのに使う。 「Ａ―Ｂ―の記号」
2.
《普通は下に「言う」「聞く」などを伴って》 《連語》内容が不確かであることを表す。 「橋沢―いう人」
>>191の場合は、「2.」の用例だろ
つまり、
「日本語でおk」だったか、「日本語でOK」だったか、「日本語でおっけー」だったか不確かだけど、そんな風な言い方
ってこと >>196
内容が不確かな事を書かれても、不確かなのだから、何を書きたいのか解らないよ。 >>197
>>191の言いたいことは、”日本語でおk”のネタさえ知ってれば通じるだろ
通じなかったとしたらネタを知らないか、アスぺなだけだろ >>199
この人はこのスレに住み着いて「とか」だけに反応する可哀想な人だから
みんなでとかとか使いまくってもっと可哀想にしてやろうよ(いじめの提案)
>>197
不確かであることを明示して話を進めることはよくある事だよ
主に明確化に意味が無い、あるいは主題を明確にするために枝葉部分を意図的に明確定義しない、などの用法がある >>191のとかは不相応の程度を強める際の「なんて」と可換なニュアンスだろう
例 ハゲとか無理 ■ このスレッドは過去ログ倉庫に格納されています
