[PHP 5.0] Wat verwachten/hopen we ervan?

[Nielsz]

Ik hoop dat de classes in PHP dan verbeterd zijn.
- Overloading (meerdere functies met dezelfde naam, dus:
$blaat->createblaat();
$blaat->createblaat("test");


- Private & Public

(en nee, het is nog niet uit!)

Waar denken jullie dat de nadruk gaat liggen?

[Nielsz]

^^ kick ^^

[chem]

kick eens niet?

[Blue-eagle]

Kicken

Maarre, wat gaat er zoal veranderen dan? Ligt dat al vast of gaan we hier een potje gokken?

Ik hoop dat PHP met een eigen database komt. MySQL suckt imo.

[[]InTeR[]]

Wat ik in nieuwe php wil zien,

- Beter ondersteuningen in de bouwen van images.
- Snellere afhandeling van sql statements.
- mysql_pconnect er weer uitslopen. (traag).
- mischien iets met dynamische java aplets bouwen ofzo?
- betere timeout's en programma controle (progies blijven doorlopen).
- internet connectie naar andere site's beter (fopen("http: enz)

[Bigs]

Op donderdag 23 augustus 2001 11:13 schreef interwork het volgende:
- internet connectie naar andere site's beter (fopen("http: enz)

fopen("http: werkt nu ook al gewoon hoor.

[chem]

Op donderdag 23 augustus 2001 11:13 schreef interwork het volgende:
Wat ik in nieuwe php wil zien,

- Beter ondersteuningen in de bouwen van images.
- Snellere afhandeling van sql statements.
- mysql_pconnect er weer uitslopen. (traag).
- mischien iets met dynamische java aplets bouwen ofzo?
- betere timeout's en programma controle (progies blijven doorlopen).
- internet connectie naar andere site's beter (fopen("http: enz)

1. valt niet onder php;
2. valt niet onder php;
3. liever niet
4. te traag (maar wel leuk, al zou je het nu ook al kunnen)
5. werkt nu toch ook al?
6. zie punt 5

en een php sql database vind ik echt nergens op slaan... php is een SCRIPTINGTAAL en verder nix,...

[wasigh]

Op donderdag 23 augustus 2001 11:19 schreef chem het volgende:
4. te traag (maar wel leuk, al zou je het nu ook al kunnen)

Waarom zou dat te traag zijn?
Waarom zou je het willen eigenlijk? als je een goede applet bouwt hoef je alleen parameters te veranderen als je wilt dat je applet iets anders doet.

* wasigh begrijpt het nut niet..... (van realtime applets maken + compilen)

[stylee]

Blue-eagle: Ik hoop dat PHP met een eigen database komt. MySQL suckt imo.

rofl

heb jij er enig idee van hoeveel werk er in het ontwikkelen van een RDMS zit? Als je MySQL vind sucken neem dat eens hier een kijkje...

[chem]

Op donderdag 23 augustus 2001 11:22 schreef wasigh het volgende:

[..]

Waarom zou dat te traag zijn?
Waarom zou je het willen eigenlijk? als je een goede applet bouwt hoef je alleen parameters te veranderen als je wilt dat je applet iets anders doet.

* wasigh begrijpt het nut niet..... (van realtime applets maken + compilen)

pcies: je zou die applet elke keer moeten compilen en dat zou ik geen server willen aandoen... elke hit == applet compilen is niet snel (was beetje kortaf wellicht)

[mbravenboer]

chem: pcies: je zou die applet elke keer moeten compilen en dat zou ik geen server willen aandoen... elke hit == applet compilen is niet snel

Dat klopt uiteraard, maar het is ook gewoon onzin . Je gaat toch ook niet dynamisch PHP code genereren Je kan een applet gewoon parameterizeren met alle info die je maar wilt .

[mbravenboer]

Als PHP 1 ding nodig heeft, lijkt het mij wel goede XML ondersteuning. Een standaard, gebruiksvriendelijke DOM, goede parsers en wellicht zelfs XSL ondersteuning.

[chem]

jah, daar ben ik het helemaal mee eens. De huidige implementatie zuigt enorm.

wat ik verder wil zien; namespaces ; mult. inherited classes; overloading bij classes; het mag altijd nog sneller; een native template engine (wellicht via een .so ?) al valt dit ook enigzins buiten PHP's doel

verder nog ff denken...

[Nielsz]

Op donderdag 23 augustus 2001 11:33 schreef chem het volgende:

wat ik verder wil zien; namespaces ; mult. inherited classes; overloading bij classes; het mag altijd nog sneller; een native template engine

Dus ik ben niet de enige? Ik erger me er best aan. Je kan natuurlijk er om heen werken, maar dat is echt de bedoeling...

[wasigh]

de mogelijkheid scripts te compilen, generieke methoden om databases aan te spreken. Grote bibliotheken.
Type checking van variabelen (oftewel alles wat Java een mooie taal maakt )

[Verwijderd]

Kortom je wilt PHP.Net. zijn daar al plannen voor om php compatible te maken met het .Net framework trouwens?

[23m3]

Wat ik graag zou zien is een transparante databaselaag, dat je dus onafhankelijk van de achterliggende database (mysql, oracle, whatever) de database op dezelfde manier kunt benaderen. Ik weet wel dat er een ODBC-standaard is maar die is niet bepaald zaligmakend.
Zo'n laag mag van mij functies bieden om bijv. eenvoudig updates op de database uit te voeren zonder zelf een update-query te hoeven construeren.

Wat pseudocode:

$record->field->id = 5;
$record->field->naam = "pietsnot";
$record->update();

Nu heb ik zelf een class geschreven die dit (en nog veel meer) doet maar het lijkt me veel praktischer (en sneller) als zoiets 'onboard' PHP zit. ASP () heeft dus wel zoiets... da's dan ook het enige voordeel wat ik in ASP zie boven PHP, maar laat ik hier geen vlammetje opsteken

[chem]

je bedoelt een uitbreiding van DBA?

[chem]

Op donderdag 23 augustus 2001 11:41 schreef wasigh het volgende:
de mogelijkheid scripts te compilen, generieke methoden om databases aan te spreken. Grote bibliotheken.
Type checking van variabelen (oftewel alles wat Java een mooie taal maakt )

ja maar je moet PHP en Java niet vergelijken. De kracht van PHP is het totale gebrek aan typecasting etc. Dat je daardoor ook flink de stront in kan draaien is ook logisch. Je meot zelf zorgen voor het juist typeren van je variabelen (declareren helpt vaak).

Een optie 'php.ini.strcit = true;' zie ik wel zitten hoor... het heeft echt wel voordelen.

hier vind je de vorderingen en plannen van PHP zelf:
http://www.zend.com/zend/week/week49.php

edit: zend ziet het declareren van variabelen ook wel zitten:
http://www.zend.com/zend/zengine/zengine-issue4.php

[Nielsz]

http://www.zend.com/lists/php-dev/200108/msg00686.html

Dit is ook best interesting voor ons.
Het gaat over het een nieuw soort php, Secure PHP,
waarin alle open deuren in php dichtgezet zijn.

[chem]

mwach, ik zie weinig problemen in de huidige PHP.

iig voorkom je door de bestaande PHP dat je vertrouwt op diens' beveiliging. Je kan simpelweg NOOIT op een variabele vertrouwen zomaar, dus zorg je ook voor typecasting en andere praktijken.

Ik zie dit meer als een eigenschap van PHP dan een nadeel..

[Nielsz]

Op donderdag 23 augustus 2001 12:32 schreef chem het volgende:
mwach, ik zie weinig problemen in de huidige PHP.

iig voorkom je door de bestaande PHP dat je vertrouwt op diens' beveiliging. Je kan simpelweg NOOIT op een variabele vertrouwen zomaar, dus zorg je ook voor typecasting en andere praktijken.

Ik zie dit meer als een eigenschap van PHP dan een nadeel..

Ik denk dat veel mensen compleet vertrouwen hebben in PHP. Had ik ook in het begin. Het zou handig zijn als ze de beveiliging omdraaien: Ipv alles opendoen en dichtzetten wat je wil, alles dichthouden en zet dan maar open wat je nodig hebt.
Daarmee creer je een omgeving waar de mensen wel na MOETEN denken over beveiliging e.d.

[mbravenboer]

chem: ja maar je moet PHP en Java niet vergelijken.

Ik zou niet weten waarom niet . Het zijn allebei programmeertalen er er zijn zelfs veel probleemgebieden waarbij je kan kiezen dus PHP of Java.

De kracht van PHP is het totale gebrek aan typecasting etc.

Ik vraag me af of dat de kracht van PHP is. Sinds een maandje gebruik ik de geparameterizeerde compiler van Java (wordt waarschijnlijk volgend jaar officieel geintroduceerd) en ik kan me niet meer herrinneren dat ik sindsdien een cast geschreven heb .

Je meot zelf zorgen voor het juist typeren van je variabelen (declareren helpt vaak).

Eerlijk gezegd neem ik een taal zonder typering, declaraties en type-checking voor run-time niet erg serieus. Ik denk dat zo'n taal interessante toepassingen kent, maar nooit als robuust bekend zal worden.

zend ziet het declareren van variabelen ook wel zitten

Lijkt me een goed plan .

[Verwijderd]

ik wil dat je je scripts kunt compileren zodat je niet je code weg hoeft te geven
en ja ik weet dat het al bestaat

[chem]

mbravenboer> je hebt wel gelijk... in het begin kan je een app heel snel opzetten omdat het er geen kont toe doet wat je variabelen voor type zijn etc.
Nadeel is dat je des te meer kwijt bent in het sluiten/beveiligen van je app. nielsz zei dat al: mensen vertrouwen op PHP. Ik vermoed echter dat als iemand het concept van ongebreidelde input van de user niet goed snapt (en de problemen die erbij horen) dat zo iemand toch wel een lek creert (bv. files openen en weergeven op basis van userinput zonder switchcase of andere begrenzing)

iig is PHP nog lang niet met Java te vergelijken al wordt het meer en meer mogelijk 'echte' applicaties te bouwen in PHP. Echter de laatste stap naar volwassenheid hiervoor ontbreekt voor mijn gevoel.

Een variant van PHP die je 'strict' kan zetten lijkt me geweldig. Dan nog overloading erbij, DBA verder uitgewerkt etc. etc. en vooral het (gratis/goedkoop) compilen van je code (al dan niet realtime dus eerst de boel door een compiler halen elke keer) en we komen al een stuk verder.
PHP blijft een geweldige taal hoor

[chem]

hmzzz waarom ga ik niet over op Java?

jah nou daar moet ik weer eens goed over nadenken hehehe grootste probleem is het gebrek aan servlet support bij m'n hoster... en heb al ZO lang niets met Java gedaan... maar goed we hadden het over PHP

[Verwijderd]

Op donderdag 23 augustus 2001 12:58 schreef chem het volgende:
maar goed we hadden het over PHP

jah man blijf nou eens voor 1 keer on-topic

[Nielsz]

Op donderdag 23 augustus 2001 12:01 schreef chem het volgende:

[..]

hier vind je de vorderingen en plannen van PHP zelf:
http://www.zend.com/zend/week/week49.php

Hehe, ik ff kijken. Vraagt een collega welke week het is:
"Week 49" euh...

En nu weer echt ontopic

[Verwijderd]

mbravenboer

PHP *heeft* support voor XML, dmv zowel de SAX (event-based) methode als de DOM methode. (--with-dom)
PHP heeft ook support voor XSLT.. (dmv Sablotron)..


voor het 'taal deel' (Zend):

Wat ik zelf graag zou zien in PHP is standaard stacktraces
het zooitje in de soeP loopt, zoals python dat heeft..
(heb al gehoord dat dat mogelijk in zend2 komt)

voor het 'overige deel' (PHP):

Betere support voor Virtual Hosting, er moet toch wel
iets aan te doen zijn.. blergh.

edit:
mjah, iets logischer misschien

[Verwijderd]

Trouwens
voor de plannen van de volgende versie van Zend Engine
kan je lezen op http://www.zend.com/zend2/

edit:

wrong url

[chem]

Op donderdag 23 augustus 2001 13:05 schreef Nielsz het volgende:

[..]

Hehe, ik ff kijken. Vraagt een collega welke week het is:
"Week 49" euh...

En nu weer echt ontopic

't is week 33 hoor, maar goed.

PHP:

<?
echo strftime('%U');
?>

[[eNeRGy]]

Op donderdag 23 augustus 2001 11:13 schreef Blue-eagle het volgende:
Ik hoop dat PHP met een eigen database komt. MySQL suckt imo.

Ehm, waarom zou PHP een eigen database bouwen?

Je kan nu al bijna elke DB aan PHP koppelen!

- Oracle
- MSQL / Sybase
- mySQL
- etc..

(ehm er staat wel ergens zo'n lijstje )

[Apache]

[newbiemode]
ik wil zo een forum kunnen maken
<?
echo forum();
?>


[/newbiemode]

ff on-topic, voor mij hoeft er zoveel niet veranderd te worden, er zijn weinig dingen die mij aan de huidige versie storen of die ik echt nodig heb, ik zou php5 enkel draaien als hij echt veel sneller zou zijn

[Blue-eagle]

Op donderdag 23 augustus 2001 11:25 schreef stylee het volgende:
Blue-eagle: Ik hoop dat PHP met een eigen database komt. MySQL suckt imo.

rofl

heb jij er enig idee van hoeveel werk er in het ontwikkelen van een RDMS zit? Als je MySQL vind sucken neem dat eens hier een kijkje...

Of het veel werk is boeit me totaal niet. Waarom wel eigenlijk?
Het gaat me erom dat er een keer een gratis goede database komt (zoals oracle) die snel is en alles kan.

Ik heb liever MsSQL dan MySQL.

[Verwijderd]

PostgreSQL, Interbase
..


Oogkleppies af doen maat

[Blue-eagle]

Op donderdag 23 augustus 2001 16:47 schreef Kepz het volgende:
PostgreSQL, Interbase
..


Oogkleppies af doen maat

Meer wordt er hier niet ondersteund

Daarbij, PostgreSQL is toch gewoon een variant van MySQL, met een iets groter scala aan mogelijkheden.

Misschien leuk voor een aparte topic. Deze discussie over databases.

[Verwijderd]

PHP 4.1 of 5.0 is op het moment onder ontwikkeling.
Deze zal komen met Zend Engine 2 welke voor een heel groot deel weer herschreven is.

PHP zal intern meer op Java lijken, (Object Handles oid).
Direct gevolg hiervan is dat PHP qua OO veel sterker word
dan het op het moment is.
Dit zal mogelijk worden:

<?php

$object_1 -> methode() -> eigenschap;

?>

Ook komen er kleinere dingetjes om stomme bugjes te verhelpen zoals:

<?php
echo $string{4}; // ipv $string[4]
?>
(sterker nog, dit is er al)
Dit om problemen met arrays en loose-typing op te lossen.

Nogmaals, dit is allemaal te vinden in de "Zend Engine 2 Draft":
http://www.zend.com/engine2/

[Verwijderd]

PostgreSQL een variant van MySQL?
Postgres95 bestond al voor dat Monty ook maar dacht aan
een database te maken!

PostgreSQL is veel meer gerijpt dan MySQL. Een *ERG*
kortzichtige reactie. PostgreSQL heeft native transactions, rules, constraints en stored procedures. Geen "addon-table-handlers" als MySQL.



Heb je het ooit wel eens gebruikt?

edit:

haha, je hebt duidelijk op de verkeerde tene gestaan

[Nielsz]

Op donderdag 23 augustus 2001 16:51 schreef Kepz het volgende:


<?php
echo $string{4}; // ipv $string[4]
?>

Dit laat dus het 4e character zien? Dat zou wel beter zijn
Maar eigenlijk is een string toch ook een array??

[Verwijderd]

Een string is "per definitie" een 'array' van characters.
Maar in intern in PHP zijn er zeer duidelijke verschillen
tussen een Array en een String.

<?php
echo $string{4}
?>

werkte overgens al in PHP 4.0.5RC6.

Om nog even op je 1e post terug te komen niels, Overloading is mogelijk, al is het niet officieel overloading.

<?php

class bla {
function muu() {
$num_args = func_num_args();
$args = func_get_args();

switch ($num_args) {
case 0:
/* $object->muu() */
echo "No args!";
break;
case 2:
/* $object->muu("arg2", $arg2);
break;
default:
trigger_error(E_WARNING, "onjuist aantal parameters in bla::muu()");
return false;
}
}
}

Zoals je ziet kan je zo bereiken wat jij wou.
Mgoed, misschien wist je het al, dan hopelijk een les voor anderen.

[Verwijderd]

PHP neigt in de nieuwe versie steeds meer naar een web-based java (of c++) variant valt mij op. Het begon als een soort versimpelde C, waar het op een gegeven moment was object in te bouwen (omdat dat zoveel gevraagd werd). Nu gaan ze zelfs de try en catch erin gooien, verder zaten er veel dingen als object extending mbv 'extend' er ook al in. Ook kun je variabelen gaan declareren. What's next? zou ik zeggen. Het wordt zo'n beetje een jsp variant waar embedded code wel 'done' is.

Op zichzelf geen slechte ontwikkeling, maar het viel me gewoon op

[brammetje]

Op donderdag 23 augustus 2001 16:56 schreef Nielsz het volgende:

[..]

Dit laat dus het 4e character zien? Dat zou wel beter zijn
Maar eigenlijk is een string toch ook een array??

de 5e natuurlijk heh...

maar ok, iedereen maakt fouten

[mbravenboer]

devel: Op zichzelf geen slechte ontwikkeling, maar het viel me gewoon op

Geen commentaar, gewoon geinteresseerd: wat zijn dan nog de voordelen van PHP boven Java (of C#)? (Behalve dat er meer hosting is voor PHP )

[Verwijderd]

Het mooie is wel dat je niet perse die objecten-zooi hoeft te gebruiken. Let wel, dat in dat Zend Engine 2 draft, vooral over de Internals wordt gepraat. De praat over dat PHP op Java zal gaan lijken in z'n internals merk je dus amper als end-gebruiker.

PHP lijkt me meer op C++ dan op Java (qua gebruiker), je kan *en* functioneel programmeren *EN* object georienteerd.
Dat is toch de beste keuze?
Anders fork je zend engine en sloop je al de object code er uit

[Nielsz]

Op donderdag 23 augustus 2001 17:11 schreef PlayR het volgende:

[..]

de 5e natuurlijk heh...

maar ok, iedereen maakt fouten

ik wou eerst de 3e zeggen, maar ik dacht, neuh, het zal wel de 4e zijn... me .. tired .. go .. to .. sleep

[chem]

Op donderdag 23 augustus 2001 17:11 schreef mbravenboer het volgende:

[..]

Geen commentaar, gewoon geinteresseerd: wat zijn dan nog de voordelen van PHP boven Java (of C#)? (Behalve dat er meer hosting is voor PHP )

vooral de hosting is belangerijk, maar de laagdrempeligheid voor de newbie is belangerijk voor PHP. Als er meer en meer Java/servlet hosting komt des te meer users daar mee gaan werken. Op dit moment waag ik me er niet aan want ik heb geen zin om weet-ik-hoe-lang bezig te zijn met de installatie...

[Verwijderd]

en de taal is natuurlijk *VEEL* makkelijker te lere
je hoeft niet ik-weet-niet-hoeveel classes te importeren
voor "Hello World"

(Misschien is dat nie meer zo, don't pin me down on it
Ben absoluut geen java expert )

[mbravenboer]

Kepz :Het mooie is wel dat je niet perse die objecten-zooi hoeft te gebruiken.

Wat is dan het voordeel ten op zicht van Python (wat naar Java bytecode kan compileren?

Let wel dat in dat Zend Engine 2 draft, vooral over de Internals wordt gepraat. De praat over dat PHP op Java zal gaan lijken in z'n internals merk je dus amper als end-gebruiker.

Waarom PHP eigenlijk niet naar Java bytecode compileren? Dan draait het gelijk onder elk platform, het zal sneller draaien en de OO engine is al beschikbaar.

PHP lijkt me meer op C++ dan op Java (qua gebruiker), je kan *en* functioneel programmeren *EN* object georienteerd.

Ik zou het geen functioneel programmeren willen noemen (dat kan je ook niet in C++), maar dit is wel een goed argument. Vergelijk het nu dan eens met Python?

[mbravenboer]

Kepz:en de taal is natuurlijk *VEEL* makkelijker te leren. Ke hoeft niet ik-weet-niet-hoeveel classes te importeren voor "Hello World"

Voor de Java Hello World hoef je helemaal niets te importeren... dus...

(Misschien is dat nie meer zo, don't pin me down on it
Ben absoluut geen java expert )

Ik doe het lekker toch . Dit is ook nooit anders geweest.

[Verwijderd]

Uhm..

het aantal extensies dat php heeft tov python
(veel duidelijker als je het mij vraagt).
mod_php4 verslaat mod_snake *by far*

de taal is wederom *makkelijker*

Mgoed, Python is ook cool :-)

en over die helloworld
I doubt wether it'd beat <?="Hello World!"?>

*LEKKER LEKKER PUH*
*tong uitsteek*

[Michael]

Het zou leuk zijn als php5 niet backwards compatible is met php3/4..

En dat meen ik serieus, volgens mij kan php veel sneller als ze code removen die moet zorgen dat het backwards compatible blijft met oude php code

[chem]

Op donderdag 23 augustus 2001 17:32 schreef Kepz het volgende:
Uhm..

het aantal extensies dat php heeft tov python
(veel duidelijker als je het mij vraagt).
mod_php4 verslaat mod_snake *by far*

de taal is wederom *makkelijker*

Mgoed, Python is ook cool :-)

python is ook jonger...
mbravenboer is java-adept bij uitstek. Ik zie de positieve punten van Java ook wel maar zie geen reden over te stappen: herschrijven van alle libs 'n tricks gaat dermate lang duren dat ik dat niet in de tijd van de baas kan doen met alle deadlines. Ik wil me er wel aan wagen maar dan mag iemand servletsupport op m'n slackbak gaan gooien; ik niet iig

En komen we toch weer terug op de hosting...

En als we PHP met andere talen gaan vergelijken dan is er nog wel een waslijt;
php, perl, asp (alle talen daarin), perl, zope, python, java, applescript, c, c++, c#, pascal, delphi... beuhhh zo kunnen we wel even doorgaan!

[chem]

Op donderdag 23 augustus 2001 17:36 schreef Michael het volgende:
Het zou leuk zijn als php5 niet backwards compatible is met php3/4..

En dat meen ik serieus, volgens mij kan php veel sneller als ze code removen die moet zorgen dat het backwards compatible blijft met oude php code

nee daar maak je vrienden mee

[Verwijderd]

Op donderdag 23 augustus 2001 17:11 schreef mbravenboer het volgende:

[..]

Geen commentaar, gewoon geinteresseerd: wat zijn dan nog de voordelen van PHP boven Java (of C#)? (Behalve dat er meer hosting is voor PHP )

Precies, het is de hosting. Verder niet, er zijn volgens mij alleen nadelen. Of servlets/jsp nou meer of minder geheugen/cpu kracht vreten dan php is me nog steeds niet helemaal duidelijk geworden (geen benchmarks oid gezien), dus over de performance kan ik niks zeggen, maar is wel erg belangrijk.

/me is qua taal een java voorstander, maar elke taal moet een kans krijgen toch?

[ACM]

Op donderdag 23 augustus 2001 17:37 schreef chem het volgende:
nee daar maak je vrienden mee

Ach, opzich lijkt een compile-parametertje (-DHAVE_BACKWARDS_COMPATIBILITY) me wel geinig

Maar dat toevoegen aan de code, zal het er niet beter op maken

[ACM]

Op donderdag 23 augustus 2001 17:37 schreef chem het volgende:
python is ook jonger...

Dan php?
*kuch*

code:

[acm@vulcanus acm]$ python
Python 1.5.2 (#1, Mar  3 2001, 01:35:43)  [GCC 2.96 20000731 (Red Hat Linux 7.1 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>

PHP was conceived sometime in the fall of 1994 by Rasmus Lerdorf. Early non-released versions were used on his home page to keep track of who was looking at his online resume. The first version used by others was available sometime in early 1995 and was known as the Personal Home Page Tools.

[tomato]

Ok, ik wilde me er eerst buiten houden, maar kan me niet inhouden, er werden zulke grappige opmerkingen gemaakt

Op donderdag 23 augustus 2001 08:29 schreef Nielsz het volgende:
Ik hoop dat de classes in PHP dan verbeterd zijn.
- Overloading (meerdere functies met dezelfde naam, dus:
$blaat->createblaat();
$blaat->createblaat("test");

Dit kan al, maar ik geef toe dat het nog niet op een mooie manier kan. Built-in functies zijn ook niet te overloaden en bijv een operator overloaden hoef je ook niet te proberen.

- Private & Public

Hmmm ja, maar dan zijn er nog wel wat dingen te noemen die je mist in OOPHP.

Waar denken jullie dat de nadruk gaat liggen?

Ik hoop op dingen als betere XML support, betere socket functies, variabelen declaraties (liefst naar keuze, kinda like 'option explicit' in VBScript), verbeterde regular expression support, logischer en helderder taalstructuur en namespaces, etc.

Op donderdag 23 augustus 2001 11:13 schreef Blue-eagle het volgende:
Ik hoop dat PHP met een eigen database komt. MySQL suckt imo.

Euhh, moet ik hier nog op in gaan? Geloof dat er al genoeg op deze flame gereageerd is

Op donderdag 23 augustus 2001 11:41 schreef wasigh het volgende:
de mogelijkheid scripts te compilen

Kan al een beetje, maar niet echt leuk inderdaad.

, generieke methoden om databases aan te spreken.

Tsja... er bestaan ondertussen al duizenden db abstraction layers volgens mij, maar built in zou mooi zijn. Probleem is alleen dat iedere dbm anders is, en dit dus best wel lastig wordt (wie vindt ODBC perfect?), maar inderdaad, zoals het nu is is het best ranzig.

Grote bibliotheken.

Het moet iig makkelijker worden om deze te maken.

Op donderdag 23 augustus 2001 12:01 schreef chem het volgende:
hier vind je de vorderingen en plannen van PHP zelf:
http://www.zend.com/zend/week/week49.php

Andi Gutmans and Zeev Suraski have completed one of the major remaining items on the TODO list for PHP 4.0.7. The $HTTP_*_VARS arrays are now available as $_* (eg. $_GET, $_POST) and are a new kind of global variable.

Willen ze toch weer perlish gaan doen. PHP zal altijd een vreemd taaltje blijven imho, rondzwevend ergens in de doelgroep waar ook perl populair zou kunnen zijn of is en af en toe lijkt het juist een slap aftreksel van datzelfde perl (wat met perl 6 trouwens een geweldige taal neer gaat zetten). Vreemdgenoeg heeft PHP toch kans gezien de harten van zovelen (former) nieuwbies te veroveren. Zonder de lage opstapdrempel was dat denk ik nooit gelukt.

Op donderdag 23 augustus 2001 12:36 schreef Nielsz het volgende:
Ik denk dat veel mensen compleet vertrouwen hebben in PHP. Had ik ook in het begin. Het zou handig zijn als ze de beveiliging omdraaien: Ipv alles opendoen en dichtzetten wat je wil, alles dichthouden en zet dan maar open wat je nodig hebt.
Daarmee creer je een omgeving waar de mensen wel na MOETEN denken over beveiliging e.d.

Wat betreft het blindelinge vertrouwen van veel mensen heb je wel gelijk, maar imho ligt dat niet aan PHP, maar aan de gebrekkige programmeerkennis en -ervaring van deze mensen zelf.

Op donderdag 23 augustus 2001 12:56 schreef chem het volgende:
nielsz zei dat al: mensen vertrouwen op PHP. Ik vermoed echter dat als iemand het concept van ongebreidelde input van de user niet goed snapt (en de problemen die erbij horen) dat zo iemand toch wel een lek creert (bv. files openen en weergeven op basis van userinput zonder switchcase of andere begrenzing)

Ik zie dat in vrijwel iedere programmeertaal nog wel gebeuren eigenlijk.

iig is PHP nog lang niet met Java te vergelijken al wordt het meer en meer mogelijk 'echte' applicaties te bouwen in PHP. Echter de laatste stap naar volwassenheid hiervoor ontbreekt voor mijn gevoel.

Ik denk dat PHP ook niet deze ambities zou moeten hebben. Het is een harstikke leuke tool voor kleine en grotere oplossingen, maar je moet van een mesje geen Swiss Armyknife (tm) willen gaan maken. Pak dan gewoon een bestaand .. (tm).

Op donderdag 23 augustus 2001 12:58 schreef chem het volgende:
hmzzz waarom ga ik niet over op Java?

Doe het in ieder geval niet omdat mbravenboer het zegt

Op donderdag 23 augustus 2001 16:31 schreef Apache het volgende:
ff on-topic, voor mij hoeft er zoveel niet veranderd te worden, er zijn weinig dingen die mij aan de huidige versie storen of die ik echt nodig heb, ik zou php5 enkel draaien als hij echt veel sneller zou zijn

Iedereen stapt toch wel over op PHP5 als het er eenmaal is, het gebeurt toch wel.

Op donderdag 23 augustus 2001 16:45 schreef Blue-eagle het volgende:
Of het veel werk is boeit me totaal niet. Waarom wel eigenlijk?
Het gaat me erom dat er een keer een gratis goede database komt (zoals oracle) die snel is en alles kan.

Ik heb liever MsSQL dan MySQL.

Lees je eigen reactie nou nog eens door. Je wilt alles voor weinig (of zelfs gratis!). Liever heb je MSSQL dan MySQL, maar MSSQL is allesbehalve gratis!
En als je vindt dat er gratis commercieel gebruik gemaakt zou moeten mogen worden van een product als Oracle heb je echt oogkleppen op imho (voor niet-commercieel gebruik is er overigens al genoeg te vinden bij Oracle).

Op donderdag 23 augustus 2001 16:51 schreef Blue-eagle het volgende:
Daarbij, PostgreSQL is toch gewoon een variant van MySQL, met een iets groter scala aan mogelijkheden.

Vannuh... oja

Misschien leuk voor een aparte topic. Deze discussie over databases.

Hmmm, doe maar niet

Op donderdag 23 augustus 2001 16:56 schreef Nielsz het volgende:
Maar eigenlijk is een string toch ook een array??

Ja, per definitie natuurlijk wel, maar voor jou is een string in PHP iets heel anders dan een array. Er mogen dan enkele 'array-features' zijn die ook op een string passen, maar daar houdt het dan ook op. Het is geen C.

Op donderdag 23 augustus 2001 17:11 schreef mbravenboer het volgende:
Geen commentaar, gewoon geinteresseerd: wat zijn dan nog de voordelen van PHP boven Java (of C#)? (Behalve dat er meer hosting is voor PHP )

* leercurve
* installatiegemak (en hosting gemak)
* grotere community (vooral ook voor newbies
* kosten (tov C#)
* rompslomp van overstappen (in het geval je al PHP kennis hebt)
* gemakkelijk als 'OS-tooltje' te gebruiken, a la perl

Al met al inderdaad maar weinig voordelen die echt aan de omgeving zelf te danken zijn en ook na 1 jaar nog belangrijk zijn.

Op donderdag 23 augustus 2001 17:17 schreef chem het volgende:
Op dit moment waag ik me er niet aan want ik heb geen zin om weet-ik-hoe-lang bezig te zijn met de installatie...

Inderdaad, ook de moeite van het verdiep in de nieuwe omgeving, hem opzetten, etc (voor mij de belangrijkste reden dat ik hier nog geen Servlets heb geprobeerd).

Op donderdag 23 augustus 2001 17:26 schreef mbravenboer het volgende:
Wat is dan het voordeel ten op zicht van Python (wat naar Java bytecode kan compileren?

Zojuist genoemde punten daargelaten zie ik het voordeel ook steeds minder. Want ook als 'tooltje' leent Python zich uitstekend, Python rulez (flame ).

Waarom PHP eigenlijk niet naar Java bytecode compileren? Dan draait het gelijk onder elk platform, het zal sneller draaien en de OO engine is al beschikbaar.

Welk voordeel van PHP boven Java blijft er dan nog staan? Ik denk niet dat het PHP devteam hier veel in ziet

Op donderdag 23 augustus 2001 17:32 schreef Kepz het volgende:
het aantal extensies dat php heeft tov python
(veel duidelijker als je het mij vraagt).

Ik begrijp niet helemaal wat je hiermee bedoelt. Vergelijk het op dit gebied trouwens ook eens met perl.

mod_php4 verslaat mod_snake *by far*

mod_snake is ook iets *heel* anders dan mod_php4 en daarnaast heb je ook nog gewoon mod_python.

de taal is wederom *makkelijker*

Als we zo doorgaan komen we nog tot de conclusie dat PHP eigenlijk het open-source VBScript is

De syntax (die veel mensen zo lekker makkelijk vinden van PHP), is natuurlijk ook maar een klein onderdeel van de taal en imo een tot op zekere hoogte erg onbelangrijk onderdeel. Als je je aan de hand van de syntax vast pint op een taal (wat veel newbie's, niet geheel onbegrijpelijk, doen) zou je eigenlijk even moeten wachten op perl 6, waarin de syntax compleet los komt te staan van de rest van de engine en standaard support aanwezig zal zijn voor Python, Java en legacy perl syntax.

Op donderdag 23 augustus 2001 17:36 schreef Michael het volgende:
Het zou leuk zijn als php5 niet backwards compatible is met php3/4..

Dit zou inderdaad veel voordelen hebben, maar te veel nadelen. Als ze eens tijd over hebben in het devteam, moeten ze eens gaan kijken naar de mogelijkheden om backward compatibility optioneel te maken (eventueel tijdens compilen).

Op donderdag 23 augustus 2001 17:42 schreef devel het volgende:
Of servlets/jsp nou meer of minder geheugen/cpu kracht vreten dan php is me nog steeds niet helemaal duidelijk geworden (geen benchmarks oid gezien), dus over de performance kan ik niks zeggen, maar is wel erg belangrijk.

Toch niet zo erg belangrijk imho.

Ik hoop dat er nog een fijn flamefest volgt

[mbravenboer]

devel: Precies, het is de hosting.

En dat vind ik nu juist het vreemde... Ik kan me haast niet voorstellen dat PHP efficienter met systeembronnen omgaat dan Java. Java Servlets moeten gewoon sneller zijn dan PHP. Ik begrijp daarom ook niet waarom er maar zo weinig servlet hosting wordt aangeboden. Is er geen vraag naar?

[mbravenboer]

chem: mbravenboer is java-adept bij uitstek. Ik zie de positieve punten van Java ook wel maar zie geen reden over te stappen: herschrijven van alle libs 'n tricks gaat dermate lang duren dat ik dat niet in de tijd van de baas kan doen met alle deadlines. Ik wil me er wel aan wagen maar dan mag iemand servletsupport op m'n slackbak gaan gooien; ik niet iig

Wijze woorden .

[mbravenboer]

Kepz: de taal is wederom *makkelijker*

Dat is nogal subjectief. Ik vind een zwak-getypeerde taal bijvoorbeeld moeilijker dan een sterk-getypeerde taal. Dit kan je dus niet als universeel argument aandragen.

en over die helloworld
I doubt wether it'd beat <?="Hello World!"?>

Dit is natuurlijk onzin. Hier verdacht weinig PHP code aan te pas. In JSP zou je vrijwel hetzelfde kunnen schrijven. Ik twijfel er echter niet aan dat PHP in gevallen kortere code op zal leveren dan dezelfde code in Java.

[ACM]

Op donderdag 23 augustus 2001 18:29 schreef tomato het volgende:
Euhh, moet ik hier nog op in gaan? Geloof dat er al genoeg op deze flame gereageerd is
[..]
Zojuist genoemde punten daargelaten zie ik het voordeel ook steeds minder. Want ook als 'tooltje' leent Python zich uitstekend, Python rulez (flame ).

Even een klein terminologisch geheel, laten we die dingen maar Trolls noemen

Flame is eigenlijk altijd negatief, maar 'linux rulez', 'java rulez', 'c++ sucks' etc, zijn in principe trolls dacht ik zo.

[mbravenboer]

tomato: er werden zulke grappige opmerkingen gemaakt

Leuk dat je meedoet .

Tsja... er bestaan ondertussen al duizenden db abstraction layers volgens mij, maar built in zou mooi zijn. Probleem is alleen dat iedere dbm anders is, en dit dus best wel lastig wordt (wie vindt ODBC perfect?), maar inderdaad, zoals het nu is is het best ranzig.

JDBC voor PHP zou leuk zijn .

Doe het in ieder geval niet omdat mbravenboer het zegt

Tsss, ik vond net dat ik resultaat aan het boeken was .

Al met al inderdaad maar weinig voordelen die echt aan de omgeving zelf te danken zijn en ook na 1 jaar nog belangrijk zijn.

En dat vind ik eigenlijk wel een probleem. PHP is erg toegankelijk, maar als je eenmaal toegang tot PHP hebt zijn er weinig nieuwe voordelen meer.

Welk voordeel van PHP boven Java blijft er dan nog staan? Ik denk niet dat het PHP devteam hier veel in ziet

Dat zijn er toch nog wel aardig wat:
* leercurve
* grotere community (vooral ook voor newbies
* kosten (tov C#)
* rompslomp van overstappen (in het geval je al PHP kennis hebt)

Bovendien is het voor de ontwikkelaars van PHP een groot voordeel. Ze krijgen gratis en voor niks een perfecte omgeving aangeboden.

Nieuwe voordelen zijn bovendien:
* Performance winst
* OO functies triviaal te implementeren
* Te draaien op elk Java platform
* Toegang tot de bibliotheken van Java -> JAXP en JDBC bijvoorbeeld

Als we zo doorgaan komen we nog tot de conclusie dat PHP eigenlijk het open-source VBScript is

Hehe .

Ik hoop dat er nog een fijn flamefest volgt

Ik doe m'n best .

[Verwijderd]

[beetje off-topic]
Hoewel het volgens tomat niet erg belangrijk is, ben ik toch wel erg benieuwd naar de performance verschillen tussen php en java servlets dan wel jsp. Is daar ooit onderzoek naar gedaan?
[/beetje off-topic]

[tomato]

Op donderdag 23 augustus 2001 19:03 schreef devel het volgende:
[beetje off-topic]
Hoewel het volgens tomat niet erg belangrijk is, ben ik toch wel erg benieuwd naar de performance verschillen tussen php en java servlets dan wel jsp. Is daar ooit onderzoek naar gedaan?
[/beetje off-topic]

Altijd lastig, dat soort benchmarks. Want wat wil je precies vergelijken? Maar het antwoord wat je wilt horen is waarschijnlijk dat servlets na 1 keer runnen sneller zijn en de complete applicatie zal schaalbaarder zijn.

[Verwijderd]

Op donderdag 23 augustus 2001 19:05 schreef tomato het volgende:

[..]

Altijd lastig, dat soort benchmarks. Want wat wil je precies vergelijken? Maar het antwoord wat je wilt horen is waarschijnlijk dat servlets na 1 keer runnen sneller zijn en de complete applicatie zal schaalbaarder zijn.

Het liefst wel ja

[ACM]

Op donderdag 23 augustus 2001 19:03 schreef devel het volgende:
[beetje off-topic]
Hoewel het volgens tomat niet erg belangrijk is, ben ik toch wel erg benieuwd naar de performance verschillen tussen php en java servlets dan wel jsp. Is daar ooit onderzoek naar gedaan?
[/beetje off-topic]

Daar is meerdere malen onderzoek naar gedaan.

Ik geloof dat php kwa snelheid verloor van jsp, maar dan niet als je tomcat als server gebruikt voor jsp natuurlijk

Oftewel dergelijke tests zijn erg moeilijk te doen.
Je test er gelijk allerlei andere aspecten bij (stel dat je php, perl en python als module van apache hebt, terwijl dat helemaal niet het snelste platform ervoor is (zope is sneller met python?) etc, php gebruikt de native interface met mysql, jsp jdbc, etc)

Als je voor de zelfde kosten, gaat (bij je vergelijking), en dan gewoon je platform optimaal maakt...

Tsja, dan zou ik niet weten wie wint
jsp kan dan heel ver komen, maar zowel php (in een lamp-config met evt tux erbij) als perl kunnen dan behoorlijk snel worden.

[Verwijderd]

Tja, nog steeds geen duidelijk antwoord, maar duidelijk is me nu ook waarom, eigenlijk ook wel logisch.

Bedankt!

[Nielsz]

Hmmm ja, maar dan zijn er nog wel wat dingen te noemen die je mist in OOPHP.
[..]

Tssss..
Wat dan? Vertel vertel

[..]


Wat betreft het blindelinge vertrouwen van veel mensen heb je wel gelijk, maar imho ligt dat niet aan PHP, maar aan de gebrekkige programmeerkennis en -ervaring van deze mensen zelf.
[..]

Tssss..
Maar PHP moet hier niet in meegaan en het negeren, maar oplossingen bedenken. De oplossing die ik vandaag dus al heb gegeven: alles dichtgooien

Ja, per definitie natuurlijk wel, maar voor jou is een string in PHP iets heel anders dan een array. Er mogen dan enkele 'array-features' zijn die ook op een string passen, maar daar houdt het dan ook op. Het is geen C.
[..]

Tssss..
Ik refereerde hier ook naar de stringfuncties van C. Daar kon je fijn 'cout << $string[3] << endl;' doen (wtf is het $ teken ook al weer in C?)
[quote]

[Verwijderd]

Op donderdag 23 augustus 2001 19:40 schreef Nielsz het volgende:
Ik refereerde hier ook naar de stringfuncties van C. Daar kon je fijn 'cout << $string[3] << endl;' doen (wtf is het $ teken ook al weer in C?)

Kent C niet string[3] dus Jeez Nielsz you need to get out more

[Nielsz]

Op donderdag 23 augustus 2001 19:43 schreef devel het volgende:

[..]

Kent C niet string[3] dus Jeez Nielsz you need to get out more

Tssss...
Helaas was ik bij het upgraden van het OS vergeten C++ te backuppen. Dus ik heb het ruim anderhalf jaar niet meer gedaan denk ik.
(alleen maar PHP & ASP & VB voor mij )

tikvautenwarning by ACM (r)

[Verwijderd]

Op donderdag 23 augustus 2001 19:48 schreef Nielsz het volgende:

[..]

Tssss...
Helaas was ik bij het upgraden van het OS C++ te backuppen. Dus ja ik heb het al ik denk ruim anderhalf jaar niet meer gedaan dus ja... (alleen maar PHP & ASP & VB voor mij )

Het z(ei|ij) je vergeven (soms is Nederlands wat te moeilijk, and in that case regexps come in handy ).

Maar goed back ontopic. Waar ik eigenlijk voor zou zijn, maar ja dat gaat toch niet door, omdat het geheel dan 0,0 backward compatible is: Een complete rewrite van de taal, waarbij alle dubbele funties, aliasses, rare fakeobject_funtie (mysql_connect) constructies eruit gaan. Verder variabele declaraties (type hoeft niet, my $varnaam is al goed). En dat deze vage object_functie constructies vervangen worden door echt objecten. Dus een gzip object, een gd object, een database abstraction layer ingebouwd etc.

[Verwijderd]

Oh ja, ik weet dat het er al in zit (als compilatie optie geloof ik), maar ingebakken persistent data. Zodat je makkelijk gegevens en geparste data (html? xml?) kunt cachen, zo kun je ook een beetje aan loadbalancing tussen db server en webserver doen. Kortom, ik ben voor schaalbaarheid

[Verwijderd]

Hoe zit het eigenlijk met Perl 6... tomato is er wel heel errug .... enhousiast over.... .....

Ik was ook met perl begonnen... maar volgens mij nam ik een boek dat te moeilijk was....

PHP heb in nog niet goed door... dus daar kan ik weinig over zeggen
wel leuk om te lezen hoe andere erover denken

zoiets.... lijkt me wel leuk

php_maak_voor_mij(een vette website, met lekkere wijven[naakt], en inhoud wat veel trafic kan generen)

[eamelink]

Ik wil er wel graag een ubb parsertje in zien. Altijd handig.

Maarja, er is zoveel handig
Hoef ik straks zelf niet meer na te denken...

[mbravenboer]

eamelink: Ik wil er wel graag een ubb parsertje in zien. Altijd handig.

Binnen enkele dagen staat er een beter alternatief op GoT .

[tomato]

Op donderdag 23 augustus 2001 20:30 schreef mbravenboer het volgende:
Binnen enkele dagen staat er een beter alternatief op GoT .

* tomato hapt tomato wel op

XML, XML, XML????

[Apache]

Op donderdag 23 augustus 2001 20:30 schreef mbravenboer het volgende:

[..]

Binnen enkele dagen staat er een beter alternatief op GoT .

oja?

[mbravenboer]

tomato: * mbravenboer hapt tomato wel op
XML, XML, XML????

Je kent me te goed .

Ik ben er nog mee bezig. De presentatie is behoorlijk op aan het schieten. Ik wil echter ook een redelijke validatie... Als dat ook af is, post ik wel een test site . Het idee is trouwens ontstaan uit een project van Wasigh, die werkt aan een site voor online use-case discussies.

[chem]

nou tomato, dat is een flinke kledder text!

ik brouw ff een reactie

[Verwijderd]

Meer support voor xml, bijvoorbeeld een query uitvoeren op een database en dan rechtstreeks omzetten naar xml:

tabel boek:
id - title - author
0 - C++ programming language - Bjarne Stroustrup
1 - PHP 5.0 handleiding - Hennie
2 - The fall of windows - Linus Thorwalds
3 - My last word - Bill Gates

tabel hoofdstuk:
boek - id - title - tekst
0 - 0 - Introduction - Welcome...
0 - 1 - Strings - bla bla bla
0 - 2 - Integers - bla bla bla
1 - 0 - Intro - Dear reader ...
1 - 1 - What's new - Now there is more xml support ;-)
2 - 0 - Introduction - Some years ago...
3 - 0 - Introd - Money is...
3 - 1 - Money - This is the ...

Na het uitvoeren van de query:

SELECT B.ID B.TITLE B.AUTHOR H.ID H.TITLE H.TEKST FROM HOOFDSTUK H BOEK B WHERE (B.ID = H.ID)

Zal de uitvoer wordt dan iets als:
<RESULT>
<BOEK>
<ID>0</ID>
<TITLE>C++ programming language</TITLE>
<AUTHOR>Bjarne Stroustrup</AUTHOR>
<HOOFDSTUK>
<ID>0</ID>
<TITLE>Introduction</TITLE>
<TEKST>Welcome...</TEKST>
</HOOFDSTUK>
<HOOFDSTUK>
<ID>1</ID>
<TITLE>Strings</TITLE>
<TEKST>bla bla bla</TEKST>
</HOOFDSTUK>
<HOOFDSTUK>
<ID>2</ID>
<TITLE>Integers</TITLE>
<TEKST>bla bla bla</TEKST>
</HOOFDSTUK>
</BOEK>
<BOEK>
<ID>1</ID>
<TITLE>PHP 5.0 handleiding</TITLE>
<AUTHOR>Hennie</AUTHOR>
...
</RESULT>

Als dit mogelijk zou worden dan scheelt dat een hoop werk en het is simpel te realiseren.

Een 2e punt is het uitbreiden van mogelijkheden op gebied van graphics. Hierin vind ik het balangrijkste dat er ondersteuning voor vector graphics komt.

Het zou ook mooi zijn als er meer email mogelijkheden kwamen. Bijvoorbeeld een optie om scripts te maken die emails verwerken. Erg handig om bijvoorbeeld een forum te maken waar je ook via email kan posten!

Misschien is het belangrijk om ook te kijken naar wat er allemaal uit mag, en dus niet standaard meegeleverd wordt, maar als modules aan te roepen zal zijn.
Zelf vind ik dat de ondersteuning voor gif er wel uit mag. Dit wordt toch bijna niet meer gebruikt.

[tomato]

Op donderdag 23 augustus 2001 20:40 schreef mbravenboer het volgende:
Je kent me te goed .

Hehe

Ik ben er nog mee bezig. De presentatie is behoorlijk op aan het schieten. Ik wil echter ook een redelijke validatie... Als dat ook af is, post ik wel een test site .

Graag!

Het idee is trouwens ontstaan uit een project van Wasigh, die werkt aan een site voor online use-case discussies.

Wil wel eens een site van Wasigh zien

Op donderdag 23 augustus 2001 21:10 schreef chem het volgende:
nou tomato, dat is een flinke kledder text!

Niet meer dan 1 x in een aantal dagen. Alhoewel, als ik nog tijd kan vinden (niet dus ) om alle dotNET en Java artikelen en discussies door te lezen die ik nog heb liggen komt er vast nog wel eentje aan. Maar er gaat altijd behoorlijk wat tijd in dat soort dingen zitten (bedoel ik dit topic trouwens niet mee hoor ).

Op donderdag 23 augustus 2001 21:14 schreef the_tag-man het volgende:
Meer support voor xml, bijvoorbeeld een query uitvoeren op een database en dan rechtstreeks omzetten naar xml:
[voorbeeldje]

Je kunt ook gewoon SQL Server 2000 gebruiken

Als dit mogelijk zou worden dan scheelt dat een hoop werk en het is simpel te realiseren.

Je zou het ook zelf zo kunnen bouwen als er (wel of geen) goeie XML support in PHP zit.

Een 2e punt is het uitbreiden van mogelijkheden op gebied van graphics. Hierin vind ik het balangrijkste dat er ondersteuning voor vector graphics komt.

Is niet echt een taak voor PHP, dit soort dingen zijn namelijk externe library's, waar PHP niets aan ontwikkelt (logisch ook). Dus misschien eens een feature request bij de GD mannen en vrouwen plaatsen

Het zou ook mooi zijn als er meer email mogelijkheden kwamen. Bijvoorbeeld een optie om scripts te maken die emails verwerken. Erg handig om bijvoorbeeld een forum te maken waar je ook via email kan posten!

Die snap ik niet helemaal
Je bedoelt dat er op een port geluisterd moet kunnen worden naar binnenkomende data? PHP lijkt me hier niet de meestgeschikte taal voor, maar verder verwerken kun je natuurlijk altijd met PHP doen...

Misschien is het belangrijk om ook te kijken naar wat er allemaal uit mag, en dus niet standaard meegeleverd wordt, maar als modules aan te roepen zal zijn.

Ben ik het wel mee eens, maar eigenlijk moet hier een heel strak beleid voor komen.
Bij perl bijvoorbeeld zijn er nu ook veel stemmen om de standaard distributie zo kaal mogelijk te houden. Dit om het gebruik van CPAN onder hosting bedrijven te stimuleren. Op dit moment zie je veel uiteenlopende configuraties op verschillende servers. CPAN is hier een prachtige oplossing voor, maar zolang de standaard distrubutie voor veel mensen uitgebreid genoeg is wordt het nog te weinig gebruikt.
Waarschijnlijk zal het idee van een super kale distributie pas in perl 6 gebruikt worden. Het brengt namelijk erg veel problemen met zich mee, ik herinner me bijvoorbeeld een discussie op de perl mailing list over welke module(s) standaard zouden moeten zijn: een SOAP module, en/of een XML-RPC module. Als dit op dit moment al zoveel discussie vergt, wordt dat al helemaal moeilijk wanneer er nog veel meer van de distributie af moet.

Iemand vroeg geloof ik waarom ik zo enthousiast ben over perl 6. Een woord: Arien
Nee hoor, serieus, ik heb hier een PDF je online gezet door Damian Conway (super perl guru), zit ook flink wat humor tussen zoals gewoonlijk bij perl
Verder is het ook wel leuk om eens wat perl 6 RFC's door te snuffelen.

Zelf vind ik dat de ondersteuning voor gif er wel uit mag. Dit wordt toch bijna niet meer gebruikt.

Dit zullen veel anderen niet met je eens zijn, maar nogmaals, dit is niet aan het PHP devteam.

[Verwijderd]

Op donderdag 23 augustus 2001 21:39 schreef tomato het volgende:
[..]
Je kunt ook gewoon SQL Server 2000 gebruiken

Ondersteunt deze dat dan? Ik had al gehoord dat Oracle het wel ging ondersteunen. Zelf gebruik ik mySQL misschien dat mySQL dit gaat ondersteunen.

[..]
Je zou het ook zelf zo kunnen bouwen als er (wel of geen) goeie XML support in PHP zit.

Het is inderdaad niet moeilijk om hier zelf code voor te schrijven een stuk eenvoudiger en sneller zelfs als met html.

Maar aangezien XML steeds meer gebruikt wordt en steeds meer mensen data uit een database in een xml pagina willen laten zien zullen er velen deze functie handig vinden.

Waarom dit nog niet eerder is gedaan is omdat er nog geen xml was. Je kunt deze functie namelijk geen html laten uitvoeren. Want in html is de data en de opmaak nog niet geschijden.

[..]
Die snap ik niet helemaal

Je bedoelt dat er op een port geluisterd moet kunnen worden naar binnenkomende data? PHP lijkt me hier niet de meestgeschikte taal voor, maar verder verwerken kun je natuurlijk altijd met PHP doen...

Ik bedoelde dat php ze kan verwerken, niet dat je een script met een poort bind, daarvoor zou er misschien een ander tooltje gemaakt moeten worden.

[acm-edit: wat overbodig enters eruit gevist, dan is die page niet zo lang ;)]

[tomato]

Op donderdag 23 augustus 2001 22:07 schreef the_tag-man het volgende:
Ondersteunt deze dat dan? Ik had al gehoord dat Oracle het wel ging ondersteunen. Zelf gebruik ik mySQL misschien dat mySQL dit gaat ondersteunen.

In SQL server 2000 kun je je resultset direct als XML terug laten komen. Of MySQL hier plannen voor heeft weet ik eigenlijk niet, zou eens moeten zoeken in Todo's en devlists.

Waarom dit nog niet eerder is gedaan is omdat er nog geen xml was. Je kunt deze functie namelijk geen html laten uitvoeren. Want in html is de data en de opmaak nog niet geschijden.

XML bestaat toch al een flinke tijd hoor

Ik bedoelde dat php ze kan verwerken, niet dat je een script met een poort bind, daarvoor zou er misschien een ander tooltje gemaakt moeten worden.

Dan snap ik niet zo goed wat je hier van verwacht. Kun je dat nu nog niet met PHP dan?

[mbravenboer]

tomato: In SQL server 2000 kun je je resultset direct als XML terug laten komen.

Op een werkelijk buitengewoon symplistische manier naar mijn mening... Volgens mij denken veel database bouwers "oh, shit we moeten ook XML ondersteunen! Hoe bouwen we dat er zo snel mogelijk in!". Alleen IBM heeft er IMHO enigszins serieus over nagedacht.

[mbravenboer]

the_tag-man: Zelf gebruik ik mySQL misschien dat mySQL dit gaat ondersteunen.

Het is een dermate triviale optie, dat het eigenlijk de vraag is of het zinvol is. Als databases echt XML willen ondersteunen, moeten ze ook de mogelijkheid bieden om XML data op een goede manier te importeren. Alleen de result set op een triviale manier naar XML vertalen is IMHO weinig zinvol .

[Verwijderd]

Op donderdag 23 augustus 2001 21:39 schreef tomato het volgende:
Iemand vroeg geloof ik waarom ik zo enthousiast ben over perl 6. Een woord: Arien
Nee hoor, serieus, ik heb hier een PDF je online gezet door Damian Conway (super perl guru), zit ook flink wat humor tussen zoals gewoonlijk bij perl
Verder is het ook wel leuk om eens wat perl 6 RFC's door te snuffelen.

ik was dat ... tnx.. ff dat document doorlezen....

quote uit pdf...

begint al leuk

I was thinking, "Should I
get up and throw mugs too?" LOL

[tomato]

Op vrijdag 24 augustus 2001 00:25 schreef mbravenboer het volgende:

XML output ondersteuning in SQL Server 2000

Op een werkelijk buitengewoon symplistische manier naar mijn mening...

Ben ik het ook helemaal mee eens

Volgens mij denken veel database bouwers "oh, shit we moeten ook XML ondersteunen! Hoe bouwen we dat er zo snel mogelijk in!".

Ja, zo kwam het iig bij SQL Server 2000 wel een beetje op mij over. Vooral omdat het 1 van de punten is waar ze enorm veel reclame mee maken voor deze versie

Alleen IBM heeft er IMHO enigszins serieus over nagedacht.

* tomato werkt voorlopig niet met DB2, maar zal eens kijken wat ze daar gedaan hebben

Overigens is via ADO wel heel wat te doen met XML, maar echt fraai is het vaak nog niet.

[edit]
Microsoft's 'FOR XML [RAW|EXPLICIT|AUTO]' (da's dus ook echt alles ) is inderdaad niet echt te vergelijken met de XML Extender voor DB2

Oracle heeft overigens ook een XML Toolkit, maar wat die precies inhoudt weet ik niet.

[wasigh]

Op donderdag 23 augustus 2001 17:32 schreef Kepz het volgende:

en over die helloworld
I doubt wether it'd beat <?="Hello World!"?>

*LEKKER LEKKER PUH*
*tong uitsteek*

[hap]
In Jsp wordt dit ongeveer: <%="Hello World"%>
officieel moet het in php dit zijn: <?php ="hello world"?>
(beaten
Dus slik die tong maar weer in

Op donderdag 23 augustus 2001 20:40 schreef mbravenboer het volgende:

[..]

Je kent me te goed .

Ik ben er nog mee bezig. De presentatie is behoorlijk op aan het schieten. Ik wil echter ook een redelijke validatie... Als dat ook af is, post ik wel een test site . Het idee is trouwens ontstaan uit een project van Wasigh, die werkt aan een site voor online use-case discussies.

En voor mezelf heb ik een Java UBB-parser geschreven(die niet geoptimaliseerd redelijk snel is 20 ms heeft ie gehaald ...(java traag ), Woensdag aan mbravenboer laten zien en die kwam toen op het idee om het met xml te doen (de 1e versie zag er goed uit!)

Op donderdag 23 augustus 2001 21:39 schreef tomato het volgende:
Wil wel eens een site van Wasigh zien

offtopic:
Een site? of die site
Hij is nu nog in closed Beta. Maar mail maar

[chem]

het is trouwens

PHP:

<?
 echo 'hello world'; 
?>

en niet = (= is nl. asp stijl)

verder; het mag niet maar ik doe het toch als iemand eens servlet support kan flikkeren op m'n K6 400 dan vind ik dat heel fijn beloning is beschikbaar
(heeft mod zijn toch nog voordelen )

verder; het gaat nogal offtopic hier dus ff back-on-track:
andere features die ik graag in php zou zien; (al genoemd) de mogelijkheid grote bibliotheken op een andere manier te beheren. Kom je uiteindelijk toch weer terecht op parse-caching, compilen etc. De grote van de bestanden worden ook een probleem met je texteditor en ook op dat vlak zie ik nog genoeg potentie om te automatiseren.

[Nielsz]

Op vrijdag 24 augustus 2001 09:40 schreef chem het volgende:
het is trouwens <?php echo 'hello world'; ?> en niet = (= is nl. asp stijl)

Bugje???

erder; het gaat nogal offtopic hier dus ff back-on-track:
andere features die ik graag in php zou zien; (al genoemd) de mogelijkheid grote bibliotheken op een andere manier te beheren. Kom je uiteindelijk toch weer terecht op parse-caching, compilen etc. De grote van de bestanden worden ook een probleem met je texteditor en ook op dat vlak zie ik nog genoeg potentie om te automatiseren.

Parse caching was er toch al, en dat was drama? Dus dat moet verbeterd worden ofzo????
En wat wil je in godsnaam automatiseren aan grote bestanden? Hoe zie je dat?

[wasigh]

Op vrijdag 24 augustus 2001 09:40 vergeet chem dat hij wel html mag posten:
het is trouwens <?php echo 'hello world'; ?> en niet = (= is nl. asp stijl)

verder; het mag niet maar ik doe het toch als iemand eens servlet support kan flikkeren op m'n K6 400 dan vind ik dat heel fijn beloning is beschikbaar
(heeft mod zijn toch nog voordelen )

[laatste keer ot]
wat voor OS? Tomcat is echt een eitje om te installeren...
[/ot]

[chem]

Op vrijdag 24 augustus 2001 09:45 schreef Nielsz het volgende:

[..]

Bugje???
[..]

Parse caching was er toch al, en dat was drama? Dus dat moet verbeterd worden ofzo????
En wat wil je in godsnaam automatiseren aan grote bestanden? Hoe zie je dat?

ja dat krijg je als je mod bent: html mag en dus verdwijnt die < enzo... (heel vervelend hoor )

Parse caching is er in de zin dat APC het eea. kan (edoch niet perfect) en Zend biedt gelukkig een stabielere versie.

Hoe die grote libs beter kunnen heb ik niet zo 1-2-3 een antwoord op. Ik geef toe dat een deel daarvan afhankelijk is van hoe het in het bedrijf gaat qua onderhoud, compatibiliteit etc. Zo gaan wij wellicht op korte termijn over op CVS en PHPDoc om dit te vermijden.

wasigh> slackware 7.1 icq me maar 98343967 (schrik niet af door de andere nick )

Wat ik graag zou zien (bedenk ik me nu) is de mogelijkheid hompen code 'in' PHP op te slaan - een soort van prepend functie maar dan met ingebouwde caching en wellicht kan PHP er een paar seconden extra op beuken bij het invoeren van de code zodat het eea. nog verder geoptimaliseerd kan worden... jah, DAT lijkt me nou kewl

edit: verkeerde smiley

[chem]

offtopic: hoe installeer ik tomcat op m'n linux bak:

code:

~$ su
~$ ftp ftp://ftp.java.sun.com/pub/j2sdk/1.3.1/f198267/j2sdk-1_3_1-linux-i386.bin
~$ wget http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.3/bin/jakarta-tomcat-3.2.3.tar.gz
~$ chmod +x j2sdk-1_3_1-linux-i386.bin
~$ ./j2sdk-1_3_1-linux-i386.bin
~$ cd /jdk1.3.1/bin
~$ ./javac -classpath /home/user/jdk1.3.1/bin
~$ tar -xzvf jakarta-tomcat-3.2.3.tar.gz
~$ cd jakarta-tomcat-3.2.3/bin
~$ chmod +x *
~$ JAVA_HOME=/home/user/jdk1.3.1/
~$ export JAVA_HOME
~$ TOMCAT_HOME=/home/user/jakarta-tomcat-3.2.3/
~$ export TOMCAT_HOME
~$ ./startup.sh

alstu
(slackware 7.1 trouwens)

[wasigh]

Op vrijdag 24 augustus 2001 11:23 schreef chem het volgende:
offtopic: hoe installeer ik tomcat op m'n linux bak:

code:

een paar commando's

alstu
(slackware 7.1 trouwens)

Ik zei toch dat het een eitje was

[chem]

Op vrijdag 24 augustus 2001 11:39 schreef wasigh het volgende:

[..]

Ik zei toch dat het een eitje was

tnx voor alle hulp... iig was het simpeler dan ik dacht (btw tomcat draait gewoon naast apache)

btw wat vinden we van m'n mooie includer idee?

[tomato]

Op vrijdag 24 augustus 2001 11:42 schreef chem het volgende:
tnx voor alle hulp... iig was het simpeler dan ik dacht (btw tomcat draait gewoon naast apache)

Misschien ga ik het nu ook proberen, het schijnt zo makkelijk te zijn

btw wat vinden we van m'n mooie includer idee?

Wat bedoel je nu precies? Soort includes, of functiecalls die als inline gecompiled worden? Of gaat het je meer om het cachen van uitvoer van die stukken? Dat laatste wordt moeilijk aangezien het zo dynamisch kan zijn als je wilt.

[chem]

Op vrijdag 24 augustus 2001 12:59 schreef tomato het volgende:

[..]

Misschien ga ik het nu ook proberen, het schijnt zo makkelijk te zijn
[..]

Wat bedoel je nu precies? Soort includes, of functiecalls die als inline gecompiled worden? Of gaat het je meer om het cachen van uitvoer van die stukken? Dat laatste wordt moeilijk aangezien het zo dynamisch kan zijn als je wilt.

wat ik bedoel; iedereen heeft wel libs liggen. Wat me gers lijkt is de mogelijkheid om bepaalde .php files in een speciale dir te zetten bv., zodat php die files 1maal parsed en de functies overal beschikbaar zijn.
Wellicht dat de functies idd. een onderdeel van PHP worden (native? sneller?) maar ik weet niet in hoe verre dit mogelijk is.

[tomato]

Op vrijdag 24 augustus 2001 13:04 schreef chem het volgende:
wat ik bedoel; iedereen heeft wel libs liggen. Wat me gers lijkt is de mogelijkheid om bepaalde .php files in een speciale dir te zetten bv., zodat php die files 1maal parsed en de functies overal beschikbaar zijn.
Wellicht dat de functies idd. een onderdeel van PHP worden (native? sneller?) maar ik weet niet in hoe verre dit mogelijk is.

Hmmm.... jij bent dus gewoon te lui om PHP opnieuw te compilen
Maar je bedoelt dus eigenlijk een gemakkelijker manier dan .so's maken? Zodat PHP automagisch iets van een .so voor je maakt wanneer hij een nieuw bestand in een /libs dir ziet staan?

[chem]

Op vrijdag 24 augustus 2001 13:10 schreef tomato het volgende:

[..]

Hmmm.... jij bent dus gewoon te lui om PHP opnieuw te compilen
Maar je bedoelt dus eigenlijk een gemakkelijker manier dan .so's maken? Zodat PHP automagisch iets van een .so voor je maakt wanneer hij een nieuw bestand in een /libs dir ziet staan?

daar komt het wel op neer; ik ben te lui om .so files (dl() is wellicht weg binnenkort) te maken en 't lijkt me dat PHP even efficiente code KAN maken uit mijn gebrabbel als een .so file doet.

Als PHP dat kan doen (betrouwbaar, stabiel, snel) dan word ik daar best vrolijk van...

[tomato]

Op vrijdag 24 augustus 2001 13:15 schreef chem het volgende:
Als PHP dat kan doen (betrouwbaar, stabiel, snel) dan word ik daar best vrolijk van...

In combinatie met function overloading wordt ik er ook vrolijk van