「Smalltalk」を含む日記 RSS

はてなキーワード: Smalltalkとは

2022-04-18

anond:20220418144442

いや、 Python ではクラスオブジェクトだよ。

メジャー言語の中では Smalltalk とか Common Lisp とか Ruby あたりがそういう立場をとってる。

言語によって理屈の付け方 (パラダイム) は異なるのでオブジェクト指向の原理原則言語仕様は分けて考えないといけない。

でも、最初の段階で躓いちゃう初心者はそこらへんのレイヤを分けて考えるってことが出来てないんよ。

2021-06-30

anond:20210630164528

アラン・ケイらによってAlto上で開発された世界初GUIベースオペレーティングシステム (OS) 的存在であるSmalltalkは、パーソナルコンピューティング方向性エンドユーザーに示すだけでなく、オブジェクト指向概念を本格的に取り入れた設計開発者にもアピールし、このときオブジェクト指向によるOSAPIフレームワーク設計は、現在最先端と言われるOSにも今なお色濃い影響を与え続けている。

1970年代半ばにはすでに、ウインドウシステムメニュー操作アイコン付きパレットWYSIWYGエディタなど、現在パソコン匹敵する特徴も備えていた。出資受容の条件に要求してこれを見た、Apple Computerスティーブ・ジョブズに大きな影響を与え、LisaMacintoshを開発させるきっかけとなった。

2021-02-14

からオブジェクト指向オブジェクト指向プログラミングは全くの別物だろって言ってるだろうが

言ってないけど。

Cから派生したCやJavaなどでやってるのはオブジェクト指向プログラミング

メッセージングメソッド呼び出しで近似して、

クラスというものを作って、「カプセル化」、「継承」、「ポリモーフィズム」を三本の矢にして

いかデザパタマウント取るかを競い合う競技のことだ。

これを提唱しているのはオブジェクト指向プログラミング日本語解説しているWikipediaなので間違いない。

現在日本人に対してオブジェクト指向とは何かと問えばこれのことなので、これさえ押さえておけば会話に問題はない。

なまじっか真のオブジェクト指向精通していると、英語版wikipediaオブジェクト指向を学び、smalltalkなんかかじった日には、現代日本におけるオブジェクト指向いかに偽物かわかるだろうが、奇異にみられるのはあなた自身であることを付け加えておく。

2020-12-20

プライベートメソッドテストすべきか

「すべきでない」というのがたぶん多数派

テストすべきでない理由としてだいたい次の理由があげられる。

プライベートメソッド関数テストする必要は無いと考えていますプライベートメソッドは、実装の詳細であるからです。

多くの場合、そのクラスパブリックメソッド経由でプライベートメソッドテストも同時に行えます

プライベートメソッドのテストは書かないもの? - t-wadaのブログ

ほとんどの場合プライベート メソッドテストする必要はありません。 プライベート メソッド実装の詳細です。

プライベート メソッドがある場合は、パブリック メソッドを見つけて、そのメソッドに対してテスト記述します。

単体テストを記述するためのベスト プラクティス - .NET | Microsoft Docs

プライベートメソッドテストするな」と強く主張されるのは、ケント・ベックの影響もあるかもしれない。

例えばtwitterで、パブリックメソッドにだけテストを書き、テスト必要なほどプライベートメソッドが複雑ならそれを別のオブジェクトに切り出す必要があると発言している(twitter/kentbeck)ように、プライベートメソッドテストに強く反対している。

またベックの書いたSUnit(xUnitの源流にあたる)には「ひとつテストひとつオブジェクトで表し、それによってテスト独立性を高める」というアイディアが使われている(そのアイディアを実現するためにとても複雑な設計をしている Simple Smalltalk Testing: With Patterns)。テスト自身ひとつオブジェクトとして独立しているなら、テスト対象となるオブジェクトプライベートメソッドテストできないのは当然のことになる。

しかし「プライベートメソッドテストがしたい(したくなることがある)」と感じる人も相当数いる。

そう感じる人にとってはむしろここからが本題で、

問題になる。

テストファーストで開発するなら手を動かしながら軽い気持ちで書きたい。

例えそのクラスがprivateメソッド依存関係があっても。

コンストラクタインジェクションされたクラスのprivate メソッドでもテストファーストしたい - Qiita

privateなルーチンの自動テストは面倒だ。実際にコーディングするとき最初publicにしておいてテストしてうまく動いていそうならprivateにするのだけど、この「いそう」がくせ者。いっそのことすべてpublicにしたくなる。

私は元々メソッドはprivateにしない主義なのでメソッド場合問題ないのだけれど、ファイル内の「関数」が問題になる。和了計算だと和了形判定とか符計算とか和了役判定とか単体でテストしたい内部関数が山ほどある。(twitter/koba0367)

private メソッドテストすべきか問題原則論だけだと袋小路に入りがちだから、private メソッドテストしたくなる具体的な場面について議論したほうがいいと思う。

自分レビューでよく見る例としては、複数の public メソッドの重複部分を private メソッド抽出した結果、濃い private メソッドと薄い public メソッドが一対多関係になる場合が挙げられる。設計としては間違っていないし、わざわざ public メソッド経由でテストする意義があるかというと微妙。(twitter/ts7i)

きれいなインターフェースを作ろうとすればするほどpublicメソッドじゃない部分に複雑性を追いやることになり、壊れた時に手戻りが大きすぎると思ったら、プライベートバックドア開けてでもテスト書くようにしてます (twitter/mizchi)

しかプライベートメソッドに対するテストを書こうとすると大概リフレクションなどで可視性の制限をすり抜けるとかメソッド可視性を変更するといった回りくどさやコストの導入が必要になるので、じゃあプライベートに対するテストはそうしたコストに見合うのかが問題になる。

伊藤さんの答えは「原則書かないほうがいいという大前提のうえで、どうしてもというときは、"これはテストのためにpublic"にしているというコメントの上でpublicにする」だった。

自分は「テスタビリティのためにメソッドをpublicにする」っていう"実プログラム挙動を変えること"の方が、「privateなメソッドテストコードのみsendで叩く」よりも怖いって思ってることに気がついた。(twitter/highwide)


メソッドプライベートパブリックかという話とそれをテストするかどうかは別問題だろという意見もある。

単体テストホワイトボックステストだとするなら、publicかprivateかでテストの有無が変わるのは明らかにおかしいだろ。ややこしいロジックはprivateに隠蔽すべきだが、そこがテストできないなんて。 (twitter/kmaebashi)

private メソッドテストするかどうか? まず最初に言っておきたいのは public/private は抽象設計問題であって、テストすべきかどうかとは当然無関係だろうということ。(twitter/qeigoi)

特定言語の貧弱な機能思考制限を受けて誤った結論を出している典型的な例。

"テストを書くべき"と"上位層から可視性"は直交する概念

https://b.hatena.ne.jp/entry/4684049296462116226/comment/megumin1

テスト粒度メソッドアクセス権は独立したものなので、「プライベートメソッドテストすべきか否か」という切り方自体ナンセンスではあるのだが、現実問題としてはアクセス権がテストに影響するので難しい。(twitter/AoiMoe)

private メソッドテストはすべきかどうかというより、「できるべき」であって、それができないというのも、ある種、言語機能テストインピーダンスミスマッチと言えるのではないだろうか、と思っている。(twitter/aetos382)


プライベートメソッドテストがしやす言語での意見

RustやGoではプライベートメソッドに対するテスト簡単にできる。

そのためかプライベートメソッドテストすることに対して拒否反応があまりないようだ。

Rustのテストファイル内とtests/以下の2箇所に書ける。

テストには開発用のホワイトボックステスト仕様確認用のブラックボックステストがあり、前者をファイル内に、後者をtests/に書けば良い。

例えば度々議論になるプライベート関数テストについてはもちろんホワイトボックステスト。(twitter/blackenedgold)

Rustではプライベートに対して何の手間もなくテストが書ける。

概念的にはプライベートに対するテストは外部コードではなく内部コードの一部として見るべきなのだろう。

Rust入門を兼ねてプロジェクト・オイラーの問題を解く - 再帰の反復blog

Rustでprivateなメソッドテストを書きたいなら、そのメソッドのすぐ隣に書けば内部アクセスになるから普通に書けるよ、ってのは目からウロコだった。できるだけ近いところにテストを書こうっていう文化と相まって最高。(twitter/kuy)

Rustみたいに単体テストは同ファイルに書ければいいのに

assertionチックにprivateメソッドのすぐ下にテスト書きたい

ドキュメントにもなるし (twitter/takaya_tim)

Rust のようにユニットテストプロダクションに混ぜる方式はおれもいいと思ってて、テストプロダクションを分離することで private 関数テストができない問題があるけど(テストしたければクラスを分けよ/メソッドを公開せよ/テスト必要なし、に分かれるよね)、そもそもこの議論不要になるよね (twitter/nunulk)


go言語だとプライベートメソッドテスト普通にやりますね。(twitter/mattn_jp)

昨日「private method の単体テストは書くか否か」という話題がちょいとあったのだが、わしは当然書く感じの昨今を送ってきたもんで何で書かんのやくらいに思ってたんだけど、Go だと private なやつのテストが書きやすいってのがデカそう。(twitter/pankona)

golangのテスト書いてたけど、テストプログラム名前空間(パッケージ)が、対象プログラムと一緒で、そのためプライベートメソッドでもテストできるの良い感じ (twitter/74th)

Goテストコードテスト対象と同じパッケージにすればエクスポートしてない関数でもなんでもテストコードから参照できるんだけど、これってプライベートメソッドテストすべきか議論するよりテスト書けと言われているようで好き。(twitter/plan9user)

プライベートメソッドテストするか?」とは別にドキュメントソースコードと同じファイルに書いていい(文芸プログラミング)なら、単体テストテスト対象と同じファイルに書いてもいいのでは?」というのも論点になるかもしれない。

2019-03-12

anond:20190312214546

C++よりSmalltalkっぽくて中二心をくすぐられたんじゃね?

2017-06-07

anond:20170602182759

Javaはすべてにおいてオブジェクト指向強制してないだろ。そう思ってるなら Smalltalk を一度やってみろ。

2016-07-24

ヘルプミー。プログラマ

プログラム書くときって、「Aがしたい」っていう考えから始まると思ってるんですけど、

なんで「Aを行うHogeClientってクラスを作って、次に....」ってする人間がいるんですか?

シンプルに考えるとクラス作らなくてよかないですか?

モジュールで良くないですか?

Simulaとビャーネ、Smalltalkアランが居ない世界にいたかった。

追記

SchemeとCしてました。OCaml齧ります

2016-04-22

プログラミング。好きだけど、さようなら

追記(2015 5/20)

洋食屋ジョブチェンジを果たしました。

---

1年の間、プログラマとして働いていたが、続けていくことが無理だと思い、さようならする話。

プログラマになる前は、コーヒー屋で働いていた。しかし、色々とあり辞め、職業訓練校に通ってプログラミング(php)を学び、60人ほどのソフトウェア開発会社就職した。

会社に入ると、まずC#研修があった。研修と言っても、C#で内製ツールを独りで作るという研修だった。この研修中に「あれ、オレ、プログラム書けねー」と思ったりしたが、研修は終えることができたし、社内の人にも「なかなか良く出来ている」と言ってもらえ、大丈夫だろうと思っていた。

研修が終わり、C#の社内で実際に使われているツールに、機能をいくつか追加する仕事を振られた。前任者にどんな設計になっているのか大雑把に聞き、なんとなくイメージができ、コードを読み始めたのだが、これが全く意味不明で、何のために有るかがわからないクラスが大量にあった。名詞王国だと思った。前任者に、何故このクラスは、この単位で分割されているのか聞くと、「単一責任原則だよ」とか「hogeパターン使うと、後から機能追加しやすいじゃん」というような回答をもらった。納得は出来なかったが、プルリクも承認されて、このツールデプロイされていたので、社内的にも、このコードは、クソコードと言われる物では無いはずだと思ったので、自分プログラムを書き続けていれば、こんな感じの設計に慣れてくるんだろうと思った。モヤモヤは残っていたものの、仕事はしなければいけないので、前任者のコードに習うように、クラスを追加したりして、機能を追加した。プルリクを出すと、設計には何も言われずに、タイポや、テストコードを注意されただけだった。指摘された点を修正すると承認された。振られた仕事は完遂した。が、結局最後まで、モヤモヤは消えなかった。むしろモヤモヤモヤモヤになった。

次に振られた仕事は、内製ツール設計から自分で行い作成する仕事だった。言語Goだった。Goで書いてと言われた時は、以前から自分モヤモヤオブジェクト指向のせいで、モヤモヤしているんじゃないかとも思っていたので、喜んで!という感じであった。が、Goを触ってみると、結局、Go継承の無いオブジェクト指向言語やないかと思った。Goの標準ライブラリinterface名もHogerみたいな感じに接尾辞に-erを持ってくることが慣習らしく、この命名だと、interfaceを満たす構造自身が-erになるので、正にオブジェクトだなぁと思った。巷での「Goオブジェクト指向ではない」というのに期待していたのだが、自分にとっては、とてもオブジェクトしていました。

Goに対する印象は良くなくなったが、ツール設計をしないといけなかったので、Go構造体をC#クラス見立て、前回の前任者のコードのように、単一責任も持つ構造体に(無駄に)分けて、プログラムを書いて、プルリクを出した。自分でクソなコードだと思いながら。だけれどもレビューでは、「errorのチェック忘れ」「標準ライブラリにこの機能ある」「こんな風に書ける」といった感じだった。こんなコードで良いんかよと思ったが、良いらしい。ワケワカメだった。

ここらで、プログラムを書く仕事は、無理だと悟った。現実世界は、自分自然だと思う方法と違う方法で、プログラミングをすることを強要してくる。

ちなみに、仕事ではC#Goを書いていましたが、オブジェクト指向と仲良くなるためにSqueak(Smalltalk)で、オレオレ言語作ってみたりもしましたが、何が嬉しくて、オブジェクト同士のメッセージパッシングプログラムを作るのかわかりませんでした。

Lisp語族言語も触りました。

Clojureは、気持ち良くプログラムを書いていても、Javaが顔を出すところでフラストレーションが溜まってしまって、つらくなりました。

Common Lispは、自分が触った言語の中でも、秀でて良いと思いました。プログラマを辞めても、プログラム書く必要に迫られたらCommon Lispで書こうと思うくらいにです。Land of Lisp楽しいです。あと、CLOS総称関数の考え方が大好きです。

最後に、この投稿は、一種の決別の表明です。いつまでも自分に向いていなかったことに、時間を掛けてしまっている自分との決別です。

最後まで読んでいただきありがとうございました。

自分共感をもった参考リンク

2015-02-26

関数型言語使ってる時の気持ちよさは、ベーシックべた書きの頃と同じ

ひょっとすると、これはべたべたな一直線の手続き書き時代以来の「全てが一直線に並ぶ気持ちよさ」なのかもなぁ、と思った。

Haskellなんかを書いてると、究極的に、関数型言語におけるプログラムとは、一引数関数の深い深い一直線の入れ子みたいに感じられる。

(いやまぁ、タプルとかもあるけど、原則的に)

構造化⇒OOPと来て、プログラミング言語Go to hellを廃し、色んな物をDRYに書けるように進化してきたけど、その結果色々なものが並列にばらばらっと並んでいる感じになった。

OOP大本smalltalkメッセージパッシング原則の時点で、対等な二つの並列に並んだオブジェクトのやりとりがベースになっている。

勿論オブジェクトは大体内部に別のオブジェクトを抱えていたりして、親子関係があるのは普通だけれど、子同士はやはり並列に順序なく並んでいる。

この並列性のおかげで、例えばそれこそメッセージパッシングをそのまま引き継ぐErlangなんかは、高いスケーラビリティと耐久性を持つわけで、これ自体は素晴らしい発明だ。

ただ、やっぱり並列なヤツラが、ごちゃごちゃっと同時にあって、そいつらが同時にガチャガチャなんかやってたら、神の見えざる手的に、なんとなく全てが上手く噛み合って、プログラムが動きます、って、これどうしても全体像を把握しにくい。

人間脳みそって、そんな同時並列のものを把握できるようには、出来ていないんだと思う。

上手く動いてはいるんだけど、何で上手く行ってるのか分かるんだけど、分かりにくい。

この気持ち悪さが、今日もどこかのITおじさんを全部staticな書き方に走らせ、OOPわかんねー、と首をかしげながら、何となく使ってる人達の心を、巨大なメソッド作りに導いているのではないかな、と。

なんてったって、Scalaなら並列処理でさえ、モナドなFutureで事実上直線に繋いでいってかいちゃう(Akkaもあるけどあれはオブジェクティブな側面なので)わけで、これは凄く懐かし気持ちいいと思う。

かくして関数型言語は「なんかとにかくきもちいいぃぃぃぃ」な信者を量産している。そしてOOP派との間に、意味分からん溝だけが広がっていく。

2013-03-09

Pythonと他言語比較

2012-06-29

どのプログラミング言語が最も美しいか

■ C

for( const char *s="12345"; *s; ++s ) if( '2'<*s&&*s<'5' ) printf( "%d", (*s-'0')*2 );

JavaScript

console.log([1,2,3,4,5].filter(function (i){ return (i > 2 && i < 5 ); }).map(function(i){ return 2 * i; }));

Python

print(map(lambda x: x*2, filter(lambda x: x>2 and x<5, [1,2,3,4,5])))

Ruby

puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2}

C#

new{}{ 1,2,3,4,5 }.Where(x => 2 < x && x < 5).Select(x => x*2);

Common Lisp

(print (loop for x in '(1 2 3 4 5) if (< 2 x 5) collect (* x 2)))

Haskell

print [x*2| x <-[1,2,3,4,5], x > 2, x < 5]

■ J

  1. :(((>&2)*.(<&5)) a) # a=:1+i.5

■ R

print((function(){x<-c(1,2,3,4,5);x[2<x&x<5]*2})())</p>

Clojure

(print (for [x [1,2,3,4,5] :when (< 2 x 5)] (* x 2)))

Squeak Smalltalk

(1 to: 5) select: [:x | x between: 3 and: 4] thenCollect: [:x | x * 2]

2012-05-18

ハッカーVimを使う」 騙される若者たちなのか

Eclipseemacsvimより優れている点を挙げてみよう。

 

 

リファクタリング機能が強力 →本当か

CVSリポジトリの構成を直接覗ける →redmineとかを使ったほうがいいんじゃないのか

デバッガグラフィカル → それ、うれしいか

・設定できる警告メッセージの種類が豊富。→警告そんなにいるのか

復元機能が非常に充実している。 →バージョン管理ソフトがあれば普通だし

 CVSのように以前の状態に復元すること、以前の状態の →diffじゃダメか、というかなんでいまどきCVSなの

 ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能存在する。

プラグインの数が豊富、膨大。 → 数があってもつかえるのは少ない

プラグイン開発環境Eclipse自体に用意されている。 →開発環境を使って作る程のものでもなく、バッチファイルとかスクリプトでよくね

ライセンス形態CPLであり商用利用もしやすい。 →eclipse組み込んで出荷するの?

・上位版にWSADが存在する。 →WSDADってなに、WebSpereの残骸?

IBMバックアップがついている。→それは何か役に立つの

Smalltalkで有名なVisualworksの影響を受けているため、

JUnitプラグイン(Eclipse標準装備)によるテストファーストリファクタリングの他、eXtreme Programming環境が充実している。→Jenkinsのほうがよくね

SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力!→コマンドラインから実行するsvnコマンドを覚えておくとはターゲットでも動いて便利だよ

・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ!→スタック見るだけのことじゃないの

プラグインによってはURLを指定するだけでプラグイン自動ダウンロード自動インストール

自動アップデートができるためプラグインインストールが非常に容易。→勝手に変わったら怖くない

Eclipseから直接Tomcat, JBossなどを再起動できるSysdeoプラグインJBoss-IDEプラグイン

 という強力なプラグインが充実している。→えー、今頃Tomcat

EclipseUML Omondoプラグインによりクラス図などを書いたり、

 UMLによるModel Driven Architecture, リバースエンジニアリング

 などを即座に実現できる。→これは何だかからない

RSSリーダープラグインMP3プラグインAll The Newsプラグイン

など様々なプラグインが充実している。→それ開発ツールじゃなくて携帯でやったほうがよくね

PHP開発が可能なTruStudioプラグインPerl開発が可能なPerl E.P.I.C. プラグイン

C/C++開発が可能なCDTプラグインAspectJ開発が可能なAJDTプラグインなど

言語プラグインが充実している。→Java以外は所詮おまけだけどね

・そのほかにD言語プラグインC#プラグインPythonプラグインJavaScriptEditorプラグイン

CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン

Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン

ゲームができるプラグイン、メーラとしてつかえるプラグインWikiプラグインHibernateプラグイン

FindBugsプラグインCheckStyleプラグイン、JalopyプラグインSobalipseプラグインソロプログラマープラグイン

など様々なプラグインが充実している。→それぞれ単機能ソフトのほうが充実してるんじゃないの

 

 

どうしてもeclipseというなら止めないけど

2012-02-17

ハッカーVimを使う」 騙される若者たち

Eclipseemacsvimより優れている点を挙げてみよう。

 

 

リファクタリング機能が強力

CVSリポジトリの構成を直接覗ける

デバッガグラフィカル

・設定できる警告メッセージの種類が豊富

復元機能が非常に充実している。

 CVSのように以前の状態に復元すること、以前の状態の

 ソースコードとの比較も容易。CVS(Eclipse標準装備)/Subversionプラグインにもこの機能存在する。

プラグインの数が豊富、膨大。

プラグイン開発環境Eclipse自体に用意されている。

ライセンス形態CPLであり商用利用もしやすい。

・上位版にWSADが存在する。

IBMバックアップがついている。

Smalltalkで有名なVisualworksの影響を受けているため、

JUnitプラグイン(Eclipse標準装備)によるテストファーストリファクタリングの他、eXtreme Programming環境が充実している。

SubclipseプラグインによりSubversionにも対応できる。これはCVSよりも強力!

・Call Hierarchyプラグイン(Eclipse3.0から標準装備)によりメソッドの呼び出し階層を調べることができる。この機能は強力だ!

プラグインによってはURLを指定するだけでプラグイン自動ダウンロード自動インストール

自動アップデートができるためプラグインインストールが非常に容易。

Eclipseから直接Tomcat, JBossなどを再起動できるSysdeoプラグインJBoss-IDEプラグイン

 という強力なプラグインが充実している。

EclipseUML Omondoプラグインによりクラス図などを書いたり、

 UMLによるModel Driven Architecture, リバースエンジニアリング

 などを即座に実現できる。

RSSリーダープラグインMP3プラグインAll The Newsプラグイン

など様々なプラグインが充実している。

PHP開発が可能なTruStudioプラグインPerl開発が可能なPerl E.P.I.C. プラグイン

C/C++開発が可能なCDTプラグインAspectJ開発が可能なAJDTプラグインなど

言語プラグインが充実している。

・そのほかにD言語プラグインC#プラグインPythonプラグイン、JavaScriptEditorプラグイン

CSSプラグイン, HTMLプラグイン, XMLプラグイン、(Jakarta)Velocity UIプラグイン

Apache Antプラグイン(Eclipse標準装備)、非常に強力なApache Mavenを使うことができるプラグイン

ゲームができるプラグイン、メーラとしてつかえるプラグインWikiプラグインHibernateプラグイン

FindBugsプラグインCheckStyleプラグイン、JalopyプラグインSobalipseプラグインソロプログラマープラグイン

など様々なプラグインが充実している。

 

 

以上、老害に騙されずにEclipseを使いましょう。

2008-10-02

Classic Texts in Computer Science

リブログです。

    http://www.zafar.se/bkz/Articles/ClassicCompScienceTexts

    http://www.zafar.se/bkz/wiki/view/43bafac8c8570f4f

    にあったけど、無くなっていたので

    http://web.archive.org/web/20060823143349/www.zafar.se/bkz/home/classictextsincomputersc.html

    から拾ってきた。

    でも書いてる途中に↓を見つけてしまったのでした。

    Classical Computer Science Texts

    2008-08-07

    それは Smalltalk ではブロック変数宣言ではないよ

    おそらく Smalltalk のテンポラリ変数の宣言(Ruby では不要)のほうを模したものじゃないかな。

    ブロック変数の宣言については、Ruby

    { |x,y| ... }
    

    に相当するのは Smalltalk ではこう。

    [:x :y | ... ]
    

    縦棒を使うっちゃあ使うけどね。

    2008-07-24

    javascript って java を真似たはずなんだけど、どっちかというと smalltalk

    ログイン ユーザー登録
    ようこそ ゲスト さん