アカウント名:
パスワード:
「プログラム」の初心者向けということなら、まず if else の羅列を見せてうんざりさせてから switch を教えるというのはありだと思う。大昔、私が初めて「プログラム」という仕掛けを知った時の本(多分ブルーバックス)での BASICの説明がこんな調子だった、多方向分岐も条件ループも IF文とGOTO文だけのプログラムで動きを示してから、ON だの FOR だのそれぞれの構文を示していた。
ややズレますが、switch文 という話だと、『単純に置き換えていい』と思わせちゃっていいのかな? と:Stringとかオブジェクト類 だと、ちょっと意図と変わりますよね (中身でなく、同一インスタンスかどうか の比較だから)。
こういう状況で 文字列比較したいわー というとき よくありますけど、Javaのswitchだと その周りの理由で 正しく中身の比較 にならなかったと思います。//まあ、『==』をまんま置き換えてるだけなので、Javaの『==』の仕様ですが。//JavaScriptだと 比較とか型とか適当だから 勝手に合わせて 中身の比較にしてくれたりしたような。
比較周りの話で教えるべき かもしれませんけど、意外とswitch あんまり簡単でもないよなー、と。
//数ページずらー が ないわー;とは思います(;^ω^)
Java の switch では、Java6以前だと 整数とenumだけでそれ以外のオブジェクトは使えなかったと思います。7 で String が使えるようになり、equals による中身の比較を行うようです。ついでに言えば、一つの switch の中で 整数やStringを混ぜて使うなんてこともできないです。
むしろ、JavaScript の switch の方が、=== のまんま置き換え、となるようです。(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/switch)=== による比較なので、== とは違って、型を勝手に変換したりもしないみたいです。文字列同士の場合に中身の比較になるのは、JavaScriptの === の仕様ってことになるのでしょうね。
あ、昔は そもそも型で弾かれて使えない → 今 文字列の中身比較になった;なんですね。ちょっと間違えて覚えてたようです。
最近のバージョンだとString にswitch文を つかうと、同一インスタンスかの比較ではなく、文字列の内容を比較するようになったのでは?7だか6だかから。
そーゆー話じゃないと思いますたとえ話にツッコミ入れて本題とは関係ない議論を繰り広げる会議を思い出した
関係ないけど、1行目の
と思わせちゃっていいのかな? と:
が三項演算子に見えてしょうがない//if(と思わせちゃっていい)// return と;
>「プログラム」の初心者向けということなら、まず if else の羅列を見せてうんざりさせてから switch を教えるというのはありだと思う。
それでも3回繰り返したらわかりそうっすね。
なるほどだからsync; sync; syncと3回繰り返すんですね(多分違う)
そして "halt"へ
たいした理由もないのにsyncは3回と教えてた人たちもあれだったなあ。
2回までは理由あります。1回目のsyncがブロッキングコールなので、2回目が走るときは1回目が終わってることが保証されたはず。3回目の理由は知りません。おまじない?#これ、特定の実装に依存して「3回」じゃないのかなぁ?#STOP-A sync は書き込み終わるまで帰ってこなかったような
sync 自分の為
sync みんなの為
sync 念の為
人民の人民による人民のための sync、的だ
最近某ファイルシステム見てたんだけど、1回目のsyncで新たな依存関係ができてそこがdirtyになり、これを書き出すには2回目のsyncが必要っぽかった。ただし3回目はやっぱり意味がなかった。
特定の実装っちゅうか、ファイルシステムの実装次第よね。
紅茶の茶葉をポットに入れるとき、1杯目は自分のため、2杯目はあなたのため、3杯目はポットのため、てのを思い出したわ。
そういえば、先日 sync 2回派の人に遭遇して、なんか新鮮でした。
去年短期間参加した基盤担当のグループは sync; sync; sync と3回が今も隆盛でした。HP-UX 11iであることよりもそっちの古き善き伝統がほほえましかった。2回というのは少数派なだけに目立ちますですね。
条件の定義が同時に発生していない時なんかは、if elseが続く事は散見される。忘れた頃に使用追加が行われ、その為のコードレビューを省くためにその事象のみを追加。
を、何度も何度も何度も何度もやっていると、そういうソースになる事も。
そして、気を利かせた奴がコッソリ直したつもりで動かなくしちゃうっての迄見た事有り。
えとすいません今21世紀なんですが
21世紀になると何か変わったんですか?もしかして人間の知能が向上したとでも?
> えとすいません今21世紀なんですが
つまり#2651008のAC氏は車輪の再発明を延々と繰り返しかねないお利口さんと言う話で?
発見学習という言葉あるから、再発見は学習効果が高く有効なんだろう。
単なる勉強不足、もの知らずでしょ。
知らないから勉強してるんだろ、そのための発見学習なんだからそれを勉強不足とか言い出すのか頭がおかしい。
そうだね。その通り。発見学習なんて言葉を持ち出す時点で、ボクはもの知らずなんですって言っている様なもんだからね。
でだ、発見しなければならないのは勉強する対象じゃない。自身の勉強不足と言う現在の状態なんだよ。それに気が付かないのがお利口さんだし、延々と車輪の再発明を繰り返すのもやっぱお利口さんなんだよね。
昔使ってたBCのコンパイラはswitchのcaseの数に上限があって(128個位だったかな?)なんだかんだで結構苦労した気がします。そもそも当初設計したときにはそこまで増えるとは想定してなくて不具合出るのが嫌なので誰も改善しようとせずにcaseだけ増えていくという綱渡り状態でした。
制御系の電文とかだと意外とこんなんになったりするかも。
つ http://developers.srad.jp/comments.pl?sid=637690&cid=2651341 [srad.jp]
switch 文では何一つ解決にならない。
イベントループやタスクシステムと呼ばれる構造を理解してもらう事が目的なら、仰るとおりです。でも、元のコードをよく見てください。分岐の中でイベントプロシージャを呼んでるわけじゃないんです。if文自体が不要なんです。4ページ全部要らないんです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
もしかしてエンドレスエイト (スコア:2, 興味深い)
「プログラム」の初心者向けということなら、まず if else の羅列を見せてうんざりさせてから switch を教えるというのはありだと思う。
大昔、私が初めて「プログラム」という仕掛けを知った時の本(多分ブルーバックス)での BASICの説明がこんな調子だった、多方向分岐も条件ループも IF文とGOTO文だけのプログラムで動きを示してから、ON だの FOR だのそれぞれの構文を示していた。
Re:もしかしてエンドレスエイト (スコア:2)
ややズレますが、switch文 という話だと、『単純に置き換えていい』と思わせちゃっていいのかな? と:
Stringとかオブジェクト類 だと、ちょっと意図と変わりますよね (中身でなく、同一インスタンスかどうか の比較だから)。
こういう状況で 文字列比較したいわー というとき よくありますけど、
Javaのswitchだと その周りの理由で 正しく中身の比較 にならなかったと思います。
//まあ、『==』をまんま置き換えてるだけなので、Javaの『==』の仕様ですが。
//JavaScriptだと 比較とか型とか適当だから 勝手に合わせて 中身の比較にしてくれたりしたような。
比較周りの話で教えるべき かもしれませんけど、意外とswitch あんまり簡単でもないよなー、と。
//数ページずらー が ないわー;とは思います(;^ω^)
Re:もしかしてエンドレスエイト (スコア:2)
Java の switch では、Java6以前だと 整数とenumだけでそれ以外のオブジェクトは使えなかったと思います。
7 で String が使えるようになり、equals による中身の比較を行うようです。
ついでに言えば、一つの switch の中で 整数やStringを混ぜて使うなんてこともできないです。
むしろ、JavaScript の switch の方が、=== のまんま置き換え、となるようです。
(https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/switch)
=== による比較なので、== とは違って、型を勝手に変換したりもしないみたいです。
文字列同士の場合に中身の比較になるのは、JavaScriptの === の仕様ってことになるのでしょうね。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:もしかしてエンドレスエイト (スコア:2)
あ、昔は そもそも型で弾かれて使えない → 今 文字列の中身比較になった;なんですね。
ちょっと間違えて覚えてたようです。
Re: (スコア:0)
最近のバージョンだとString にswitch文を つかうと、同一インスタンスかの比較ではなく、文字列の内容を比較するようになったのでは?7だか6だかから。
Re: (スコア:0)
そーゆー話じゃないと思います
たとえ話にツッコミ入れて本題とは関係ない議論を繰り広げる会議を思い出した
Re: (スコア:0)
関係ないけど、1行目の
と思わせちゃっていいのかな? と:
が三項演算子に見えてしょうがない
//if(と思わせちゃっていい)
// return と;
Re:もしかしてエンドレスエイト (スコア:1)
>「プログラム」の初心者向けということなら、まず if else の羅列を見せてうんざりさせてから switch を教えるというのはありだと思う。
それでも3回繰り返したらわかりそうっすね。
Re:もしかしてエンドレスエイト (スコア:1)
なるほど
だからsync; sync; syncと3回繰り返すんですね(多分違う)
Re:もしかしてエンドレスエイト (スコア:1)
そして "halt"へ
Re: (スコア:0)
たいした理由もないのにsyncは3回と教えてた人たちもあれだったなあ。
Re:もしかしてエンドレスエイト (スコア:3, 参考になる)
2回までは理由あります。
1回目のsyncがブロッキングコールなので、2回目が走るときは1回目が終わってることが保証されたはず。
3回目の理由は知りません。おまじない?
#これ、特定の実装に依存して「3回」じゃないのかなぁ?
#STOP-A sync は書き込み終わるまで帰ってこなかったような
Re:もしかしてエンドレスエイト (スコア:3, おもしろおかしい)
sync 自分の為
sync みんなの為
sync 念の為
Re:もしかしてエンドレスエイト (スコア:1)
Re: (スコア:0)
人民の人民による人民のための sync、的だ
Re: (スコア:0)
最近某ファイルシステム見てたんだけど、
1回目のsyncで新たな依存関係ができてそこがdirtyになり、
これを書き出すには2回目のsyncが必要っぽかった。
ただし3回目はやっぱり意味がなかった。
特定の実装っちゅうか、ファイルシステムの実装次第よね。
Re: (スコア:0)
Re: (スコア:0)
紅茶の茶葉をポットに入れるとき、
1杯目は自分のため、2杯目はあなたのため、3杯目はポットのため、
てのを思い出したわ。
Re: (スコア:0)
そういえば、先日 sync 2回派の人に遭遇して、なんか新鮮でした。
Re:もしかしてエンドレスエイト (スコア:1)
去年短期間参加した基盤担当のグループは sync; sync; sync と3回が今も隆盛でした。
HP-UX 11iであることよりもそっちの古き善き伝統がほほえましかった。
2回というのは少数派なだけに目立ちますですね。
Re: (スコア:0)
条件の定義が同時に発生していない時なんかは、if elseが続く事は散見される。
忘れた頃に使用追加が行われ、その為のコードレビューを省くためにその事象のみを追加。
を、何度も何度も何度も何度もやっていると、そういうソースになる事も。
そして、気を利かせた奴がコッソリ直したつもりで動かなくしちゃうっての迄見た事有り。
Re: (スコア:0)
えとすいません今21世紀なんですが
Re: (スコア:0)
21世紀になると何か変わったんですか?
もしかして人間の知能が向上したとでも?
Re: (スコア:0)
> えとすいません今21世紀なんですが
つまり#2651008のAC氏は車輪の再発明を延々と繰り返しかねないお利口さんと言う話で?
Re: (スコア:0)
発見学習という言葉あるから、再発見は学習効果が高く有効なんだろう。
Re: (スコア:0)
単なる勉強不足、もの知らずでしょ。
Re: (スコア:0)
知らないから勉強してるんだろ、そのための発見学習なんだから
それを勉強不足とか言い出すのか頭がおかしい。
Re: (スコア:0)
そうだね。その通り。発見学習なんて言葉を持ち出す時点で、ボクはもの知らずなんですって言っている様なもんだからね。
でだ、発見しなければならないのは勉強する対象じゃない。自身の勉強不足と言う現在の状態なんだよ。それに気が付かないのがお利口さんだし、延々と車輪の再発明を繰り返すのもやっぱお利口さんなんだよね。
Re: (スコア:0)
昔使ってたBCのコンパイラはswitchのcaseの数に
上限があって(128個位だったかな?)
なんだかんだで結構苦労した気がします。
そもそも当初設計したときにはそこまで増えるとは想定してなくて
不具合出るのが嫌なので誰も改善しようとせずにcaseだけ増えていくという
綱渡り状態でした。
制御系の電文とかだと意外とこんなんになったりするかも。
情弱ホイホイ? (スコア:0)
つ http://developers.srad.jp/comments.pl?sid=637690&cid=2651341 [srad.jp]
switch 文では何一つ解決にならない。
Re: (スコア:0)
イベントループやタスクシステムと呼ばれる構造を理解してもらう事が目的なら、仰るとおりです。
でも、元のコードをよく見てください。分岐の中でイベントプロシージャを呼んでるわけじゃないんです。if文自体が不要なんです。4ページ全部要らないんです。