Java VS PHP
■ このスレッドは過去ログ倉庫に格納されています
>>200
arrayObject使ってメソッド実装すればいい
つうかそんな事OOPの本質と関係ない >つうかそんな事OOPの本質と関係ない
やっぱり本質的に関係あるよ。
関数名の先頭にオブジェクト名がついてるようなオブジェクト指向言語はIQ不足だ。
Javaで
StringBuffer sb = new StringBuffer();
sb.stringbuffer_append();
だと冗長なので
sb.append();
となっている。
コーディング上意味が重複するものが発生しないようにすべきなのだ。
OOP化したならPHPの関数のaからzまでまるごと先頭の単語はムダだ。
>>203
だから202は「arrayObject使ってメソッド実装すればいい」と言ってるじゃないか このスレに限らす変数なんでもオブジェクトがオブジェクト指向と思ってるやつがいるよな
まずはWikiでOOP読め >>205
WikiでOOPで見たら
オブジェクト指向プログラミング
があったがそのページにはPHPがのってなかった。
やっぱなんちゃってのまがいものだから載せるにはためらいを感じたんだろう。
>>208
3回読んだ。
ようするに純粋なOOP言語にJavaは含まれるがPHPは論外であり
Perlより下の扱いというか圏外。
邪道、外道、ハリボテ、バッタモンである。
OOPが出来ない言語はPerl以下の言語である。
何それ?
209の考え方の方が邪道、外道、ハリボテ、バッタモンじゃん >>209
理由書いてみ
変数ネタはもう飽きたから違うのな print()<---C
とか
echo <-----shell
とか他の言語体系からパクって来てるの、恥ずかしくないのかな。
print_r("件数は$kennsuuです");
は
print_r("件数は".$kennsuu."です");
にしてくれんかな〜〜違和感がある。
風船騒ぎの子供みたいなのがPHP作ったんじゃないかな。
array は文字通り見たら配列でしょ。
ところがこれが「連想配列」でJavaのMapみたいなもの。
自然言語のイメージと食い違っていて誤解を生じる。
Mapと配列は分けてくれ。
配列の発展形として当然Listクラスくらいないと困るけどないらしい。
ボロボロなのでは?書いてて苦痛じゃないですか?
>>213
JavaのListにはキーがない。ただオブジェクトが並べて入っている。
キーを使わないで並びのオフセット値で取り出したり入れ替えたりするのに使う。PHPではできない。
PHPのlist()はarray()からキーで取った値を取り出す。キーなんかつけるなよ!
PHP作者はMapとListと配列が頭の中でカオス状態になっている。もっと頭脳明晰じゃないと言語作る資格がない。
>キーを使わないで並びのオフセット値で取り出したり入れ替えたりするのに使う。PHPではできない。
PHPでもキーを指定しなければ並び順になるのでは?
>PHPのlist()はarray()からキーで取った値を取り出す。
よく分からない。list関数にキーは関係ないと思うが。 >PHPでもキーを指定しなければ並び順になるのでは?
だからね〜そもそもarrayにキーの概念が混じってるのがトンチンカンなの。
>PHPのlist()はarray()からキーで取った値を取り出す。
よく分からない。list関数にキーは関係ないと思うが。
http://www.scollabo.com/banban/php/php_05.html
<?php
$fruit = array("Apple" => "りんご", "Orange" => "みかん",
"Grape" => "ぶどう");
while(list ($key, $val) = each($fruit)) {
print ("インデックスの $key は、$val です<br>\n");
}
?>
という例文見た時ヘンだと思った。諸悪の根源はPHPを最初に作ったとき「配列」と「Map」がarray()でごちゃ混ぜになっていて
別クラスになっていなかったことだ。この区別をしないのはおバカだろう。
区別をしないようにしたのは意図的だろう。
その判断が正解だったかはどうかは別として。
だんだん厳密な方向に進んでいるから、最初の作者も今は後悔しているかもしらん。 後悔というより選択肢を増やしてるだけだ
PHPはスカラー値の宣言が無いのを見てもわかる。これは意図的なものだ。そして今時でもある。
多態性を持たせるために可能な限り型を区別しないのだ。
昔は変数名に型名をつけてたりしたのを知らないか?
OOP以前は型を厳密に区別するのが保守性や生産性に優れてると考えられてたんだ。 >昔は変数名に型名をつけてたりしたのを知らないか?
OOP以前は型を厳密に区別するのが保守性や生産性に優れてると考えられてたんだ。
これは異なことをおっしゃる!
今も昔も将来もOOPは型に厳密なのが本筋ですよ!C++は特にそう。Javaもそう。
型を動的にしたOOPはRubyがあるけど。
型の扱いがユルイのはコーディングのミスと実行時エラーのもと。
>>217
216だけど
>だからね〜そもそもarrayにキーの概念が混じってるのがトンチンカンなの。
なんで?arrayにキーの概念が混じっているとなんでだめなの?
215で「PHPではできない」と言ったことに対して「できるよ」と言ったのにさっきから話題逸らしてるよね。
>という例文見た時ヘンだと思った。
これも意味がわからない。ただの主観で語ってるじゃないか。
別にヘンだと思わないで使っている人が多数。
どの辺がヘンなの?
別に古い考え方に凝り固まっている人と評価して切り捨てたりはしないけど
せめて論理的に主張できなくちゃ説得力がないと思いますよ なにかを正しいと思い込んで、 まったく関係ない別の事柄にも
ソレを望むなど、気がふれてるとしか思えない。 >>221,222
PHPを否定する理由は前にも書いたが
異なる概念は異なるものとしてハッキリと識別すべきであるにもかかわらず
PHP作者はMapとListと配列が頭の中でカオス状態になっている
ということ。
list()は最初リストを作る関数のように思ったが、arrayの中身を取り出すものだったらしい。
こういう関数のネーミングもヘンだ。PHP作者が英語話せるかどうかが疑問だ。
おっとヘンというと主観になるのか〜。「不適切」と言い換えよう。
おっと、EcmaScriptを悪く言うのはそこまでだ。 >>223
すべきであるにもかかわらずというところから。
まず、なぜ異なるものと識別すべきと思うのでしょうか。 ID:xxwa2wCTみたいな低レベルの独りよがり(でも自分はできるみたいな書き方をする)が、
批判に混じるからややこしくなるんだな。 >>224
EcmaScriptについては何も言ってないよ。JavaScriptのことは「これでよい」と思う。
>>225
三角形と四角形と円くらいの違いがあれば区別するのが自然。
>>227
なんで 三角形と四角形を 区別するのが自然なんですか?
一緒にする体系が存在することがそんなに問題ですか? >>228
Mapはキーで値とかオブジェクトにアクセスする。
Listと配列はオフセットでアクセスする。
Map(arrayを連想配列で使う場合)はキーは違ってないといけないし1つのキーに対する値は1つ。
Listと配列は要素として全く同じものが入っていてもかまわない。
Listは要素が可変だが配列は要素数が固定。
こんなに違うのを一緒くたにすると使えなくなる。
>>223
>異なる概念は異なるものとしてハッキリと識別すべきであるにもかかわらず
それはJava脳
>こういう関数のネーミングもヘンだ
これもJava脳 それは静的型付け言語だから
コンパイラに向いてるがPGが喜ぶ話ではない。
配列の個数を言語レベルで制限して生産性や保守性が上がるシーンは限られてる
その3つをはん化して区別なく使えるようにした方がより使いやすい。
PHPの配列が弱かったのはそんな事でなくオブジェクトとしての振る舞いが出来なかった事だ。
だがそれはもう解消されイテレータも持てるようになった。 >>121
Pythonの先祖は教育用だったが
Python自体は教育用に設計されたわけじゃない。
毎度のことながらWikipediaは間違いだらけだ。 >>229
また元に戻ったな。一緒にしたわけでもないんだから、その論は通らないよ。 プログラマーにとっては
$記号がついてないと変数と認識できないようなへぼい解析しかできない処理系は
カンベンしてもらいたい。
数学の式において変数にはアルファベットしかない。
$が氾濫してると見た目が醜悪で可読性が下がる。抽象性が下がって本質が見えなくなる。
ドッグフードばかり食ってるとフランス料理がまずいと感じるようになる。
>>232
当たり前のように使いにくい言語扱いされてんだな >>235
$一つ押したらIDEがそのスコープの変数全てをリストしてくれる。極楽じゃないか?
置換も楽だ。 全然大変じゃない
最低限の設定がいるだけ
つうか"無い"は嘘だろ Java版Ruby on Railsと呼ぶにふさわしいフレームワークが出たぞー
「Play framework 1.0」
http://www.playframework.org/
動画を見ると非常にすばらしい
モデル、ビュー、コントローラーの変更がリアルタイムに反映させる。
>>245
携帯電話のNOKIAのスマートフォンのOSはシンビアンだ(個人的には嫌いだ)が
これはC++でコーディングする。
iPhoneもC++、GooglePhoneはJava。
速くて資源を節約する(軽い)ためこの言語を採用した。型にうるさい。
型にうるさいのは「冗長」とは言わないよ。
速く軽くするための必然だ。
型がゆるいのは重くて遅い。物理的にそうなる。
クラスで変数メンバーを持っているときPHPは
$this->hensuu = 1;
と書かないといけない。
Javaでは
hensuu = 1;
でよい。どっちが冗長だろうか。
同名のローカルがある場合は、this.hensuu だろ? 読むとき分かりやすいのはどっちだろうね。 >>249
http://www.scollabo.com/banban/php/php_11.html
の例を見ると同名のローカル変数がないけど$this->
になっている。例が間違っているのか、そうでないのかどっちだろう。
$thisを撃つ必要があるかないかって本質的な問題?
それを言ったら、JavaでWebページを出力する時とか、ファイルの入出力する時とか、DBに接続する時とか、それはもう・・・ >>250
それPHP this.hensuu は JAVA >>246
ライトウエイト言語って速度が速くてライトって意味じゃないぞ…
LL知ってるか? PHPはだいぶJavaの仕様を取り入れている、PHP6.0ではもっと近づく。
PHPは簡単だ軽い何て始めた人達も結局プログラミングの知識や
テクニックが必要になるのはもう分かり切っている。
>>251
>$thisを撃つ必要があるかないかって本質的な問題?
それを言ったら、JavaでWebページを出力する時とか、ファイルの入出力する時とか、DBに接続する時とか、それはもう・・・
Javaではローカルかパラメータで同名がある場合以外はthisはいらない。
Webページ出力、ファイル入出力、DB接続もthisの出番があるとは思えない。StrutsのFormのことならそれはJavaの責任ではなくStrutsの責任。Strutsを改造すればよい。
http://www.php.net/manual/ja/language.oop5.basic.php
関数のコールにもthisが必要なのか。タイピング量が増えて疲れる。
>>255
幅が持てるってのがポイントだ
仕様増えた文の学習を強要されるわけじゃない。レンサバから数万台のクラスターまで対応できる言語になったのだ。 >>257
昔のコードをPHP5.3で動かすとdeprecatedだらけになる。
PHP6になったら動かなくなるぞぉぞぉー
なんくるないさ >>258
そりゃそのためのdeprecatedだろ PHP諸君
Eclipse+Javaで行きたまえ。
Javaがタイプ量が多すぎると思っている諸君は、
Eclipseのコード補完に驚くだろう。
Javaの世界では、だれも今時、しこしこ秀丸やvim等のエディターでコードを
書くやつはいない。PHP諸君の間ではいまだに結構いると思うが...
>>260
逆だ。
そういうのないとやってられんだけだろ。 >>261
PHP使いもだいぶEclipseやNetbeansを使い始めているぞ。
Zend Studioも結構いるが何しろ有料で高いからな。
>>261
あれだ、コマンド一発で大量の設定ファイル、下書きコードが自動で作成されます。でそれを便利だとありがたがってるやつ
最初がそもそもおかしいからそういうのがいるようになる。前提が不便すぎるのだ。 >>263
あれだ、コマンド一発で大量の設定ファイル、下書きコードが自動で作成されます。でそれを便利だとありがたがってるやつ
そういうのがJavaのフレームワークにはありがちだ。そういうのは確かによくない。
hibernateはクソだ。
しかしそれはJavaの責任ではない。そういうフレームワークを使わなければいいのだ。
Servletベースにすれば大量の設定ファイルは必要ない。server.xmlとweb.xmlだけくらいだ。
(これはWebサーバー使う限りどの言語でも必要だ。)
>>263
PHPのクラスも同じだよ。
PHPを使う人達にはクラスを使う事が浸透していなだけ。
ま、関数いっぱい用意されてるしクラス化する必要性がまずないからな >>266
cakePHPにしろsymfonyにしろフレームワークを使うとなると、
必要になるんじゃないのかなーーー?
まだ使っていないと思うけど PEARのコード見てみ〜。
言語的に不十分なPHP4であれだけきっちり書いてる。
ZSは更にちゃんとしてる >>269
PHPのバージョンアップの流れを考えろや。
これからはフレームワークが必須だろうが。
>>262
cakePHP + NetBeansで快適さ
Eclipse(PDT)よりコード補完がベターだ
フレームワークがライブラリを置き換えるものではない。
CAKE別にいいと思うがあんな密結合でスケールアウト出来ないのは"これから"じゃないと思うぞ。PHP4でOOPとは言い難いし。書きなぐり用ならOK >>244
スクリーンキャストを見たけど、確かにシンプルだね
いわばJava版LL風WEBフレームワークといった感じ。
ちょっとマニュアルを見て見たがcakePHPに似ている。
StrutsでもじゅうぶんLLだとおもうが。
どこが難しいのかさっぱりわからん。
LLの意味は日本と英語圏ではまったく逆。
http://ja.wikipedia.org/wiki/%E8%BB%BD%E9%87%8F%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E8%A8%80%E8%AA%9E
>英語圏におけるLightweight languages
英語版Wikipediaによれば、Lightweight Languagesは
計算機リソースを多くは消費しないという意味で軽量(Lightweight)であり、
C言語などが例としてあげられている。
つまり、プログラマ負担の軽い言語を意味しない。
よって、日本における軽量プログラミング言語(Lightweight Languages)と
欧米におけるLightweight Languagesは、その「軽量」の意味においてまったく異なるものであり、
英語でPerlやJavaScript、PHPを指し示す場合は、Scripting languagesと表現したほうが妥当であると考えられる。
つまり日本人のLightweightLanguageは和製英語であり、西洋人には通じないので注意しましょう。
外人エンジニアとの議論で混乱するから
LBL(Lightweight Brain Language)
に改称したらいい。
BLL(Brain-Less Language)
では?
javaで書かれた関数をWeb cgiで使いたいのだけど
トムキャットが無難なの? php が java に構文が近づくってだけでもjavaの完成度は高いよ。
そんなことより一番の恩恵はjvmの進化。
起動時以外はネイティブかそれ以上のパフォーマンスを得られる。 Mono最強伝説
http://ja.wikipedia.org/wiki/XSP_(Web%E3%82%B5%E3%83%BC%E3%83%90%E3%83%BC) なんか全体的にphp使いこなせてないのにphp批判してる連中ばっかだなww
プロがフレームワーク使いこなして中規模のwebアプリバリバリ書いてるとこ見たことないだろ
相当キレイに早くwebアプリが作れるし可読性も高くてメンテナンスもしやすい
javaでもプロが書けば同じだから、結局は言語仕様ってより使いこなすプログラマの質によるんだよ アプリケーションスコープの有り無しが違いとして大きいかと。 本当に不毛だな。
俺はPHPもJavaもできるがもうWebの時代は終わりだろ。
終わりってゆーか、スマホっていうビックウェーブが来てて
時代はもうそっちだよ。
だからこれからのプログラマは、JavaかObjective-Cができないと駄目だ。
Windows Phoneのことも考えればC#もできるようにしておいた方がいい。
もっと言うとC/C++もできるようにしておいた方がいい。
時代に取り残されたくなければ今のうちに勉強するんだな。 別にスマフォが普及してもサーバ側のプログラミングが
不要になるわけじゃないし。
自分はJavaとObjective-C使えるから別にどうでもいいけど。 >>292
サーバサイドがなくなるとは言ってないが、
メインストリームからは外れるだろ。
汎用機からオープン系に流れたように
Webからスマホに主軸は流れるんだよ。 スマフォは画面を出すだけで
データの蓄積、重い処理はサーバーに投げることになる 俺も最近Objective-C勉強するためにMacBook(AirでもProでもない)を
中古で6万円で買ったよ。
中古にしては手の良い中古でかなり大満足だ。
Windowsでも開発できるようにしてほしかったがしょうがねぇ。 俺の大学は一年で最初にJavaを使って教えてたんだけど、
今年からついにプログラミングの基礎はPython使って教えることになった。 Pythonなんて金にならない言語覚えてどうすんだろうな。 >>299
COBOLの方がPythonなんかより全然金になる。
(俺はCOBOL知らないがな) ■ このスレッドは過去ログ倉庫に格納されています