ugrás a tartalomhoz

Miért nem használnak jóval többet ASP.NET-et fejlesztésre

moszinet · 2007. Jún. 8. (P), 21.17
Sziasztok,

gondoltam felvetem a weblabor-on a kérdést, hogy miért nem használnak jóval többen asp.net -et webfejlesztésre ?
Én fejlesztettem egy jópár weboldalt PHP-ben és Perl-ben is, viszont azt kell mondjam, hogy csalódottan látom azt, hogy elég kevesen használják az asp.net -et ami véleményem szerint sokkal hatásosabb mint a PHP.
Maga a strukturáltsága és az objektum orientált framework ami a háta mögött van sokkal fejlettebb mint a PHP framework-je, mégis úgy látom, hogy a PHP sokkal közkedveltebb :) ... ?
‹ ASP .Net URL rewrite vs. Googlebot .ini kiterjesztésű fájl kezelése ASP.NET -ben ›
 ■
1

flame on

Fraki · 2007. Jún. 8. (P), 21.59
Én nem ismerem az asp.net-et, de azt tudom, hogy a php egy nehézkes, merev őskövület. Nyilván a beágyazottság, az elterjedtség az ok. Amikor született, teljesen másról szólt a webfejlesztés, szerintem a php tervezésekor erős szempont volt a template-funkció.

Az ember JS-kódoláskor látja igazán mi mindenről is szólhatna a szerveroldal, persze ez nyafogás, én személy szerint ruby-ra szeretnék átállni, de ez nem könnyű és nem gyors folyamat.

Aztán nyilván belejátszik a kérdésbe a windows vs. linux, illetve apache vs. IIS témakör.
8

ez igy tenyleg csak flame ;)

Hodicska Gergely · 2007. Jún. 10. (V), 20.22
a php egy nehézkes, merev őskövület.
A nehezkes az szubjektiv, ezert erre annyira nem reagalnek, de azert azt megjegyzem, hogy PHP egy-ket nyelvi megoldasanak hala sok dolgot (OOP design patternekre gondolok) lenyegesen egyszerubben lehet megoldani, mint mondjuk C#/JAVA-ban. Az oskovulet az szerintem igencsak eltulzott, esetleg lehet, hogy nem koveted a nyelv fejlodeset. Raadasul pont a PHP-ra jellemzo, hogy ha megjelenik valami jo dolog, akkor valaki biztosan illeszti hozza.

Az ember JS-kódoláskor látja igazán mi mindenről is szólhatna a szerveroldal,
Hat oszinten kivancsiva tettel, hogy mi volt az JS kodolaskor, ami hianyerzetet kelltett Benned a PHP-val szemben.


Udv,
Felho
2

Elérhetőség, egyszerűség

saxus · 2007. Jún. 9. (Szo), 00.10
A PHP mindenki számára elég egyszerűen elérhető. Regisztrálsz egy ingyenes tárhelyen, 99%, hogy lesz PHP-d és MySQL-d. (Főleg itthon). Egyszerű, gyorsan tanulható nyelv, ráadásul olcsó, hiszen szoftvert se kell venni.

Ahogy láttam, ASP.NET -t meg inkább nagyobb projectekhez használnak.

- Szerintem -
12

Lehet mar itthon is asp.net-et kapni

moszinet · 2007. Jún. 10. (V), 22.45
hostingabc.hu-n lehet mar asp.net-et kapni ...
14

köszi!

krey · 2007. Jún. 10. (V), 23.45
Régóta keresünk ilyet :)

üdv. krey
30

szivi

moszinet · 2007. Jún. 11. (H), 23.03
Nagyon szivesen :) ...
3

framework..?

szaky · 2007. Jún. 10. (V), 10.02
"...sokkal fejlettebb mint a PHP framework-je"

A php nem framework, ezért nem értem a php és az asp.net öszehasonlítást. Egy WACT-ot, vagy CodeIgnitert össze lehet hasonlítani vele, de a php és a asp.net összehasonlítása igen csak fals...

Szaky
4

Szerintem

w3net · 2007. Jún. 10. (V), 10.36
azért, mert legtöbben a JSP-t választják.
Megpróbálom felsorolni a lehetséges indokokat:
- spórolnak. Jává-t és ASP.NET-et általában nagy projekteknél használnak, legtöbbjük dedikált szerveren fut, ami azt jelenti, hogy Windows esetében jelentősen megnőnek a kiadások a szoftwer licensz miatt.
- kevés a VB vagy C# fejlesztő. Szinte minden főiskolán tanitanak Java-t.
- spórolnak. A PHP fejlesztők kevesebbe kerülnek.

Szerintem az a kérdés érdekesebb, hogy hány PHP fejlesztő tart ki továbbra is a PHP mellett. Az évek során a fejlesztők tudása és a fejlesztendő webes alkalmazások követelményei is egyre inkább nőnek. A PHP pedig nem sokat fejlődött. Igyhát sokan kinövik a PHP-t, mások pedig szomorúan belátják, hogy a PHP már többé nem ideális nagyobb webes alkalmazásokra (teljesitmény, gyenge OOP, skálázhatóság,..).

Hogy miért nem használnak jóval többen ASP.NET-et fejlesztésre? Szerintem ezért, mert még sok a kicsi webes projekt, amire a PHP alkalmasabb. Kisebb projektekhez a PHP szerencsésebb választás, mert gyorsabban elkészül a projekt. Kis projekteknél nem érdekes a spagetti kód, a nehezen átlátható és nehezen karbatarthatű kód, mert a projekt elkészül, és utána senki sem fog vele törődni.
5

védelem

Szekeres Gergő · 2007. Jún. 10. (V), 14.09
Az anyagi részével teljesen egyetértek, sokkal olcsóbb kialakítani egy php-s környezetet, mint egy ASP-t, de:
Nagyon sok fejlesztőt hallottam szídni a phpt gyenge teljesítménye miatt. Szerintem ez egy erős túlzás, megfelelő környezet és technikák alkalmazásával igenis gyors futásidőt lehet elérni(gyorsítótárak, HATÉKONY kódolási technikák). Az pedig, hogy kinek mi a "spagetti kód", arról fölösleges vitatkozni, én még nem láttam olyan nyelvet, amiben ne lehetne gányolni, így ez is a programozón múlik...

Az őskövület kifejezést pedig nevetségesnek találom. Én inkább egy kicsit nagyobb fapadosságot hiányolok, amivel akadályozható lenne, hogy a fejlesztők "csakműködjön" személelbe kódolhassanak. Kódolj egy napot assembliben, utána nem mondanál ilyet;) (amúgy már egy kis C programozás is megváltoztatná ezt a szemléletet..)
6

hát igen

Fraki · 2007. Jún. 10. (V), 14.54
Ki honnan érkezett. Én C64 Basicen, delphin, majd javascripten nőttem fel. Az első kettőt merevnek éreztem már akkor is, utóbbi pedig mennyország, most pedig a ruby felé áhítozom, úgyhogy "fölfelé" haladok :)
10

JS vs. php??

Szekeres Gergő · 2007. Jún. 10. (V), 21.01
Nem értem, most már többen írtátok, de mi az ami phpban merev, jsben nem? Azért érdekel a dolog, mert így vagy ti tudtok kevesebbet phpban, vagy én jsben... :) De azért szerintem egy kliens oldali scriptnyelvet nem érdemes összehasonlítani egy szerveroldalival. nem egy súlycsoport.

Az ooval kapscolatban megjegyezném, hogy pontosan ugyan azt tudod megoldani nélküle is(persze, kivételek és hasonló, de ezeket is le lehet kezelni nélküle), igazából szerintem a fejlesztők 99% nem talákozott még olyan méretű projekkel, amihez tényleg feltétlenül kellene(én sem). mivel még nem volt még ennyire égetően szükségem, így nem is tudom mi a vége, de nekem még nem volt olyan feladat, amit phpval nem tudtam megoldani. A webes projektetben általában az adatbázissal lehet sokat gyorsítani, az, hogy php vagy asp fut, szinte nem is feltűnő. A fejlesztésen spórolt forintokat pedig lehet szerverre költeni, és akkor végül is melyik a gyorsabb?:)
11

OOP vs funkcionalis

Hodicska Gergely · 2007. Jún. 10. (V), 22.06
Az ooval kapscolatban megjegyezném, hogy pontosan ugyan azt tudod megoldani nélküle is
Ezzel vitatkoznek kicsit. Elvben talan elkepzelheto, hogy funkcionalis megkozelitesben is lehet ugyanolyan kifejezoen programozni, de ezt meg nem nagyon tapasztaltam, raadasul akarhogy is nezzuk, de az OOP eszkoztaraval ez konnyebben megteheto. Plusz egy kis adalek: http://weblabor.hu/cikkek/oopkodujrahasznositas.


Udv,
Felho
16

persze hogy összehasonlítható

Fraki · 2007. Jún. 11. (H), 02.43
De azért szerintem egy kliens oldali scriptnyelvet nem érdemes összehasonlítani egy szerveroldalival.

Már miért ne lenne érdemes. A megfelelő szempont kell hozzá, engem elsősorban a php szintaxisa zavar: rettenetesen merev CFG (különösen OOP-ben).

De említhetnénk a namespace nélküli függvénykönyvtárat is (ennek sincs sok köze ahhoz, hogy szerver- vagy kliensoldali).

Én egyébként nem rosszindulatú vagyok a php-val szemben, egyszerűen csak megállapítom, hogy amikor tervezték, még másról szólt a webfejlesztés. Nem véletlenül mondják többen, hogy kisebb projektekre alkalmasabb: amikor készült, akkor még template-funkciót szántak neki (sokféle string-szintaxis, megszakított tagek stb.), a mai web2-es és MVC-s világ viszont már másról szól. Nem arra készült, hogy frameworköket írjanak rá. Ezért egyébként a php-ra készült frameworköket is magukkal viszik ezt a merevséget, pláne hogy egy frameworkben már hangsúlyosabb szerep jut az oop-re is.

És hogy miben rugalmasabb a js? Vhol olvastam egy cikket, ami arról szólt, hogy a Prototype mennyire át tudta formálni ruby-sra a JS-t, és hogy a JS-t valójában szándékosan ilyenre tervezték (a cikk egyébként egy reakció volt egy prototype-pal szembeni kritikára, miszerint az eltéríti a programozót a JS helyes koncepciójától). Csakhogy a JS tényleg arról szól, hogy össze-vissza lehet gyúrni. Nem tudom, mi volt a megnevezés erre a tulajdonságára.

Szóval aki a szemantikai tömörségben ínyenc, annak a php egy szálkás öreg deszka.
17

kicsit konkrétabban?

Hodicska Gergely · 2007. Jún. 11. (H), 03.07
a mai web2-es és MVC-s világ viszont már másról szól. Nem arra készült, hogy frameworköket írjanak rá.
Tudsz erre pár konkrétabb dolgot mondani?

Ezért egyébként a php-ra készült frameworköket is magukkal viszik ezt a merevséget, pláne hogy egy frameworkben már hangsúlyosabb szerep jut az oop-re is.
Mi a gond a PHP OOP-jével, ezt még nem tudtuk meg (csak hogy elég szomorú, hogy nem lehet egy példány egy metódusát csak úgy felül definiálni).


Üdv,
Felhő
18

nem tudok konkrétabb dolgokat mondani erre

Fraki · 2007. Jún. 11. (H), 07.57
Tudsz erre pár konkrétabb dolgot mondani?

Ez a véleményem. Nem tudom megkérdezni az alkotókat, mi volt az alapkoncepció, én a nyelvből meg az említett körülményből, hogy akkor hogy nézett ki a web, és hogy hogy néz ki most, ezt olvasom ki.

Mi a gond a PHP OOP-jével, ezt még nem tudtuk meg (csak hogy elég szomorú, hogy nem lehet egy példány egy metódusát csak úgy felül definiálni).

Nincs túl határozott véleményem a php OOP-jéről, de nem is erről beszéltem. (A másik topikban sem arról beszéltem.)
29

...

Sulik Szabolcs · 2007. Jún. 11. (H), 14.59
a mai web2-es és MVC-s világ viszont már másról szól. Nem arra készült, hogy frameworköket írjanak rá

Mielőtt ilyeneket írnál nézz egy kicsit körül. Ajánlom figyelmedbe a CakePHP-t.

...Csakhogy a JS tényleg arról szól, hogy össze-vissza lehet gyúrni...

Ebből és néhány korábbbi megszólalásodból számomra csak az jön le, hogy te rendesen kevered a tervezési mintákat és azok adott nyelven történő megvalósítását.
9

kicsit reszletesebben?

Hodicska Gergely · 2007. Jún. 10. (V), 20.36
mások pedig szomorúan belátják, hogy a PHP már többé nem ideális nagyobb webes alkalmazásokra (teljesitmény, gyenge OOP, skálázhatóság,..).
Erdekelne, hogy ezt milyen tapasztalatok alapjan szurted le. Mindig csodalkozom, amikor ilyesmiket olvasok.

A teljesitmenyt alapvetoen hagyjuk, mert szinten tok relativ, de nem hiszem, hogy egy "nagyobb webes projekt" eseten a PHP "lassusaga" lenne a legszukebb keresztmetszet, raadasul lattam/latok eleg komoly terhelessel biro PHP rendszereket.

Gyenge OOP: ket gondolat. Mi az a gyengeseg, ami nagyon akadalyoz abban, hogy valami komoly dolgot tudj alkotni PHP alapokon? Masreszt az OOP szerintem szemleletmod, nem azon fog mulni, hogy ne adj isten valamit a nyelv nem tamogat, persze nyilvan jobb, ha bizonyos funkciok nyelvi szinten tamogatottak.

Skalazhatosag: hat ha valami, akkor pont a PHP az, ami nem temaszt akadalyt a skalazhatosag ele. Milyen gondjaid voltak a PHP-val kapcsolatban a skalazhatosag szempontjabol?


Udv,
Felho
19

Egyetértek

janoszen · 2007. Jún. 11. (H), 08.35
Egyetértek. Egy alkalmazás attól lesz skálázható, hogy skálázhatóra írod meg, nem attól, hogy a nyelv támogatja. Lehet, hogy egy keretrendszer támogatja a skálázást, de a PHP nem keretrendszer, innentől kezdve...
20

Konkrét példa

w3net · 2007. Jún. 11. (H), 10.18

class CollectionBase implements IteratorAggregate, Countable {

    public function addItem($newItem, $key = null) {
    }
}

class SurveyCollection extends CollectionBase{

    public function addItem(Survey $newItem, $key = null){
        parent::addItem($ne­wItem, $key);
    }
}
Strict Standards: Declaration of SurveyCollecti­on::addItem() should be compatible with that of CollectionBase::ad­dItem() in …

Még ilyen logikus dolgot sem enged a PHP, pedig ez helyes OOP elgondolás lenne (szerintem).
A SurveyCollection osztály egy specializált osztály, aminek az addItem metódusa felülirja a szülő osztályt. Na most a PHP szerint ez miért nem kóser? Logikus, hogy egy konkrét objektum a variable data type részhalmaza, igy nem értem miért nem kóser, ha type hint-et alkalmazok a specializált osztályban.
Persze kipróbálhatjátok úgy is, hogy a szülő osztály addItem metódusának első argumentuma Object-et fog várni.

class CollectionBase implements IteratorAggregate, Countable {

    public function addItem(Object $newItem, $key = null) {
    }
}
De úgy emlékszem ez sem kóser a PHP-nek. Ez csak egy konkrét példa volt.


A legidegesitőbb azonban a névterek hiánya. Képzeljétek el, hogy van 2 web alkalmazásom, és szeretném használni az egyik webes alkalmazásban a másik webes alkalmazás API-ját, mert nincs kedvem copy paste-t csinálni. De ez nem olyan egyszerű, mert előtte minden osztály nevét valami prefix-el kell ellátnom, nehogy name collision jöjjön létre. Nos, az ilyen kényszer megoldásokat én nem szeretem.
ASP.NET ben az egész webes alkalmazás egy dll, és azt simán tudnám használni egy másik webes alkalmazásban.

A másik dolog, hogy ha OOP-ben akarunk programozni, akkor arra jövünk rá, hogy PHP-ben nincsenek is előre definiált objektumok (OK PHP5.2-ben már van néhány). Például olyan alap osztályok, mint Collection, DateTime, DateTimeInterval, TimeSpan, ...
Persze, máris rávágjátok, hogy frameworkot kell használni. Ez igaz, de melyik frameworkot a létező 20 vagy 30 ból? És mennyibe kerül nekünk ez? Az eredmény gyengébb teljesitmény. ASP.NET-ben nyugodtan használhatjuk a .NET frameworkot, mert nem kell attól tartani, hogy lassúbb lesz a teljesítmény.

The performance test of 6 leading frameworks
CakePHP & CodeIgniter Benchmark


Szerintem is a JavaScript egy sokkal rugalmasabb nyelv, és egyből szerelmes lettem bele. A closures a JavaScript-ben egyszerűen fantasztikus dolgokra ad lehetőséget.
21

Nem feltétlen

janoszen · 2007. Jún. 11. (H), 10.53
Na azért ácsi meg a menet. Az azért példa azért nem egészen oké, mert tfh. valamilyen osztály alapoz az előbbi CollectionBase osztályra és az valamilyen alaptípust vár és ezért nincs megadva typecast. Namost ha ahelyett egy objektumot kap, akkor mi történik?

Emlékeim szerint viszont az utóbbi példának működnie kéne.

Ami pedig a frameworkoket illeti, az a kérdés, hogy mennyire akarsz alacsony szinten programozni. Ha magas szinten akarsz programozni, akkor oké, de nem tudom, mennyire tudsz az alacsonyabb rétegekbe belenyúlni. Annyi ASP.NET-es nem rendesen lekezelt hibát láttam a neten, hogy ihaj.

A másik kérdés a portabilitás. A PHP szinte bármilyen rendszeren el fog futni. Elmondható ugyanez az ASP.NET-ről is? Nem hiszem. Plusz még annyit hozzáteszek, hogy a JavaScript kezdetektől fogva egy beteg nyelv volt, a Microsoft és a Netscape párharcának esett áldozatul - a mai napig nincs egységes implementációja. Arról nem is beszélve, hogy a Microsoft bármikor foghatja magát és átgombolhatja az egészet vagy megszűntetheti a supportot és senki nem fog tudni ellene semmit sem csinálni.
26

Re

w3net · 2007. Jún. 11. (H), 13.11
- JavaScript: The World's Most Misunderstood Programming Language
- MONO
- ECMAScript Language Specification
- kiprábáltam mindkét esetet, nem megengdett.
22

rere

Hodicska Gergely · 2007. Jún. 11. (H), 11.26
Strict Standards: Declaration of SurveyCollecti­on::addItem() should be compatible with that of CollectionBase::ad­dItem() in …
Pedig ez szerintem elég logikus. Egy gyerek interfésze nem lehet specializáltabb, mint az ősé, hisz ha valahol előírod, hogy egy szülő objektum előforduhat, ott bármikor használható kell legyen egy gyerek osztály is, de a fenti megoldás ezt meggátolná.

A legidegesitőbb azonban a névterek hiánya.
Ebben simán egyet értünk, sose tudtam megérteni, hogy ezt miétr nem akarják beletenni, ez már szinte kicsit "politikai" döntés volt. Reméljük, hogy PHP6-ba végre beleteszik.

A másik dolog, hogy ha OOP-ben akarunk programozni, akkor arra jövünk rá, hogy PHP-ben nincsenek is előre definiált objektumok
Nem hiszem, hogy ez döntően befolyásolja azt, hogy tudsz-e jól OOP kódot gyártani. Ha tényleg szükséged van egy ilyesmi osztályra, akkor könnyedén megírhatod (vagy használhatsz PEAR-t), de ha épp csak egy funkcióra van szükség, akkor engem nem zavar ha ezt egy függvényhívással érem el.

Szerintem is a JavaScript egy sokkal rugalmasabb nyelv, és egyből szerelmes lettem bele.
Hát szíved joga, két észrevétel:
o Fura, hogy a PHP OOP hiányosságai után egy olyan nyelvre mondod, hogy sokkal rugalmasabb, ahol semmilyen nyelvi eszközöd nincs arra, hogy biztonságosan tudj programozni. (mondjuk szerintem sem érdemes a két nyelvet összevetni)
o Ami megint csak fura annak fényében amit írtál, hogy pont JS szinte alig nyújt bármit is, ha hatékonyan akarod használni, akkor kénytelen vagy valamilyen frameworkot használni.


Üdv,
Felhő
28

Re:

w3net · 2007. Jún. 11. (H), 14.31
Pedig ez szerintem elég logikus. Egy gyerek interfésze nem lehet specializáltabb, mint az ősé, hisz ha valahol előírod, hogy egy szülő objektum előforduhat, ott bármikor használható kell legyen egy gyerek osztály is, de a fenti megoldás ezt meggátolná.

Nem értem az érvelésedet. Talán egy példa segítene megérteni.

Ime a kód Java nyelven. És működik. 
public class Hurra {
	public static void main(String[] args){
		System.out.println("Hello!");
		new SurveyCollection().AddItem(new Survey(), "key");

	}
}


class CollectionBase {
	protected String m_strKey;

	// constructor
	public CollectionBase(){
	}

	public void AddItem(Object obj, String strKey){
		this.m_strKey = strKey;
		System.out.println("AddItem invoked in CollectionBase class.");
	}
}

class SurveyCollection extends CollectionBase {

	private Survey m_oSurvey;

	// constructor
	public SurveyCollection(){
	}

	public void AddItem(Survey obj, String strKey){
		this.m_oSurvey =  obj;
		this.m_strKey = strKey;
		System.out.println("AddItem invoked in SurveyCollection  class.");
	}
}

class Survey {
	public Survey(){
	}
}
Nem hiszem, hogy ez döntően befolyásolja azt, hogy tudsz-e jól OOP kódot gyártani. Ha tényleg szükséged van egy ilyesmi osztályra, akkor könnyedén megírhatod (vagy használhatsz PEAR-t), de ha épp csak egy funkcióra van szükség, akkor engem nem zavar ha ezt egy függvényhívással érem el.

- természetesen az osztályok hiánya nem jelenti azt, hogy nem tudok jó OOP kódot írni. Csak hát kinek van egy projekt elején kedve heteket azzal eltölteni, hogy megírja ezeket az alap osztályokat. Sokan csak PHP programozók, és nem szoftwer tervezők. Nem könnyű jó objektum modellt megtervezni. A másik dolog pedig, hogy nincsen idő és pénz saját alap osztályok tervezésére és kódolására, mert az idő pénz. Ami pedig a PEAR-t illeti, inkább hanyagoljuk. Sosem használtam és nem is fogom.

Szerintem is a JavaScript egy sokkal rugalmasabb nyelv, és egyből szerelmes lettem bele.

A nyelv szépsége (syntax és lehetőségek) és rugalmassága fogott meg.


Fura, hogy a PHP OOP hiányosságai után egy olyan nyelvre mondod, hogy sokkal rugalmasabb, ahol semmilyen nyelvi eszközöd nincs arra, hogy biztonságosan tudj programozni. (mondjuk szerintem sem érdemes a két nyelvet összevetni)

- privát változók és metódusokat támogatja JavaScript nyelv. Ennek ellenére nem ajánlott gyakran closure-t használni, mert a teljesitmény jelentősen leromlik. The cost of private members via closures in JavaScript
- semmi problémát nem látok abban, hogy a privát láthatóságú metódusoknak és tulajdoságoknak "_"-el ellátott nevet adjak. Pl.: var _colItems;


Tessék egy másik konrét példa:

class ParentClass{
    private function foo(){}
}

class Child extends ParentClass{
}

$rc = new ReflectionClass('Child');
echo $rc->hasMethod('foo'); // TRUE!
Azt hiszem, nem kell kommentálnom.
31

re mindenféle

Hodicska Gergely · 2007. Jún. 13. (Sze), 11.53
Szia!


Kicsit megkésve, de eléggé be vagyok havazva.

Az eredeti példa logikussága (ahogy én látom, lehet, hogy tévedek): azzal, hogy megszorítom egy metódus által elfogadható paraméter típusát, azzal szűkítem az objektum interfészét, ami szerintem nem szerencsés. Elvileg ugye ahol egy osztályt megengedek, ott bármikor használhatok egy belőle származó gyereket. Ha a használat helyen az ős osztály nem tesz semmilyen megszorítást az addItem paraméterére vonatkozóan, így gond lehet, amikor ott egy gyerek osztály addItem függvényét hívom meg mondjuk egy inttel.

JAVA (amihez nem értek) példa:
o Kíváncsi lennék, hogy ugyanaz működik-e akkor, ha az alap osztályban nem Objectet használsz, hanem int-et.
o Amit nem értek a példából, hogy ez nem mond ellen a polimorfizmusnak?

Az eredeti PHP kódod: kicsit azért gyanús volt nekem ez a dolog, ezért kipróbáltam, igaz én azt akartam kipróbálni, hogy az ős mondjuk egy Param object hintet használ, a gyerek pedig egy ParamChild-ot. Erre nem kaptam hibát. Ezután kipróbáltam a Te példád szerint (hogy a szülőnél nincs semmi meghatározva), szintén nem volt hiba. Ezután most gugliztam egyet, és ki is derült, hogy ez nem a PHP OOP model hiányossága, hanem egyszerű bug: http://bugs.php.net/bug.php?id=41461 -> http://news.php.net/php.internals/29646.


Üdv,
Felhő
36

Re:

w3net · 2007. Jún. 13. (Sze), 21.14
Szia,

kösz, hogy utánanéztél. Már értem mire gondoltál. Amit én akartam elérni az teljesen normális más nyelveken, mint például Java vagy C#. Csakhogy nem metódus felülirásról van szó, hanem method overloading-ról (túlterhelés). Ez azért lehetséges, mert egy metódust a szignatúrája (a metódus neve, a paraméterek száma és rendre a paraméterek típusai együtt) azonosít. Szóval a polimorfizmussal sincsen semmi gond, mert az átadott paraméterek száma és típusa alapján mindig a megfelelő metódus kerül végrehajtásra, egyszer a gyerek objektum specializált metódusa, egyszer a szülő objektumé.

Tehát most már értem és talán mások is, miért nem kóser PHP-ben, amit én akartam. Ahhoz method overloading kellene, ami sajna nincs és talán sosem lesz a PHP-ben.

Szerény véleményem szerint valóban E_STRICT kivételt kell dobnia a PHP-nek, mert ahogyan azt Te is irtad, gond lehetne a polimorfizmussal. Mindkét web cimet megnéztem, és őszintén szólva kicsit össze vagyok zavarodva.
Ha jól értettem a PHP nyelv tervezői szerint nem kell E_STRICT kivételt dobni??


Ez a kód a PHP szerint teljesen kóser:

error_reporting(E_STRICT | E_ALL);

class CollectionBase {
    public function addItem($newItem, $key = null) {
    }
}

class SurveyCollection extends CollectionBase {
    public function addItem(Survey $a, $key = null){
        parent::addItem($a, $key);
    }
}

class Survey {
}
Az alábbi kód (lásd interface-t) pedig már E_STRICT kivételt dob:
Strict Standards: Declaration of SurveyCollection::addItem() should be compatible with that of CollectionBase::addItem() in ...
<?php
error_reporting(E_STRICT | E_ALL);

class CollectionBase implements Countable{
    public function addItem($newItem, $key = null) {
    }
    public function Count(){
		return 1;
    }
}

class SurveyCollection extends CollectionBase {
    public function addItem(Survey $a, $key = null){
        parent::addItem($a, $key);
    }
}

class Survey {
}


$oSurvey = new Survey();
$o = new SurveyCollection();
$o->addItem($oSurvey,'s');
Az általad küldött bug szerint pedig a hiba az, hogy E_STRICT kivételt dob a fenti kód, mert a szülő objektum implementál egy interface-t. Akkor most kinek van igaza?


Még egy kis példa arra, hogy miért nem jó megváltoztatni a paraméterlistát, ha felüldefiniált kódról van szó:

class Emlos
{
  public function someFunc($one, $two)
  { }
}

class Kutya extends Emlos
{
  public function someFunc($uno)
  {  }
}

$o = new Emlos();
$o->someFunc("ss");
A kutya IS_A (ő egy) Emlős, ezért ha egy bizonyos kódnak egy Kutya példányt adunk át, de az csak Emlős-t ismer (azt sem tudja, mi az a Kutya), gond nélkül működnie kellene a kódnak.
De a PHP semmilyen figyelmeztetést nem ad nekünk, hogy a fenti kód nem szerencsés.


Megjegyzés:
- azért szeretem a C# -ot a Jávánál jobban, mert C#-ban mindig jelezni kell az override kulcsszóval, ha egy metódus felülirja az ős osztály ugyanilyen metódusát.
public override void AddItem(Survey2 obj, string strKey){
    this.m_strKey = strKey;
}
Üdv,
Attila
32

Pontosítás

puzzles · 2007. Jún. 13. (Sze), 12.21
Szia,

A Java-s példával kapcsolatban. Már egy ideje ugyan nem Java-zok, de ha jól tévedek, akkor Java-ban a metódusokat azok teljes szignatúrája (metódus neve + paraméterek típusa) azonosítja, így tehát amikor a SurveyCollection osztályban létrehozod az AddItem metódust, akkor az nem felüldefiniálja a szülő azonos nevű hívását, hanem overload-olja (túltölti?) azt. Így tehát a SurveyCollection osztálynak két AddItem metódusa lesz, és a paraméterek típusától függően fog eldőlni, hogy mikor melyik hívódik meg.

PHP-ban - a Java-val ellentétben - a hívásokat csak a függvény/metódus neve azonosítja, mivel a paraméterek kezelése itt teljesen másképp működik (elvileg ugye nem is muszáj deklarálni őket, mégis tudod a func_get_args(), stb. hívásokkal kezelni). Ilyen szempontból picit más szemlélet szükségeltetik az összehasonlításhoz.

Üdv,
Z
35

Method overloading

w3net · 2007. Jún. 13. (Sze), 20.31
Szia,
Igazad van Z. Ezt tényleg nem metódus felüldefiniálás volt. Valójában 2 AddItem nevű metódust hoztam létre.
Például C# nyelvben is a metódusokat azok teljes szignatúrája azonosítja.
Kösz a pontositást, már (majdnem) mindent tisztán látok.

Üdv,
Attila
38

Mono, projekt méret

moszinet · 2007. Jún. 22. (P), 18.56
Igen, az igaz, hogy mivel a JSP az jóval idősebb ezért talán bizonyos szinten jóval kiforrottabb is (lássuk be, egy halom .net-es portja van egy halom java-s dolognak).

Viszont azt hiszem, hogy az egyik nagy érv amivel egyetértek veled az tényleg az applikáció mérete... A licensz kiadások részével nem teljesen értek viszont egyet ugyanis már létezik Linux-ra is a MONO (az ASP.NET linux-os verziója), amit ha jól értettem folyamatosan fejlesztenek, és egész jó ?! (bár bevallom nem próbáltam még ki :) ... )
7

PHP

krey · 2007. Jún. 10. (V), 16.12
Azért a PHP-t sem kell rögtön elföldelni! Én azért szeretem a PHP, mert úgy érzem nagyon széles az a feladat-skála, amin alkalmazni lehet.
Kisebb és közepes projectekhez kiváló. Frameworkből is van hozzá 1000, de tudom, hogy lehet használni a .NET frameworkkel is.
A teljesítményre többen felhívták a figyelmet. Szerintem a legjobb eredményeket mindig a kompilált nyelvek fogják elérni, ezért is kísérletezem most kompilált PHP kódokkal.
Amúgy hogy a kérdésre is reagáljak, olcsóbb és több a közép és kis project, ezért.

üdv. krey

ps. azért nagy butaságokat ne írjunk, h a PHP őskövület, meghogy a JS üti, etc.
13

a lenázett php

szaky · 2007. Jún. 10. (V), 23.05
Ez a vita a "php vs egyéb nyelvek" -ről egen sokhelyen lezajlott, és szinte mindig hitvitába és flémbe torkollot. A php-nek sajnálatos módon van egy kis rossz mellékíze sokak szemében. És sajna tényleg igaz, hogy nagyon sok kezdő/rossz php-s van. És az is tény (szvsz) hogy php-ben könnyebb gány kódot írni, mint javában. És a sok java-dotnet guru csak ezt látja, és innen nehéz érvelni.
Szaky
15

windows vs nix

Peti_ · 2007. Jún. 11. (H), 00.00
Szakynak igaza van ez a téma mindig flémbe megy át. Ami mindig probléma, hogy ha vissza megyünk a györekhez. Az ASP azért mégis ms találmány, a php meg unix alapokra épül. Én személy szerint jobban alszok, ha a webszervermen egy jó bekonfigolt nix megy. A másik gond, amikor egy komplex alkalmazást akarnak létrehozni okos emberek pl. egy pénzügyi rendszert. Na erre nem való a php! Viszont webfejlesztére tökéletes.
23

php vs komplex alkalmazás

zila · 2007. Jún. 11. (H), 12.09
Miért nem való a php komplex pénzügyi rendszer fejlesztésre? Mondj olyan _nyelvi_ akadályt a php-ban ami kizárja, ilyen alkalmazás fejlesztését.
24

Szerver

janoszen · 2007. Jún. 11. (H), 12.15
Ebben részlegesen igaza van a t. hozzászólónak, ugyanis a PHP mint tudjuk, lekérésenként fut és jónéhány alkalmazásnak bizony szüksége van arra, hogy folyamatos kapcsolatot, kommunikációt, stb tudjon végezni, vagy még alacsonyabb szinten tudjon hozzányúlni a dolgokhoz. Viszont erre az ASP.NET sem alkalmas. Mindig a feladatnak megfelelően kell megválasztani az eszközt, nem fordítva.

Nyilván lehet PHP-vel pénzügyi alkalmazást írni, de ha csak a számlanyomtatást nézed, már problémába ütközöl, mert a PHP nem tudja ellenőrizni, hányszor nyomtatták ki a számlát. (ld. erről szóló viták korábban).
25

webes alkalmazás?

Hodicska Gergely · 2007. Jún. 11. (H), 12.40
de ha csak a számlanyomtatást nézed, már problémába ütközöl, mert a PHP nem tudja ellenőrizni, hányszor nyomtatták ki a számlát.
Szerintem semmilyen webes alkalmazás sem fogja tudni, hogy ellenőrizze a nyomtatást valamilyen plugin és jogosultság szint páros nélkül. Tehát ez nem igazán PHP vs egyéb témakör, hanem inkább webes vs desktop alkalmazás.


Üdv,
Felhő
27

Pont ezért

janoszen · 2007. Jún. 11. (H), 14.05
Pont ezért fontos, egy printszervert nem fogsz PHP-ban megírni. Elég egy szó szoros értelmében üzemeltetett webárúházra gondolni, máris ott a példa hogy miért kell...
33

hatásosabb?

virág · 2007. Jún. 13. (Sze), 12.29
Szia!

Hogyan lehet "hatásosabb" egy programozási nyelv? Esetleg hatékonyabb, de ne lovagoljunk a szavakon, valószínű egyre gondolunk :)

Én aktívan használok .NET-et, ASP.NET-et is és szerintem az egész ASP.NET bár hatékonynak tűnő "szörny", egyáltalán nem jobb mint a PHP. Sőt. Sokkal rosszabb... Az ASP.NET tele van pakolva komponensekkel és egy nagyon látványos eszköztárral (Visual Studio), van hozzá hipp-hopp használható Ajax-os alrendszer, van sablonrendszere (masterpédzses, konténeres) - és ezek valóban használhatók, ugyanúgy mint a cache megoldásai. Viszont egészében véve egy befejezetlen és nehézkes rendszert képeznek, nagy erőforrásigénnyel és a .NET minden előnyével, hátrányával és bogaraival. Próbálj pl. SharePoint alá fejleszteni vele meg fogsz őszülni záros határidőn belül...

Mindennek ellenére használható eszköz és használják is :)

Nekem a PHP egy megkönnyebülés és kreativitásra serkentő eszköz az ASP.NET mellett és sokkal szívesebben fejlesztek átlátható, szép oldalakat (értsd ezalatt: CSS validitás, XHTML validitás stb.) mert az MS cinikusan nem nagyon törődött ezekkel a dolgokkal, sőt ha elmész egy MS tanfolyamra és a validitást emlegeted, akkor megmosolyognak érte, de persze kiemelik, hogy a Firefoxxal már kompatibilis az új ASP.NET. :)

Az ASP.NET egyik nagy hiányossága, hogy egyáltalán nem törődik a "szép" kimenettel, persze megoldható benne a helyes és szabványos "végtermék", de egyáltalán nem könnyen és magától értetődően, értsd. a gyári vizuális komponensek nem törődnek ezzel, vagyis neked kell szenvedned... Ezen kívül az ASP.NET cache rendszere bár fejlett, de nem kellően egyensúlyozza a .NET kód lassúságát akkor, amikor először fut és felépíti az objektumokat...meg még sorolhatnám, de nem akarok ezzel senkit untatni, lényeg, hogy én mindkettőt használom rendszeresen, de nálam a PHP a majdnem tökéletes webes fejlesztőeszköz, jobb megoldással erre a célra én még nem találkoztam, gondolom nem véletlenül olyan népszerű mint amilyen.


Az ASP.NET erőssége abban rejlik, hogy a nem professzionális webes fejlesztők gyorsan összekattingathatnak benne ezt-azt, ez persze hatékony a nagyobb cégeknek és költségkímélő, a legtöbb helyen csakis ez a mérvadó és az MS pont ezt használja ki.

Ez persze nem jelenti azt, hogy ASP.NET-ben nem lehet szép és szabványos oldalakat gyártani! Ellenkezőleg! Sok példa van rá a neten, de ezeknek az előállítása már több hozzáértést igényel és nem lehet kizárólag egy csilli-villi fejlesztőeszközzel összetákolni! Vagyis, ugyanott leszel mint a PHP-nál: kódolnod kell ezerrel. :) Csak egy nehézkesebb környezetben, elveszítve a többplatformúság előnyeit és a nyílt forráskód szépségeit (és csúfságait is!).


kb. ennyi :)

PHP +1
34

MS folyóirat

Marcell · 2007. Jún. 13. (Sze), 17.05
Kb 3 hónapja olvastam egy MS belső folyóiratot és volt benne egy cikk az AJAX+ASP.NET kapcsolatáról, vagyis arról, hogy hogyan csináljunk olyat, abban. Pont mint amit Virág is mondott, hogy melyik komponenst hova dobáljuk be... mindezt úgy, hogy JS kód nem is volt benne. Biztos szép dolog ez, hogy Pistike kattint kettőt és máris ott van nesze AJAX, de azért nekem ez furcsa, hogy úgy akarnak egyesek tervezni (sőt, arra bíztatnak minket), hogy sejtelmük sincs, mi is fut a háttérben... Nyilván vannak olyan részek, amik elrejthetőek, de én jobban szeretem, ha a készülő honlap minden(!) egyes apró porcikáját betéve ismerem - vagyis magam írtam. Másrészt, ha nincsenek köszönő viszonyban az adott modullal, akkor a technikai lehetőségeit/korlátait sem ismerik, csak úgy kb tudják, melyik ikonra kell klikkolni...
39

Kérdés mrc-nek

moszinet · 2007. Jún. 22. (P), 18.58
Használtál te már bármilyen külső framework-ot PHP-hez amit nem te írtál :) ?
40

Nem.

Marcell · 2007. Jún. 22. (P), 22.05
Csak magamban bízok! :D Komolyra fordítva a szót, még nem volt olyan összetett weboldalam, ami megkövetelte volna, h ilyeneket használjak, úgyhogy én nem is hiányolom.
43

Méret a lényeg

moszinet · 2007. Jún. 24. (V), 20.59
Igen... végül is tényleg bármilyen hozzáállás ahhoz vezet, hogy a PHP-t általában kisebb projektekre használják ... Amúgy biztos vannak - nem értek eléggé hozzá:$ : vannak PHP-hez már kiforrot perzisztencia layer-ek, meg framework-ok ?
37

Hm... Kissé talán szubjektív a véleményed

moszinet · 2007. Jún. 22. (P), 18.36
Hát most ellentmondanék neked, viszont azt érzem, hogy úgyis felesleges ... :)
ÉN IS AKTÍVAN használom az ASP.NET-et egy kb 2000 fős cégnél ahol több tehnológia is megfordult már előttem ... (PHP, Perl, Java, Ruby, .NET) és annyit mondanék, hogy mielőtt "befejezetlennek" titulálsz egy tehnológiát talán kissé jobban merülj el benne :) ...

Amúgy meg elég érdekes válaszok jöttek a kérdésemre. Picit rettegtem attól, hogy nem azt fogják elmondani az emberek, hogy miért szeretik jobban a PHP-t, hanem szubjektív véleményt mondanak majd az ASP.NET-ről; viszont talán kissé érthető is ez ...

Ebben a kérdésben amit feltettem nem arra szerettem volna választ kapni, hogy miért gyengébb a PHP vagy az ASP.NET ...

PS. Az ASP.NET nem egy programozási nyelv. Az egy tehnológia ...
44

Egy válasz

BenGab · 2011. Szep. 26. (H), 07.40
Kicsit régen írok rá erre a témára, de én is fejlesztek PHP segítségével oldalakat, meg mostanában kezdtem bele az ASP.NET-be.

Igazából miért nem használják inkább az ASP.NET-et?
Azért nem használják annyian sajnos, mert sokan nem ismerik a C# nyelvet, a VB-t és a .NET keretrendszert, emellett semmilyen késztetést nem éreznek rá, hogy megtanulják. Sok olyan emberrel is találkoztam, akik PHP után belenéznek a C#-ba és máris ott is hagyják, a VB-vel dettó ugyanez és maradnak a PHP-nál.

A PHP egy igen egyszerű nyelv és nagyon cimborás, belegondolva abba, hogy változó típussal sem kell foglalkoznod, meg Kollekcióként elég a sima tömb is. Az ilyen könnyedségek miatt szeretik, csak sajnos amennyire könnyű, sokszor annyira is idegesítő tud lenni. Sokszor akadtam bele olyan problémába, hogy egy változó típusát nem jól kezeli (pl 10-ből kivontam 1-et és 99 lett az eredmény, típuskényszerítéssel meg nagyobb katasztrófa lett, voltak még hasonló gondok is).

A másik amit hiányolok, hogy az eseményvezérelt programozás benne nagyon fapados, szinte nem is tudja, inkább a Javascriptre bízták ezt (ez nagy hiba!).

Nagyobb projekteknél már hatékonyabb elővenni a .NET-et, de igaz PHP-ban is megvalósítható, csak több a macera.

A lényeg az, hogy azért nem használják igazán, mert a PHP programozók legtöbbje nem akar más nyelvet megtanulni.
45

Nem hiszem

Poetro · 2011. Szep. 26. (H), 10.18
Nem hiszem, hogy ez lenne az egyetlen indok. Szerintem a legfontosabb indok, hogy nincsen hol futtatni ASP.NET-et. Azaz ingyenes hosztingon nem tudod futtatni, mert nincs. Olcsóbb hoszting szervereken nincs. Ha olcsó akarsz maradni, akkor vagy bérelsz saját szervert, vagy pedig VPS-t, de a licenc költségek akkor is magasak, valamint neked kell szerezned egy rendszergazdát, aki karbantartja a Windows-od, vagy összehoz egy olyan Linux környezetet, ahol futtatható az ASP.NET kód. Ez mind nagyon drága. És Magyarországon amíg nem fognak megfizetni tisztességesen egy weboldalt, addig nem hiszem, hogy jelentősen változni fog ez a helyzet, hiába olyan szép nyelv a C# vagy az F#.
46

Számomra +1 indok, hogy ha

H.Z. v2 · 2011. Szep. 26. (H), 10.24
Számomra +1 indok, hogy ha nem a szerveren akarok desktopot futtatni/desktopon szervert, akkor drága is, mert plusz egy windows kell hozzá. PHP, java stb. esetében meg annyi linuxot telepítek, amennyi helyem van.
41

ehm

amonrpg · 2007. Jún. 23. (Szo), 09.24
Hitvitába nem fogok beleszólni, a véleményemet írom le.

A PHP szerintem egy kényelmes, kézreálló, igaz ilyen-olyan hasfájással megáldott (melyik nem?) nyelv.
Előnye az elterjedtsége. Nagy előnye.

Viszont mostanában kezdtem el nézegetni a C#-ot MONO-val. No. A PHP után szinte már felüdülés az OO készlet, amit ad. Mindent a fenék alá tol, cserébe persze kicsit le is korlátoz (a PHP-val viszonyítva). Ellenben ami nagyon fontos, az a C#-os thread-elés. Pl. Meg a nem elhanyagolható (a méréseink szerint) kb. 10x-es teljesítménybeli különbség a C#Mono javára. (Persze biztosan nem 100% a mérési eredmény, de elgondolkodtató).

Ja, és a Mono = .NET on Linux (aki esetleg nem tudná), azaz nem kell hozzá windows-os szerver.
42

már megint

szaky · 2007. Jún. 23. (Szo), 13.34
Már megint ez a php és .net (vagy jelenesetben mono) összehasonlítás. Mikor döbbentek már rá, hogy a php ugyanúgy nem tol semmit a fenék alá, mint mondjuk a c#. Nyelv != framework, vagy lib. Legalább akkor már a wact-al hasonlítsd össze, és akkor még értelme is van. Uram, irgalmazz!
47

csak hangosan gondolkodva

unregistered · 2012. Feb. 29. (Sze), 09.20
Senkit nem akarok kihívni szakmai vitára, de lehet hogy sokkal alapabb dolgok miatt "népszerűtlen" az ASP:

Pl lehet ok az hogy a windows szerver nem kicsi idegeskedéssel jár + e miatt sokkal drágább...

Aztán mit nevezünk nagy projektnek? Ha a világon kb 10, najó legyen 20% "nagy projekt" van akkor ez is egy korlátozó tényező... ugye egy darab fecske sem csinál tavaszt...

Aztán még itt lehez az ágyúval verébre eset is, hiába a frameworkök csúcsa az ASP... kérdés tényleg van-e értelme egy sima login formhoz?
48

Windows

Hidvégi Gábor · 2012. Feb. 29. (Sze), 10.01
Pl lehet ok az hogy a windows szerver nem kicsi idegeskedéssel jár + e miatt sokkal drágább...
Nekem tapasztalt rendszergazdák azt mondták, és olvastam is már pár helyen, hogy egy Windows-os szerver fenntartása nem drágább, mint egy Linuxosé, és ugyanolyan biztonságos, ez csak beállítás kérdése.
50

ellentét

unregistered · 2012. Feb. 29. (Sze), 11.18
Na az jó mert nekem pont ellentétesek a tapasztalataim :)

Márcsak ott drágább fenntartásnál, hogy a komplett OS frissítés/váltás pénz, bár ezzel máris kontrázhat bárki jogosan, hogy azért nem szokás OS-t cserélgetni évente a szervereken, úgyhogy ez szerintem sem mérvadó.

Na tehát vissza az elejére, amikor beindult itthon az OS X szerver képzés akkor igen sok win és linux (félreértés ne essék nem vagy-vagy hanem mindkét OS-hez nem kicsit értő) rendszergazda volt ott és kialakult egy kisebb vita UNIX (linux) vs WIN téren (nem stabilitás téren mert ott tényleg csak a szaktudás dönt hanem karbantartási téren): szüttyögősebb a win szerver buherelása bármit csinálsz. Ha több idő akkor azzal nem tudsz mit csinálni... a Cessna 172 is repül X óra szervizelés után és a Boeing 747 is repül csak 100 X óra szervizelés után... az idő meg ugye pénz. Természetesen itt (1 webszervernél) nem súlyos milliókról beszélünk, de amíg a linux szerverek vannak többen pláne ugye számunkra relevánsabb webszerver téren így nem tud olcsóbb lenni a szaktudás ez által az ASP hosting sem. Ebből pedig az következik hogy a piac a kisebb ellenállás irányába mozdul így mégnagyobbra nyitva az ollót.
52

Drágább

janoszen · 2012. Feb. 29. (Sze), 23.37
Ha kicsiben gondolkodsz, sokkal drágább és pont ezért nem tudnak sokan elindulni. Erre még rátesz egy lapáttal a Microsoft a licenc feltételeivel. Annó akartunk Windowsos VPS szolgátlatást indítani és mire megbeszéltük az említett társasággal rájöttünk, hogy abban az árkategóriában esélytelen. A tárhelyről nem is beszélve.
49

10 PRINT "Basic for ever!" 20

Karvaly84 · 2012. Feb. 29. (Sze), 10.06

10 PRINT "Basic for ever!"
20 GOTO 10
51

Optimalizálva:

Pepita · 2012. Feb. 29. (Sze), 22.21
10 ? "Basic for ever!"
20 RUN
53

Pont ma olvastam egy cikket

aky22 · 2012. Már. 4. (V), 20.52
Pont ma olvastam egy cikket Drága Billikénkről :D Ha jól emlékszem abban olvastam majdnem ugyanezt a kódrészletet. Kicsit más téma volt de a lényegi rész ugyanez volt :D