ふよふよ~~ん

うちの開発の連中がオブジェクト指向の手習いをはじめたみたいだ。
メソッドだとかプロパティだとかクラスだとかって大っきらいな言葉が飛び交っている。

僕は手続き型大好き人間で、車輪の再発明も大好きなので、基本的にオブジェクト指向は嫌いだw
Hello,Worldだってそれを“書くこと”に意味があると思ってるし。

できるようになってから、楽をするのはいい。
できないうちから楽を覚えちゃ駄目だ。


さてさて。そんな中。うちはWeb系で、メインはLLのphp。しかもつい先日End of Lifeを通知されたVersion4系。
いやー素敵ですね。で、5系に移行するか~。んじゃついでにオブジェクトもーって感じなんですけどね。
6見えてきてる状況での移行はリスキーな気がしないでもないけど。

さて。その結果、周りでプロパティだのメソッドだのと。うるせぇっ!!!
俺は全部functionで書くぜっ。でもCで実装してるとファイルハンドルのオープンだけでもダルいのでめんどくさいときは全部perlとシェルで逃げてるけど。
なんだかんだで結構利用の幅が広いですしね。sed+awk最強(違

ときどきシェル上実行プログラムがphpで書かれてたりするのは内緒。内緒ったら内緒。
ちょっとやってみたかっただけなんですw 次はrubyで書いてみやうwwwww
pythonも書いてみたいしwwwwww

で、横で話してるのが聞こえてきたんですが、メソッドオーバーロードができない、っつかなんだこのへんな実装!って.NETな人が言ってるので、phpでのオーバーロード実装を調べてみた。

…なんだこれは。どこがオーバーロードなんだ? って思ったがちょっとよく考えてみたら

変数型が厳密じゃねーんだから型定義でのメソッドオーバーロードなんてできるわけないじゃん。
さらっと見てみりゃrubyだってpythonだってオブジェクト指向LL言語って名乗ってるけど型でのオーバーロードなんて実装できてないっていうか仕様的に実装できない。

だって引数の個数と型によって呼ぶメソッドをダイナミックに変えるわけで、個数はなんとかなるにしても、型は無理。だって型定義しないんだもん。そもそもそんなことを考えなくていいからこそのLLであって。

型定義を厳密に規定する言語系使えよ、型でのメソッドオーバーロードしたいんだったら。
これはLLがダメっていうより単純にC++やJavaなんかのオーバーロード実装が型定義を前提として、そもそもそういう言語仕様に依存してつくられた概念であって、それと全く同じものをLLに求めるとこが間違ってる気がする。
まあ、あれば便利なのは確かなんだけど、最大個数決めて個数で引き渡してもらってメソッドの頭で諦めてif文スパゲッティでも作っておけとwwww美しくないなぁwwww
僕は手続き大好きですからif文大好きですけどね?w
Switch ~ caseなんてperlじゃif文の羅列ですし。言語仕様としてそうなんだから、それにあった書き方をすればいいんじゃなかろうかと思わないでもない。ないものねだりしたってしょうがないし。

僕的にはむしろ“型”の概念の薄い言語からはいっちゃった子たちが、SQLのカラム型の定義をとってもおろそかにしてるのが気になってしょうがありません。フラグビット一個たてるためにmedium int宣言してたり、とりあえずchar型のカラムが全部255になってたり。そして時々char(768)とか混ざってたり。
一時期のMySQLが255オーバーを許容してたから異常なことに。
そんなにいるならtext型にしとけえええええっ。ってなんに使ってるのか聞いたらそのカラムはパスワード記録フィールドとか言われて萎えた。どこのバカが768文字のパスなんか使うものか。パスフレーズでもつかわねぇよ。

そもそも、char(255)っていう型だと認識してるんじゃないだろうか。あとSQL99とかSQL97しらなすぎだよなぁ…。
俺もDB専門じゃねーから全然しらんけどさ、Web系開発である程度汎用性をって考えたら普通代表的なDBの型定義くらい気にするもんじゃないのかね、とenum使いまくったカラムを見て思う。
なんせenumの中身をそのままセレクトボックスの要素としてブチ込むから、おもいっくそMySQLのenum仕様依存じゃねぇか。せめてenum(‘0′,’1’)とかで頼むわ…。ていうかそれはbool使ってtinyintでいいだろって思うんだけどね。SQL97ベースだからboolの実装が変なのは仕方ない。

けど、enum(‘足’,’手’,’顔’,’ひざ’)とかねwwwwwww 最初みたときに腰が砕けた。
それはないだろって。

要は、型ってのをあまり意識しない言語に慣れ過ぎて、あらゆる型を軽視してしまう傾向にあるんじゃないかな、と。
その世界だけなら決して困らないけれど、ひとたびその世界の外に触れるとその異常性が際立つ。

けどまあ、型オーバーロードのその引き換えとしてLL最大のお手軽ポイントである型宣言なしでの変数の適当乱れ撃ち使用の仕様を捨てれるのか、って話だし。それは無理っつかイヤなんだろうな。それやってもいいよっていうなら最初からC++かJavaでやっとるわっつー話だわな。

そんなことよりも、ぼくはいまmysqlの4.1.xxから4.1.yyへえいやってアップデートしちゃおうかどうしようか悩んでるんですよwwwwwwwwww
普通なら大丈夫だけど、なんせMySQLだしねぇ…。
信じていいのかしら…。念のためにテストしてからの方がいいかしら。

これがapacheなら気にせず置き換えるんだけど。まずなにも起きないしwwwww
でも別に環境作ってテストするのもめんどくさいし(それが仕事のはずですwwwwwww

どーしよっかなあああああああああっ。めんどくさいよおおおおおおおおっ←ダメ人間

よく考えたらMySQLって10年しかたってないんですよね、生まれてから…。
40年前からあるPostgreSQL。どうも、歴史のある方が好きみたいです。LinuxよりBSDの方が好きだし。
社内でpgSQLへの移行を促し中。MySQL捨てましょうキャンペーン展開。
双方向レプリがたけぇんだよ、MySQLは。SQL Serverとおんなじやな。
※双方向レプリが必要なものを作ってるのか?という根本的なとこは質問禁止。

0 thoughts on “ふよふよ~~ん

  1. まあ、ミクに関してはプロによる計画的犯行食らって
    リベンジに燃えた人がリベンジ成功してたりするから洒落になってない人はなってない。<きしめんで探せば出る
    個人的にはベースの声の主の性質が正直あまり宜しくなかったんではと最近思うんよ、アタックが弱い声だから色々無理してる部分が多いと思ってる。
    で、問題のT豚Sはとりあえず地デジオンリーになる前に消えてくれ…何も見てないから電波の無駄じゃ

  2. まあ企画書通りにやってないのはアレとして、今回はキモヲタんがさらにその上をいってアレだけどなぁ。
    アタックの弱いサンプリング音しかないので、バラード系はともかく、キレのいい歌は苦手だろうねぇ。
    PCMでやるなら最低でも50音*32テーブルくらいもってくれないとキツくないかなー。
    音ごとに一回エフェクタ通してリサンプリングしたのを音源にすればある程度はごまかせそうだけど。
    リサンプリングまでやったデータってあったかなぁ…?
    とりあえず上手い人のは上手いですね。まだまだいくらでも煮詰める要素が思いつくけど、あとは手間との相談なんで、でてくるには時間がいるでしょうし。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です