[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2chのread.cgiへ]
Update time : 10/07 16:29 / Filesize : 229 KB / Number-of Response : 1002
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Objective-C



1 名前:デフォルトの名無しさん mailto:sage [05/01/29 16:18:12 ]
ほんとプログラマにとってはMacって
本当に興味が無いOSだよねw

Macでの標準的な言語であるObjective Cのスレすら無いし。
過去にはあったんだろうけど。

932 名前:デフォルトの名無しさん [2007/05/14(月) 11:33:35 ]
Objective-Cのオブジェクトシステムの部分はSmalltalkの影響を受けているわけで、
そのSmalltalkはLispの影響を受けているので、括弧が多くなるのはそういう理由からでしょう。

933 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 12:01:36 ]
ふーん

934 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 12:37:10 ]
>>932
すごい三段論法だな。w
というか、どうして lisp や smalltalk をろくに知りもしないのに
そういう見てきたような嘘をつくかなー。

objc が smalltalk の影響を受けているのは [ ] の中だけ。
というか、objc の [ ] の中は、smalltalk の世界。
objc は smalltalk のコードを C コンパイラに通すためのプリプロセッサとして
開発された経緯がある。そんなわけで、[ ] のネストの多さは objc の勝手な事情で
smalltalk とは無関係だよ。

あと、smalltalk への lisp からの影響は、everything is an object のポリシーや
クロージャ、ブロッククロージャメソッドのたぐいで、
S 式(つまりこの文脈でいうところの括弧の多さ)じゃあない。

ちなみに残念ながら objc は、これら(lisp からの影響)の恩恵の外にある。
メタクラスやメソッドはオブジェクトじゃないし、ブロッククロージャメソッドはおろか、
ブロック(クロージャ)すら使えない。これらは objc の言語拡張のやりにくさや
イントロスペクションの貧弱さ、コレクションの扱いにくさとして出てくる。

935 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 14:19:56 ]
ま〜たそんなマジレスしちゃって。

936 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 14:53:23 ]
>>934 がマジレスしてくれなかったら俺がマジレスする所だったわ
危ない危ない…

937 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 16:53:09 ]
>>934
> ブロック(クロージャ)すら使えな
使える処理系もあるけどね。

938 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 19:43:36 ]
poc poc チーン

939 名前:デフォルトの名無しさん [2007/05/14(月) 21:09:12 ]
説明していただきありがとうございました。
おかげでOjective-Cの勉強を諦めることが出来ました。
感謝します。

940 名前:デフォルトの名無しさん mailto:sage [2007/05/14(月) 21:24:24 ]
まだ ObjC にクロージャ入らないんだっけ?



941 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:01:30 ]
クロージャを入れるのは一苦労じゃけん

942 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:05:46 ]
ふーん

943 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:29:33 ]
そこでRubyですよ

944 名前:デフォルトの名無しさん [2007/05/15(火) 00:52:11 ]
Objective-Cやっている人はそれがC++よりも優れていると思う?
それともMacについてきたからやっているの?

945 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 00:59:06 ]
優れているところもあるし劣っているところもある
ちなみにMacOSXについてるのは
Objective-C じゃなくて Objective-C++ だから

946 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 02:34:24 ]
> ちなみにMacOSXについてるのは
> Objective-C じゃなくて Objective-C++ だから

ちがいます

947 名前:デフォルトの名無しさん mailto:sage [2007/05/15(火) 16:14:25 ]
>>944
C++より先にObjCを学んだからC++使ってると違和感を感じることがある。
多分C++が先な人は逆なんだろうけど。

948 名前:デフォルトの名無しさん mailto:sage [2007/05/16(水) 19:40:39 ]
俺はどうもC++の変数の型の縛りが苦手だなあ。
virtualとか、何種類もあるキャストとか...

そんなわけで最近はruby。Cocoaも呼べるし。

949 名前:デフォルトの名無しさん mailto:sage [2007/05/16(水) 22:01:25 ]
使いやすいのでいいんじゃない

950 名前:デフォルトの名無しさん mailto:sage [2007/07/01(日) 21:02:32 ]
ほしゅ



951 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 04:34:52 ]
ttp://ja.doukaku.org/lang/objectivec/

952 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 09:40:00 ]
>>947
先にC++だったけどC++使ってると違和感を感じる
やっぱりObjective-Cの方がいいよ


953 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 09:50:28 ]
>先にC++だったけどC++使ってると違和感を感じる

これって、MFCじゃね?
MFCとCocoaを比較したらCocoaがマシかもしれない。
でもMFCのトンデモ設計とちょーサイアクGUIビルダーよりましといった事に意味は無い。

954 名前:デフォルトの名無しさん mailto:sage [2007/07/19(木) 22:22:06 ]
何で C++ == MFC だと思ったのかな?

955 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 02:14:36 ]
かな?

956 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 08:50:11 ]
だって、C++Builderなんて使ったらCocoaの変にIDEにコントロールされて
逆にMVCを開発者側が制御できない変なもの使ってられないよ。
MVCを変に制御して困るものでC++といえばMFC。

957 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 09:52:47 ]
どっからMVCなんて出てきたんだか。

958 名前:デフォルトの名無しさん mailto:sage [2007/07/20(金) 10:20:20 ]
ttp://developer.apple.com/jp/documentation/cocoa/Conceptual/CocoaBindings/Concepts/WhatAreBindings.html#//apple_ref/doc/uid/20002372/175802

959 名前:デフォルトの名無しさん mailto:sage [2007/07/27(金) 20:00:51 ]
日本語でok って言うトコロなんだと思う

960 名前:デフォルトの名無しさん mailto:sage [2007/08/06(月) 11:22:30 ]
プロトコルと抽象クラスってどういう風に使い分ければ良いのよ



961 名前:デフォルトの名無しさん mailto:sage [2007/08/06(月) 12:07:29 ]
Objective-C 2.0 には抽象クラスがあるの?

962 名前:デフォルトの名無しさん mailto:sage [2007/08/06(月) 12:32:23 ]
いや、言語仕様にはないけどさ…

963 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 10:38:33 ]
どっちも使わない。ふつうは informal protocol というか単にセレクタの名前を取り決めておくだけ

964 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 11:05:51 ]
もうObjective-C廃止にしない?

Mac OS XとC++でポトペタ開発しようよ。

965 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 11:14:55 ]
C++なんてクソ言語使ってられるかっつーの

966 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 12:01:59 ]
というか Interface Builder はポトペタの元祖なのでは?まあ癖はあるような気がするけど。バインディング可なパレットきちんと作っておくと殆ど IB だけで出来るべ

967 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 12:07:23 ]
出来るってだけで、GUIの凝ったコントロールを作る事が不可能だお。

968 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 12:49:00 ]
ポトペタってなんですか><
インターフェースビルダーよりどこが凄いのか押しえて下さい!!!!

969 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 13:03:28 ]
コンポーネントを派生して、差分コーディングで処理を足して、画面に"ポトペタ"貼る事でつよ。
他人のハイパーなコンポーネント使ったり、ネットに派生コンポーネントが溢れたりするお。

970 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 13:16:29 ]
それはまさに IB でパレットから D&D して、カスタムクラスを設定することだとおもうんだけど、どっか違うの?
Apple が提供してる以外の新規パレット自体をつくることもできるよ。
www.bignerdranch.com/palettes/

確かにネット上にカスタムパレットが溢れてはいないが ...



971 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 13:26:51 ]
派生前クラスのソースコードって公開されてる?
やっぱ、クラス派生する場合にはそれが無いとスゲー足かせだお。

972 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:07:21 ]
というか、Cocoa のプログラミングは
1) view はパレットから D&D してカスタムクラス
2) controller も最近はバインディング用のをパレットから D&D
3) model は手で書いても良いし、CoreData でも良い
だとおもうんだけど。

Apple 提供のパレットはソースコードは流石にないよ。でもドキュメントは(英語なら)完備してる。まあ GNUStep が 8割方再実装してるから読みたけりゃよめばいいけど。

ネットにころがってるのは、そもそも数が少ないけども、ころがってるやつはソースも配ってると思うよ

あと、Objective-C はカスタムクラスが面倒だったら、元クラスのソースコードもってなくても元クラスにメソッドを追加できるよ。これは非常に便利。

973 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:12:17 ]
>1) view はパレットから D&D してカスタムクラス

やっぱ、そうだよね。

プロジェクトと強く結びついたカスタムクラスであって、
クラスライブラリのベースクラスが派生したハイパークラスで溢れる、
というイメージじゃないだよね。

974 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:21:49 ]
別にプロジェクトと強く結びついてんくても良いんだけど。

975 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:25:37 ]
まあハイパークラスなんて配られてないからね。
Apple 謹製の NSTextView, WebView は充分 Hyper な気がするけど。

あと、Cocoa ではクラス派生をする前に大抵の処理は delegate で済む気もする。
(コントローラが標準 view の機能を拡張できるみたいなかんじ)

ポトペタでハイパーなコンポーネントののってるページの例をなんか URL おしえてください

976 名前:デフォルトの名無しさん mailto:sage [2007/08/07(火) 14:33:25 ]
ttp://hp.vector.co.jp/authors/VA015730/vcl/vclworld.html
ttp://norg1964.hp.infoseek.co.jp/delphianworld/

977 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 00:43:11 ]
o ひとつめの URL にあがってるような機能は Cocoa /Carbon API にある気がする
o ふたつめのにはいっぱいカスタム GUI コントロールがのってるけど、
あんまり Apple はカスタムコントロールをつくるのは推奨してない気がするし、
そういうことすると OS X ぽくないソフトになりがちで嫌われがちだと思われる

978 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 00:45:43 ]
shiira.jp/hmblkappkit/

こういうカッコいいコントロールもあるよ。まあ Apple がまだ公開してない API を再実装した奴だけど、Interface Builder でふつうに配置してクラスの名前をこれにかえるだけで使える

979 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 01:38:51 ]
MacのプロアプリのようなUIにしたければカスタムするしかないよね。
スライダーとか機能的にも不十分だしIBにあるパーツだけじゃ足りなくなってきたからパーツの作り方勉強しなきゃ。

980 名前:・∀・)っ-○◎● mailto:sage [2007/08/08(水) 02:12:08 ]
リストボックスをオーナーデータ化するにはどーすりゃいいんだ?



981 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 08:48:20 ]
>あんまり Apple はカスタムコントロールをつくるのは推奨してない気がするし、

これが今の時代の開発ではネック。

>そういうことすると OS X ぽくないソフトになりがちで嫌われがちだと思われる

だからコントロールを派生して元々OS Xの描画の上に描画を足したり処理を足したりするわけじゃん。

982 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 11:16:36 ]
>>979
ProKitでなんとかなるかもしれないけど。

983 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 11:40:52 ]
>>981
まあ確かに、機能豊富で、ちゃんと Cocoa の window にマッチするパレット集が一杯おちてたら便利だろうね。
もうちっとデヴェロッパ層が厚くならないとだめかな。

984 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:11:56 ]
ええと、そろそろCocoaスレに行ってくれません?

985 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:20:11 ]
>>978
この黒パネルはLeopardのIBで実装されてる。

986 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:25:15 ]
次スレ
pc11.2ch.net/test/read.cgi/tech/1186543111/

987 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:29:14 ]
>>984
Cocoa の話が駄目とすると GNUStep も駄目?

988 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 12:37:22 ]
漢は黙って objc/Object.h をインポート

989 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 13:39:09 ]
>987
AppleがCocoaで新たに組み込んだ関係がうぜ〜って事じゃね?
IBの話すんならGORMの話しろや!ってきっといいたいに違いないと思ってるのだが(w

あ,クラスライブラリはどうでもいい言語そのものの話をしたいって人だったのかも>984

990 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 14:22:59 ]
OOP言語ならクラスライブラリと切り離して話できんわ。



991 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 15:24:09 ]
そこでObjective-C標準クラスであるObjectを…

992 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 18:27:56 ]
Object.hと同じディレクトリにList.hってのもあるんだけど、
ListもObjective-Cの標準クラス?

993 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:29:02 ]
純粋に Objective-C の話ってなかなか難しいのでは ...
Apple の独自拡張も多いし。

Object と NSObject がどっちが「標準」かというと、
一社/一グループの実装だけじゃなくて、
標準を定めた文書が別個に存在するかという意味では
Openstep のほうが「標準化」されているのではないかと思わなくもない

GCC もせめて GNUStep の non-GUI 部分を一緒に配布してくれればいいのに。

994 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:38:23 ]
基本Java厨で、現在C++で食っていきながら、
Rubyが一番好きかも知れないという俺ですが、
Objective-Cに興味を持っています。
他のOOPLとくらべてどうでしょうか。
メリットとかデメリットとか。

995 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:44:25 ]
実際に運用する上で言語使用だけを他の OOPL とくらべるのは難しい...
Cocoa つかうぶんには非常に便利ですよ。
RubyCocoa も Leopard から標準になるので Ruby が
いいならそれでいいけれども、API の仕組みはかなり Objective-C に影響されているので、
RubyCocoa を使うための基礎として Obj-C を学ぶのは悪くないと思う

GNUStep はちゃんとつかったことがないのですいません

C++ を知っているひとのための、C++ と Obj-C の文法の比較は
ktd.club.fr/programmation/fichiers/cpp-objc-en.pdf
が簡単にまとまってる。英語だけど。

996 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:49:00 ]
>>994
CとJavaが使えるなら30分で覚えられるからとりあえず使ってみれ

997 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:51:58 ]
ご丁寧にどうもありがとうございます!!
Cocoa使ってウハウハにも興味はあるんです。
Win32でどうのこうのに飽きちゃってですね。
言語としても興味津々なんでリンク先熟読します。

998 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:52:59 ]
>>996 やってみます!

で、998ゲットォ!!

999 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 22:55:59 ]
そういう興味のある人なら Apple のこのあたり

Objective-C Language
developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/index.html

Cocoa Fundamentals Guide
developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/index.html

が面白いかも。あと他にもいっぱいあるよ:
developer.apple.com/documentation/Cocoa/index-date.html

いや、GNUStep にリンクはらんで済まんね ...

1000 名前:デフォルトの名無しさん mailto:sage [2007/08/08(水) 23:03:19 ]
次スレ立てました
Objective-C Part3
pc11.2ch.net/test/read.cgi/tech/1186581730/
次スレでもみんなよろしく〜



1001 名前:1001 [Over 1000 Thread]
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<229KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef