Na melyik az a programozási nyelv...

... amelyik engedi, hogy egy osztálynak a metódusait statikus metódusként hívjuk meg, mégha az nem is az? :) 

<?php

class A
{
	public function foo()  // NEM statikus metódus
	{
		echo get_class($this);  // "B"
	}

}

class B
{
	public function bar()
	{
		A::foo();  // statikus metódushívás! 
	}
}

$b = new B();
$b->bar();

( persicsb | 2010. 01. 14., cs – 17:45 )

Popcorn bekeszit. Majd kapod a flamet, hogy hat de a PHP igy meg ugy jo, meg ilyen jo OOP meg olyan jo OOP. Utana jonnek a Java fanok, hogy a Java ilyen jo, olyan jo. Aztan az ASP.NET-esek, hogy a .NET gyorsabb mint a Java, de ugyanolyan jo, aztan a Javasok, hogy a C# a Javarol masolt mindent, aztan jonnek a Ruby/Python fanok, hogy azok sokkal jobb kornyezetek, mert ezeknek jobb az API-ja, stbstb. Amugy a PHP tenyleg fos. Sokan nem fogjak fel, h ez se mas, mint egy template rendszer...azert az LOL, hogy barhol a kodban, barhol egy egyszeru echo hivassal tudok a bongeszo fele BARMIT irni. Nincs meg a REquest/Response szetvalasztas rendese (nem, meg a Zend Frameworkben sem, ott is irhatsz echot-t, mert nyelvi elem). Gagyi.

( Protezis | 2010. 01. 14., cs – 18:00 )

Már a cím alapján tudtam, hogy a PHP lesz terítéken.

Az említett "feature" valóban idegesítő, én sem szeretem, sajnos PHP4-es maradvány. Azt azonban el kellene fogadni, hogy ugyanúgy, mint más nyelvnek, a PHP-nek is megvannak a maga előnyei és hátrányai. A fenti példa az utóbbihoz tartozik.

( Panther v | 2010. 01. 14., cs – 19:38 )

Hm. Lehet, a jelölés PHP-specifikus, ugyanis C++-ban ez elő szokott fordulni, ha a szülőosztálybeli azonos nevű függvényt meg kell hívni, és nyilván nem statikus függvényt. Olyankor például, amikor van egy absztrakt ősosztály, annak egy tisztán virtuális tagfüggvénye, amelyet a gyerek osztályok implementálnak. További öröklődéskor további adattagokat kell v. lehet használni, de a szülőosztály viselkedésére továbbra is szükség van, pusztán annak bővítését kell implementálni.

Vagy egy tisztán virtuális függvény "törzsét", kódját hívja meg a leszármazott osztály azonos nevű függvénye.

Szerintem nézd meg jobban a kódot, semmiféle ősosztály nem játszik itt.

Adott két, egymástól független osztály, benne két függvény, amelyek nem statikusak (az, hogy virtuális-e vagy sem, az most itt lényegtelen).

Az egyik osztály meghívja a másik osztály metódusát, mintha statikus lenne (ld. :: operátor -> helyett), holott ez normális nyelvekben (C#, C++, stb.) le se fordulna.

Ráadásképp a hívott osztály a $this-t "megörökli" a hívó osztálytól, mintha a hívó osztály saját metódusa lenne, pedig semmiféle kapcsolatban nem áll a két osztály. 


#include <iostream>

using namespace std;


//////////////////////////////////////////////////////////////////////////////
class A
{
public:
	void Foo();	
};

void A::Foo()
{
	cout << "Hello";
}


//////////////////////////////////////////////////////////////////////////////
class B
{
public:
	void Bar();
};

	
void B::Bar()
{
	// error C2352: 'A::Foo' : illegal call of non-static member function
	A::Foo();
}


//////////////////////////////////////////////////////////////////////////////
int _tmain(int argc, _TCHAR* argv[])
{
	B b;
	b.Bar();

	return 0;
}

----------------
Lvl86 Troll

( Nyosigomboc v | 2010. 01. 14., cs – 20:41 )

Erdekes is lenne, ha nem hagyna, mikor a doksiban is benne van, hogy hagyja, es ebben az esetben mi tortenik:
http://hu.php.net/manual/en/language.oop5.basic.php

"The pseudo-variable $this is available when a method is called from within an object context. $this is a reference to the calling object (usually the object to which the method belongs, but possibly another object, if the method is called statically from the context of a secondary object)."

+peldakodot is talalsz alatta
Ha el akarod kerulni, az E_STRICT-et bekapcsolva warningot kapsz erre a hivasra (ezt is leirja).

--
"You will have to look a long way before you find a bunch of scum-suckers more greedy, humourless and deserving of death than the suits in the music business." - Terry Pratchett

Ezt az egeszet ugy taglaljatok, mintha a kliens minden esetben hozza tudna ferni valamihez, anelkul, hogy a programozo ezt beleirta volna a kodba.
Tehat, az en elgondolasom szerint akkor fer hozza az altalad leirt modon, ha te igy irtad meg.
Mivel a PHP -t altalaban webes alkalmazasokban hasznaljuk, nagyon csunya lenne, ha csak a nyelv sajatossagaira hagyatkoznank, mindenfele ACL,stb. nelkul.

"-Pedig vegetariánus vagyok; csak növényevő állatokat fogyasztok!"
azenoldalamponthu

A legnagyobb probléma valójában ez:
"Calling non-static methods statically generates an E_STRICT level warning."
Normális nyelvekben ez syntax error és le sem fordul a kód, nem pedig valamilyen szintű warning.
Hanyag programozók pedig mindenhol vannak, akik hibásan kódolnak (esetleg hozzászoknak, hogy így is lehet, de jó..nem, nem jó). és ha egy külső libet használok, akkor a nyelv miért hagyja, hogy egy másik objektum a hívó objektum mindenéhez hozzáférjen? Ez egy alapvető OOP tervezési elv semmibevétele, nyelvi tervezési hiba.
A PHP a modern kor BASIC-e. Bizonyos feladatokat nagyon kényelmesen lehet vele megvalósítani, de valójában egy rémálom.

Normális programozó IDE-t használ, ami meg mondjuk a :: után csak a statikus és megfelelő láthatósággal rendelkező metódusokat és változókat kínálja fel. Tudom, ez nem változtat a tényen, de szerintem kár ezen lovagolni. Szerintem nem rémálom, én szeretem a hibái ellenére is.

A nyelv megengedi, ha te is megengeded. Ha nem akarod, akkor error_reporting(E_ALL|E_STRICT);.
A fenti példa eredménye:

Strict standards: Non-static method A::foo() should not be called statically, assuming $this from incompatible context in /home/protezis/devel/php/minimalscripts/classes/stricttest.php on line 12

Egy jó PHP programozó a fenti sorral kezdi a munkát.

Az E_STRICT nem warning :) Az az E_NOTICE-nál is kisebb prioritású, PHP 5.2-ben benne sincs az E_ALL-ban. Szóval a helyzet még rosszabb.

Nem feltétlen kellene syntax error-nak lennie, én bőven kibékülnék, ha a parse error-okat leszámítva mindenhol exception lenne (ahogy az jobb szkriptnyelvekben szokás).

Legyen csak parser/syntax error. Az exeption csak az emberek eletet bonyolitana.

Egyebkent is, nem tudom, egy ilyen nyiltan template alapu nyelvbe mi a feszkes frasznak OOP. Doglott lonak fenyes nyereg.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Felreertesz. Nem maganak az OOP-nak a letenek ertelmet kerdojelezem meg, hanem annak, hogy valoban kell-e ez a PHP-ba. Alapvetoen a nyelv eredeti szintaxisa nem tette soha alkalmassa a nyelvet az objektum orientalt programozasnak meg a latszatara sem. Idokozben sikerult bevezetni az OOP-t, de - akarcsak a nyelv tobbi elemet - atgondolni ezt sem sikerult, gyanitom, hogy valami hasonlo szavazasos alapon ment a dolog, mint a namespace support.
A legnagyobb gond az, hogy a legtobb feature egy normalis QA folyamat utan torlesre kerulne a nyelvbol, egyszeruen azert, mert nagyon veszelyes az egesz a jelen allapotaban. Es itt nem csak az OOP specifikus problemakra gondolok, hanem az inkonzisztens core API-tol kezdve az eletveszelyesen liberalis parseren at nagyon sok mindenre.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"valoban kell-e ez a PHP-ba."

Én azért örülök annak, hogy van, sok mindent gyorsabban, rugalmasabban meg tudunk oldani vele, mintha nem lenne.

"A legnagyobb gond az, hogy a legtobb feature egy normalis QA folyamat utan torlesre kerulne a nyelvbol, egyszeruen azert, mert nagyon veszelyes az egesz a jelen allapotaban."

Csupán ennyi a problémám.

----------------
Lvl86 Troll

( vomberg | 2010. 01. 15., p – 09:25 )

Én nem igazán tudom, hogy min folyik a habverés, mivel a PHP születésénél fogva egy szkript nyelv, s a szkript nyelvek sajátossága, hogy olyan hajmeresztő dolgokat lehet bennük csinálni, amitől egy "normális" programnyelv még syntax error-t sem dobna, mert elájul a látványtól fordítás vagy értelmezés közben.

Az egy külön pikantériája az ügynek, hogy ezt az objektumorientált fasságot divat lett ráerőltetni mindenre (lassan a klozettot is csak úgy lehet lehúzni, hogy metódust hívok hozzá), s ilyenkor jön a zavar az éterben, mert az OOP-t is a szkriptnyelvekre jellemző lazasággal implementálja a PHP.

Ab start ilyen a filozófiája, miért lenne más az implementálása?