PHP: false, null en '0'

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Het kan natuurlijk een leuk streven zijn voor personen om daadwerkelijk te
>>doorgronden waarom/hoe en of iets werkt.
>
> Inderdaad, dat heet "wetenschap" :-)

Techniek is voor mij een wetenschap :)

>>Mijn nederlands is niet geweldig
>
> Mwa, dat valt wel mee. Neem me niet kwalijk dat ik enkele spelfouten in de
> quotes heb gecorrigeerd.

Dat is mijn handels merk.

>>>>Er zijn meerdere beschikbare implentaties
>>
>>> "Van wat?" Is dan de enige zinnige vraag, maar in deze context kennelijk
>>> retorisch.
>>
>>maar waar dat op slaat lijkt me duidelijk.
>
> Mij niet, zoals in onze discussie bleek. "Het OO-paradigma" zegt mij niet
> zoveel. Ik heb een vaag benul van wat het zoal betekent, maar zonder
> concrete beschrijving of verwijzing vind ik het te vaag.

Dat stond er in 4 woorden samengevat achter (alles is een object), dat
is voor mij het belangrijkste onderdeel. Daaruit volgt een dusdanig
ontwerp dat je op een zinnige manier het geheel kan samenstellen uit een
serie objecten welke ervoor zorgen dat je het systeem hopelijk makkelijk
kan onderhouden en uitbreiden. Aangezien ik daar geen kaas van heb
gegeten (het ontwerpen) kan ik je daar niet veel wijzer mee maken, ik
zie alleen de gevolgen van een slecht ontwerp.

>>Mooie voorwerpen, een vliegtuig vliegt omdat het een of meerdere
>>objecten heeft welke de eigenschap hebben dat het een vliegtuig zou
>>kunnen vliegen (laten we dat basisding de naam 'Fietsbel' geven). Hoe
>>dat object daadwerkelijk geconstrueerd is boeit gewoon niet, dat het een
>>implementatie van het basis object Fietsbel is is voor het object
>>BusHalte voldoende om te kunnen vliegen.
>
> In de informatica werkt dat zo ja, maar als dit je overtuiging is dan
> verzoek ik je vriendelijk geen bemande vliegtuigen of vliegtuigen voor
> personenvervoer te ontwerpen, noch vliegtuigen die in de buurt komen van
> postcodegebied 1066 :-)

Gelukkig heeft het vliegtuig object een methode om correct te kunnen
bepalen of het object de grond kan verlaten en terug keren op een
volgens implementatie afhankelijk gestelde eisen ;)

>>>>>Wees welkom, builtin types!
>>>>En waarom zouden builtins geen object kunnen zijn?
>>> Omdat ik "types" zei, niet "classes".
>>Waarom sluit dat elkaar uit?
>
> Builtins kunnen inderdaad ook objecten/classes zijn. Maar ik doelde op de
> builtin types die geen class zijn, zoals de gewone integer in talen als
> Java en Python.

Het feit dat er ints en Integers zijn in Java is een goed voorbeeld van
hoe het niet moet. Een Integer is niet veel meer dan een container voor
een int, je kunt er niet eens een andere Integer of int bij de waarde
optellen. Een int kan je bv weer niet in een Collection gebruiken
aangezien die alleen objecten vreet. Het Integer object is hiermee
verworden tot niet veel meer dan een wrapper.

> Ik corrigeer mijzelve: welkom builtin non-class types! :-)

Waarom zou je dat willen in een (gedeeltelijke) OO taal?

--

Daniel Tryba

Michiel de Roo:
>Wat betref het instantieren denk ik toch van wel. Waarschijnlijk doet de
>ClassLoader dit voor je op het moment dat je java.exe aanroept.

Nee sorry, dit lijkt me flauwekul. Er is wel een class, maar geen
instantie van die class.

"Another difference between instance members and class members is that
class members are accessible from the class itself. You don't need to
instantiate a class to access its class members."
http://java.sun.com/docs/books/tutor...classvars.html

Eigenlijk gaat dit helemaal nergens over, maar ik heb _wel_ gelijk ;-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Inca <shadow*movements@wanadoo.nospam.invalid> wrote:
>> Wat betref het instantieren denk ik toch van wel. Waarschijnlijk doet
>> de ClassLoader dit voor je op het moment dat je java.exe aanroept.

Voor het gebruik van Java als taal is het niet verplicht om ook
daadwerkelijk een JVM te gebruiken. Java kan ook gewoon naar native
standalone code worden gecompileer (bv gcj wat het dus in een C++ object
lijkt te mikken)

> En mag je het dan nog een object noemen? Uiteindelijk is het allemaal plek
> in het geheugen, eentjes en nulletjes. Maar of dat genoeg is om te kunnen
> concluderen dat primitieven niet zonder object kunnen voorkomen?

http://java.sun.com/j2se/1.4.2/docs/...ang/Class.html
<q>
The primitive Java types (boolean, byte, char, short, int, long, float,
and double), and the keyword void are also represented as Class objects.
</q>

--

Daniel Tryba

Marcus <mark@ijbema.xs4all.nl.invalid> wrote:
>> > Nee hoor, het is gewoon heel logisch. In java is het overigens ook
>> > zo. Als je integers op elkaar deelt krijg je een integer, als je reals
>> > op elkaar deelt krijg je een real.
>>
>> Ik zie daar de logica dus niet (meer) van in :)
>
> Het is dezelfde logica waarom 3 + 3 == 6 en "3" + "3" == "33".

Leuk voor PHP, daar levert "3"+"3" namelijk netjes 6 op, aangezien de
operator + gedefineerd is als numerieke optelling. 3 . 3 levert netjes
33 op (aangezien de operator . als string concatenator gedefineerd is).
Das toch volkomen logisch :)

--

Daniel Tryba

Daniel Tryba:
>>Rene Pijlman:
>> Ik corrigeer mijzelve: welkom builtin non-class types! :-)
>
>Waarom zou je dat willen in een (gedeeltelijke) OO taal?

Om te beginnen heb ik het conceptueel moeilijk met het
alles-is-een-object-idee. Wat zijn immers de attributen van een object in
zo'n wereld? "Objecten!" hoor ik je denken, maar... enfin je snapt mijn
Hofstadteriaanse vraagtekens.

Verder hou ik niet van een opgelegd software-paradigma. Soms wil ik OO
programmeren, soms traditioneel, soms functioneel en soms wil ik gewoon ff
een scrippie om wat handigs te doen op mijn computer. Als Java in al die
dingen goed was dan gebruikte ik uitsluitend Java.

Maar voor ff een scrippie is dat gedoe met strikte signatures soms knap
lastig. Je verandert wat in een method deep down, die blijkt daardoor een
andere exception te kunnen throwen en voor je het weet moet je op 487
plaatsen de signature aanpassen. Nu weet ik ook wel dat je dat in een goed
ontworpen systeem moet voorkomen door passende abstracties te
introduceren, maar dat wil je allemaal niet voor ff een scrippie.

En neem nu zoiets triviaals als een enumerated type. Wat je in Java
allemaal niet moet programmeren om een equivalent daarvan in een class te
krijgen... weerzinwekkend. Er zijn boeken, nou je hoofdstukken over
geschreven.
http://developer.java.sun.com/develo...a/Chapter5.pdf

Is een taal met een builtin enum nou niet veel makkelijker? Mis ik ook bij
Python trouwens.

Maar goed, ik dwaal af van jouw vraag. Een goede vraag. Misschien weet ik
er geen goed antwoord op. Misschien ben ik wel te inflexibel, zoals de
programmeurs in mijn omgeving die niet konden programmeren zonder
pointers, terwijl ik niet meer kan programmeren met.

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Michiel de Roo <michiel@mderooPUNTNL>:
> Rene Pijlman wrote:
>
>> Michiel de Roo:
>>
>>>Rene Pijlman wrote:
>>>
>>>>Builtins kunnen inderdaad ook objecten/classes zijn. Maar ik doelde op
>>>>de builtin types die geen class zijn, zoals de gewone integer in talen
>>>>als Java en Python.
>>>
>>>Maar in Java kan zo'n primitieve alleen bestaan als onderdeel van een
>>>object. Dat is wel een belangrijk verschil.
>>
>> Nee hoor. Even uit mijn hoofd:
>>
>> class HalloWereld {
>> public static void main(String[] args)
>> {
>> int i = 1;
>> System.out.println("i: " + i);
>> }
>> }
>
> waarbij i dus bij class HalloWereld hoort. Het is immers gedeclareerd
> binnen een functie van class HalloWereld. Dat deze functie static is
> doet daar niets aan af.

Maar dat i onderdeel van een class is, doet er ook niets aan af: het blijft
een primitieve/builtin.

--
robert

robert wrote:
> Marcus <mark@ijbema.xs4all.nl.invalid>:
> > robert wrote:
> >
> >> > Het is dezelfde logica waarom 3 + 3 == 6 en "3" + "3" == "33".
> >>
> >> Nee, want het optellen van strings is niet duidelijk gedefinieerd in de
> >> wiskunde, voor zover ik weet.
> >
> > Maar wel in programmeertalen.
>
> En volgens de logica van stringconcatenatie is 1/2 altijd een
> integerdeling?

ja, een deling van integers is een integerdeling, een deling van reals
een real, operator overloading heet dat.

Mark

Michiel de Roo wrote:
> Daniel Tryba wrote:
>
>> Resulteert in:
>> $ javac /tmp/Foo.java
>> /tmp/Foo.java:7: incompatible types
>> found : java.lang.Boolean
>> required: boolean
>> if(t)
>> ^
>> 1 error
>>
>> De enige correcte expression in dit geval is
>> if(t.booleanValue())
>>
>
> Ja, je hebt hier wel gelijk, maar Java is een echte programmeertaal,
> terwijl python en php toch meer scriptingtaaltjes zijn. Java kan ik als
> zodanig veel serieuzer nemen.
>
> Ik heb inmiddels wel door dat je niet php moet gaan programmeren met Java
> in je achterhoofd. Dan kom je namelijk voor rare verassingen te staan.
> Hetzelfde gezanik had ik een keer toen ik een composite object in een
> session had gezet. Na de volgenden pagina-reload waren alle composites
> weg. Tja, dan kijk je toch wel zuur.

Moet je misschien toch eens naar perl gaan kijken. Hoewel het even duurt
voordat je alles door hebt kan je er daarna best netjes OO in
programmeren.

Mark

NNTP-Posting-Host: cust.91.90.adsl.cistron.nl
X-Trace: ncc1701.cistron.net 1070010175 10265 195.64.91.90 (28 Nov 2003 09:02:55 GMT)
X-Complaints-To: abuse@cistron.nl
NNTP-Posting-Date: Fri, 28 Nov 2003 09:02:55 +0000 (UTC)
User-Agent: slrn/0.9.7.4 (Darwin)
Xref: nl-news.euro.net nl.internet.www.server-side:32643

Marcus <mark@ijbema.xs4all.nl.invalid>:
> robert wrote:
>> En volgens de logica van stringconcatenatie is 1/2 altijd een
>> integerdeling?
>
> ja, een deling van integers is een integerdeling, een deling van reals
> een real, operator overloading heet dat.

In het geval van Python zijn integers primitives, dus er is geen sprake van
operatoroverloading.

--
robert

Marcus:
>Michiel de Roo:
>> Ik heb inmiddels wel door dat je niet php moet gaan programmeren [...;-)]
>
>Moet je misschien toch eens naar perl gaan kijken. Hoewel het even duurt
>voordat je alles door hebt kan je er daarna best netjes OO in
>programmeren.

Ik wil hier niet de language advocate uithangen, maar als je overweegt
naar Perl te kijken _dan_ heb je zeker een reden om eerst naar Python te
kijken. Python is Perl, maar dan goed.

Zie wat ESR erover zegt in:
http://www.linuxjournal.com/article.php?sid=3882

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Ik wil hier niet de language advocate uithangen, maar als je overweegt
> naar Perl te kijken _dan_ heb je zeker een reden om eerst naar Python te
> kijken. Python is Perl, maar dan goed.

Ik kan maar niet wennen aan dat indentgedoe van Python. Afgelopen week was
ik wat Pythonscripts aan het aanpassen (een paar example-stukjes voor een
specifiek MacOSX gebeuren), en hupsa: "syntax error". Want natuurlijk was
de code geïndent met spaties terwijl ik met tabs indent.

> Zie wat ESR erover zegt in:
> http://www.linuxjournal.com/article.php?sid=3882

These problems combined to make large volumes of Perl code seem
unreasonably difficult to read and grasp as a whole after only a few
days' absence.

Uh-uh. Dat zegt mij meer over ESR (iemand wiens mening ik toch al niet al
te hoog in achting neem) dan over Perl.

--
robert

Rene Pijlman wrote:
> Marcus:
>
>>Michiel de Roo:
>>
>>>Ik heb inmiddels wel door dat je niet php moet gaan programmeren [...;-)]

met java in je achterhoofd.... (knippen is ook een kunst ;-)

>>
>>Moet je misschien toch eens naar perl gaan kijken. Hoewel het even duurt
>>voordat je alles door hebt kan je er daarna best netjes OO in
>>programmeren.

In PHP kun je ook best netjes OO programmeren, als je jezelf wat extra
restricties oplegt. Maar dat is toch wat anders dan een taal als Java,
waarbij alles erop gericht is dat je dat ook werkelijk gaat doen.

>
>
> Ik wil hier niet de language advocate uithangen, maar als je overweegt
> naar Perl te kijken _dan_ heb je zeker een reden om eerst naar Python te
> kijken. Python is Perl, maar dan goed.
>
> Zie wat ESR erover zegt in:
> http://www.linuxjournal.com/article.php?sid=3882
>

Nee, helaas mensen. Als ik PHP achter mij laat is dat omdat ik op servlets
overstap. Helaas zijn de hosting kosten daarvoor nog redelijk duur, anders
had ik dat waarschijnlijk allang gedaan.

Michiel.

robert:
>Ik kan maar niet wennen aan dat indentgedoe van Python.

Ik geef toe, dat is een tikje ongebruikelijk, en lastig in het begin.

Maar aan de andere kant is het inderdaad zo dat ik bij alle talen met een
expliciete block syntax altijd consequent een bepaalde indentering
aanbreng en de haakjes dan in feite overbodig zijn.

Java:

if (a >= b)
{
max = a;
}
else
{
max = b;
}

Python:

if a>=b:
max = a
else:
max = b

Ik vind het zonder die ; en { } eleganter. Python lijkt ook meer (soms
zelfs 100%) op de pseudocode die ik anders weleens schrijf voordat ik echt
ga coderen.

>Rene Pijlman:
> > Zie wat ESR erover zegt

>Uh-uh. Dat zegt mij meer over ESR dan over Perl.

Da's waar :-)

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Michiel de Roo:
>Nee, helaas mensen. Als ik PHP achter mij laat is dat omdat ik op servlets
>overstap.

Wat mij betreft een prima keuze hoor.

>Helaas zijn de hosting kosten daarvoor nog redelijk duur

Hé, zit hier een gat in de markt?

Wat zou je bereid zijn te betalen voor hosting van server-side Java
applicaties, inclusief Tomcat, JBoss, de Apache projecten, een database
server etc.?

--
René Pijlman

Wat wil jij leren? http://www.leren.nl

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> robert:
>>Ik kan maar niet wennen aan dat indentgedoe van Python.
>
> Ik geef toe, dat is een tikje ongebruikelijk, en lastig in het begin.
>
> Maar aan de andere kant is het inderdaad zo dat ik bij alle talen met
> een expliciete block syntax altijd consequent een bepaalde indentering
> aanbreng en de haakjes dan in feite overbodig zijn.

Ja en nee: ik hou zelf ook een vrij nette (al zeg ik het zelf) indentering
aan, maar ik vind expliciete blokscheiders zoals accolades visueel toch
prettiger.

In het geval van een lang stuk code, dat van het scherm afscrollt, lijkt
me Python extreem onduidelijk; in het geval van scheiders kan je met de
gemiddelde editor in ieder geval makkelijk naar het begin en einde van het
huidige blok springen.

--
robert