PHP: false, null en '0' [Archief]

Inca

25/11/03, 21:15

Marcus wrote:
> PHP maakt net als Perl geen onderscheid tussen strings en integers,
> dit is daaruit logisch volgend resultaat.

Volgens mij klopt dit niet geheel: PHP maakt wel onderscheid tussen strings
en integers (en andere types), alleen hoef je dat niet van te voren aan te
geven. Het verschil bestaat echter wel degelijk (check bv de functies
is_int() en is_string(), zie ook manual over )
http://nl2.php.net/manual/en/language.types.type-juggling.php

Wat hier optreedt is een impliciete conversie naar een bool. En dan wordt
'0' geconverteerd naar false. (Enigzins logisch als je bedenkt dat php veel
gebruikt word voor forms en databases). Zie
http://nl2.php.net/manual/en/language.types.boolean.php#language.types.boolean. casting

Afhankelijk van de toepassing (want /wat/ wil je nou precies weten als je
test op if('0')) kun je gebruik maken van isset(), strlen(), de operators
=== en !=== (typespecifieke vergelijking) en er zijn vast nog wel meer
mogelijkheden.

--
Inca
JA - Wel liberalisatie stroomnet
NEE - Geen stroom
http://www.poldermodelstickers.nl/

Michiel de Roo, 2 SEE Technology

26/11/03, 00:00

> Ik probeer me dan zelf ook zo vaak mogelijk erop te wijzen om === ipv ==
> te gebruiken indien ik weet van de types heb.
>

Ik had daar ooit wel over gelezen, maar er nog niet gelijk
aan gedacht. Dat is inderdaad wel een goede tip in dit
verband.

Michiel.

robert

26/11/03, 06:30

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> #!/usr/bin/python
> if '0':
> print '0'
> if '1':
> print '1'
>
> $ ./php-sucks.py
> 0
> 1

$ cat python-sucks.py
#!/usr/bin/python

if 1/2:
print "yes"
else:
print "no"

$ ./python-sucks.py
no

--
robert

Rene Pijlman

26/11/03, 09:45

robert:
>$ cat python-sucks.py
>#!/usr/bin/python
>
>if 1/2:
> print "yes"
>else:
> print "no"
>
>$ ./python-sucks.py
>no

Da's waar, maar dat was in de toekomst al opgelost.

$ cat python-sucked.py
#!/usr/bin/python2.2

from __future__ import division

if 1/2:
print "yes"
else:
print "no"
$ ./python-sucked.py
yes

--
René Pijlman

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

robert

26/11/03, 10:00

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid>:
> Da's waar, maar dat was in de toekomst al opgelost.
>
> $ cat python-sucked.py
> #!/usr/bin/python2.2
>
> from __future__ import division

from __future__ import zerostringisfalse? ;)

--
robert

Rene Pijlman

26/11/03, 10:15

robert:
>from __future__ import zerostringisfalse? ;)

$ cat mapzerotofalse.py
#!/usr/bin/python2.2
if {"0": False, "1": True}["0"]:
print "true"
else:
print "false :-)"
$ ./mapzerotofalse.py
false :-)

--
René Pijlman

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

Inca

26/11/03, 11:15

robert wrote:
> if 1/2:
> print "yes"
> else:
> print "no"
....
> no

Dat klopt toch?
--
Inca
NEE - Geen talent
JA - Wel een single
http://www.poldermodelstickers.nl/

robert

26/11/03, 11:15

Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>> if 1/2:
>> print "yes"
>> else:
>> print "no"
> ...
>> no
>
> Dat klopt toch?

Jij vindt het logisch dat 1/2 'false' oplevert?

--
robert

Inca

26/11/03, 11:30

robert wrote:
> Jij vindt het logisch dat 1/2 'false' oplevert?

Ja. Bij een int-deling (en dat is 1/2) krijg je het aantal gehele keren dat
2 in 1 past. Dus 0. Dus false.
--
Inca
NEE - Geen talent
JA - Wel een single
http://www.poldermodelstickers.nl/

robert

26/11/03, 11:30

Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>> Jij vindt het logisch dat 1/2 'false' oplevert?
>
> Ja. Bij een int-deling (en dat is 1/2) krijg je het aantal gehele keren
> dat 2 in 1 past. Dus 0. Dus false.

En waarom is het logisch dat 1/2 een integerdeling is?

--
robert

Rene Pijlman

26/11/03, 11:45

Inca:
>robert:
>> Jij vindt het logisch dat 1/2 'false' oplevert?
>
>Ja. Bij een int-deling (en dat is 1/2) krijg je het aantal gehele keren dat
>2 in 1 past. Dus 0. Dus false.

1/2 is 5/10 ofwel 0,5. Dat leren kinderen van 11 (ofzo). Het is heel
merkwaardig dat in programmeertalen van de
lagere/middelbareschool-wiskunde wordt afgeweken.

Net zoals het zeer merkwaardig is dat het meest basale datatype van de
informatica en formele logica, de boolean, in veel programmeertalen en
databases pas in de zoveelste versie als afterthought is toegevoegd.

--
René Pijlman

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

Inca

26/11/03, 17:15

Rene Pijlman wrote:
>> Ja. Bij een int-deling (en dat is 1/2) krijg je het aantal gehele
>> keren dat 2 in 1 past. Dus 0. Dus false.
>
> 1/2 is 5/10 ofwel 0,5. Dat leren kinderen van 11 (ofzo). Het is heel
> merkwaardig dat in programmeertalen van de
> lagere/middelbareschool-wiskunde wordt afgeweken.

Tsja, maar daar/voor/ leren ze dat 1 gedeeld door 2 nul is, met rest 1. En
dat is precies weer die int-deling. Breuken etc komen pas veel later.
--
Inca
NEE - Geen IKEA
JA - Wel SWEN
http://www.poldermodelstickers.nl/

robert

26/11/03, 17:30

Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> Rene Pijlman wrote:
>>> Ja. Bij een int-deling (en dat is 1/2) krijg je het aantal gehele
>>> keren dat 2 in 1 past. Dus 0. Dus false.
>>
>> 1/2 is 5/10 ofwel 0,5. Dat leren kinderen van 11 (ofzo). Het
>> is heel merkwaardig dat in programmeertalen van de
>> lagere/middelbareschool-wiskunde wordt afgeweken.
>
> Tsja, maar daar/voor/ leren ze dat 1 gedeeld door 2 nul is, met rest
> 1. En dat is precies weer die int-deling. Breuken etc komen pas veel
> later.

Ik vraag niet aan Python het aantal gehele keren dat 2 in 1 past, ik vraag
wat 1 gedeeld door 2 is. Net als het niet logisch is om '0' false te maken
is standaard integerdeling ook niet logisch.

--
robert

Inca

26/11/03, 17:45

robert wrote:
> Ik vraag niet aan Python het aantal gehele keren dat 2 in 1 past, ik
> vraag wat 1 gedeeld door 2 is. Net als het niet logisch is om '0'
> false te maken is standaard integerdeling ook niet logisch.

Definieer logisch?

In de c(++) documentatie staat heel duidelijk dat dat nu precies is wat je
vraagt. Wil je dat niet dan moet je 1 van beide integers naar een float
converteren.
In de python-documentatie ben ik niet zo thuis, maar het lijkt me dat dat
hetzelfde is:
" One other thing to note:
>>> print 5/2
results in a whole number (integer) result (i.e. 2). This is because Python
sees that the numbers are whole numbers and assumes you want to keep them
that way. "

http://www.freenetpages.co.uk/hp/alan.gauld/

Misschien /wil/ je het niet vragen, maar dat doe je dus wel, volgens de
syntaxregels van de taal.
--
Inca
NEE - Geen buitenlanders
JA - Wel shoarma
http://www.poldermodelstickers.nl/

robert

26/11/03, 18:00

Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>> Ik vraag niet aan Python het aantal gehele keren dat 2 in 1 past, ik
>> vraag wat 1 gedeeld door 2 is. Net als het niet logisch is om '0' false
>> te maken is standaard integerdeling ook niet logisch.
>
> Definieer logisch?

Dusdanig dat ik niet na hoef te denken of de gebruikte programmeertaal zelf
gaat afronden.

> In de c(++) documentatie staat heel duidelijk dat dat nu precies is wat
> je vraagt. Wil je dat niet dan moet je 1 van beide integers naar een
> float converteren.

C en C++ zijn wat dat betreft gewoon ouderwets, met hun "alles is een
integer" aanpak.

> In de python-documentatie ben ik niet zo thuis, maar het lijkt me dat
> dat hetzelfde is:
> " One other thing to note:
>>>> print 5/2
> results in a whole number (integer) result (i.e. 2). This is because Python
> sees that the numbers are whole numbers and assumes you want to keep them
> that way. "

Ik kan de logica daarachter niet vinden: ik deel het ene getal door het
andere, en dan verwacht ik een wiskundig kloppend antwoord.

> Misschien /wil/ je het niet vragen, maar dat doe je dus wel, volgens de
> syntaxregels van de taal.

Dezelfde taal die wordt gebruikt om te laten zien hoe debiel PHP is...

--
robert

Daniel Tryba

26/11/03, 18:00

Inca <shadow*movements@wanadoo.nospam.invalid> wrote:
>> Ik vraag niet aan Python het aantal gehele keren dat 2 in 1 past, ik
>> vraag wat 1 gedeeld door 2 is. Net als het niet logisch is om '0'
>> false te maken is standaard integerdeling ook niet logisch.
>
> Definieer logisch?
> In de python-documentatie ben ik niet zo thuis, maar het lijkt me dat dat
> hetzelfde is:
> " One other thing to note:
>>>> print 5/2
> results in a whole number (integer) result (i.e. 2). This is because Python
> sees that the numbers are whole numbers and assumes you want to keep them
> that way. "

maar python is toch volledig OO! Dat betkent toch dat 1/2 een object
naar een integer met de waarde 0 oplevert. Het object bestaat en dus
dient 1/2 true op te leveren! Of is python weer zo'n vage halve
implementatie?

--

Daniel Tryba

robert

26/11/03, 18:45

Daniel Tryba <news_nl.internet.www.server-side@canopus.nl>:
> maar python is toch volledig OO! Dat betkent toch dat 1/2 een object
> naar een integer met de waarde 0 oplevert. Het object bestaat en dus
> dient 1/2 true op te leveren!

Zodat een Boolean-object met waarde false ook true oplevert? ;)

--
robert

Marcus

26/11/03, 19:00

robert wrote:
> Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> > robert wrote:
> >> Ik vraag niet aan Python het aantal gehele keren dat 2 in 1 past, ik
> >> vraag wat 1 gedeeld door 2 is. Net als het niet logisch is om '0' false
> >> te maken is standaard integerdeling ook niet logisch.
> >
> > Definieer logisch?
>
> Dusdanig dat ik niet na hoef te denken of de gebruikte programmeertaal zelf
> gaat afronden.
>
> > In de c(++) documentatie staat heel duidelijk dat dat nu precies is wat
> > je vraagt. Wil je dat niet dan moet je 1 van beide integers naar een
> > float converteren.
>
> C en C++ zijn wat dat betreft gewoon ouderwets, met hun "alles is een
> integer" aanpak.

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.

Mark

Rene Pijlman

26/11/03, 19:45

Daniel Tryba:
>maar python is toch volledig OO!

Als je met "volledig" bedoelt dat er uitsluitend objecten bestaan in de
zin van "een instantie van een klasse" dan moet ik je teleurstellen.

"I also have to warn you that there's a terminological pitfall for
object-oriented readers: the word ``object'' in Python does not
necessarily mean a class instance. Like C++ and Modula-3, and unlike
Smalltalk, not all types in Python are classes: the basic built-in types
like integers and lists are not, and even somewhat more exotic types like
files aren't."
http://www.python.org/doc/2.3.2/tut/node11.html#SECTION0011100000000000000000

>Of is python weer zo'n vage halve implementatie?

Van wat?

--
René Pijlman

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

Rene Pijlman

26/11/03, 20:00

Inca:
>Rene Pijlman wrote:
>> 1/2 is 5/10 ofwel 0,5. Dat leren kinderen van 11 (ofzo). Het is heel
>> merkwaardig dat in programmeertalen van de
>> lagere/middelbareschool-wiskunde wordt afgeweken.
>
>Tsja, maar daar/voor/ leren ze dat 1 gedeeld door 2 nul is, met rest 1.

Dat is een didactische tussenstap, die later onjuist blijkt. Zoals de
ooievaar die kindertjes brengt.

Datzelfde kan van de bewering 1/2 = 0,5 niet gezegd worden. Die houdt in
alle mij bekende varianten van de wiskunde stand. In ieder geval in de
reëele en complexe getallen.

Ik refereer dan wel aan de basisschool, maar er is natuurlijk een zeker
minimumniveau nodig om te kunnen programmeren :-)

--
René Pijlman

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

Rene Pijlman

26/11/03, 20:00

Inca:
>robert:
>> Ik vraag niet aan Python het aantal gehele keren dat 2 in 1 past, ik
>> vraag wat 1 gedeeld door 2 is.

>Misschien /wil/ je het niet vragen, maar dat doe je dus wel, volgens de
>syntaxregels van de taal.

Zo simpel ligt dat niet. De operator heeft geen type, dat hebben de
operanden. En die kunnen in Python van een onbekend type zijn, dat pas
runtime blijkt. Dan is het heel onhandig dat a/b een heel ander resultaat
oplevert wanneer a en b de float waarden 1.0 en 2.0 hebben i.p.v. de
integerwaarden 1 en 2.

" The current division (/) operator has an ambiguous meaning for
numerical arguments: it returns the floor of the mathematical
result of division if the arguments are ints or longs, but it
returns a reasonable approximation of the division result if the
arguments are floats or complex. This makes expressions expecting
float or complex results error-prone when integers are not
expected but possible as inputs.
[...]
The problem is unique to dynamically typed languages: in a
statically typed language like C, the inputs, typically function
arguments, would be declared as double or float, and when a call
passes an integer argument, it is converted to double or float at
the time of the call. Python doesn't have argument type
declarations, so integer arguments can easily find their way into
an expression.

The problem is particularly pernicious since ints are perfect
substitutes for floats in all other circumstances [...]"
http://www.python.org/peps/pep-0238.html

--
René Pijlman

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

Marcus

26/11/03, 20:15

Rene Pijlman wrote:
> Daniel Tryba:
>>maar python is toch volledig OO!
>
> Als je met "volledig" bedoelt dat er uitsluitend objecten bestaan in de
> zin van "een instantie van een klasse" dan moet ik je teleurstellen.

Dan zal je idd bij ruby moeten zijn :)

Mark

Marcus

26/11/03, 20:15

Rene Pijlman wrote:
> Inca:
>>Rene Pijlman wrote:
>>> 1/2 is 5/10 ofwel 0,5. Dat leren kinderen van 11 (ofzo). Het is heel
>>> merkwaardig dat in programmeertalen van de
>>> lagere/middelbareschool-wiskunde wordt afgeweken.
>>
>>Tsja, maar daar/voor/ leren ze dat 1 gedeeld door 2 nul is, met rest 1.
>
> Dat is een didactische tussenstap, die later onjuist blijkt. Zoals de
> ooievaar die kindertjes brengt.
>
> Datzelfde kan van de bewering 1/2 = 0,5 niet gezegd worden. Die houdt in
> alle mij bekende varianten van de wiskunde stand.

Wij leerden anders op de middelbare school dat dit fout is.
0,5 == 1/2 +/- 1/20

Mark

Inca

26/11/03, 20:15

robert wrote:
> > Definieer logisch?
>
> Dusdanig dat ik niet na hoef te denken of de gebruikte
> programmeertaal zelf gaat afronden.

(-: Dan moet je zelf een programmeertaal schrijven. Want alleen een die je
zelf schrijft kan precies doen wat je verwacht. Ik vind het huidige gedrag
juist veel 'logischer'.
(Hoewel 'intuitiever' misschien een beter woord is, want met formele logica
heeft het weinig te maken)

> Ik kan de logica daarachter niet vinden: ik deel het ene getal door
> het andere, en dan verwacht ik een wiskundig kloppend antwoord.

Verdiep je eens in discrete wiskunde en wie weet wordt het 'logischer'?
Bij mij werd bij wiskunde al vrij snel erin gehamerd dat je natuurlijke en
reele (gebroken) getallen hebt, en dat dat heel verschillende dingen zijn.
En dat het wiskundig prima kloppend is als je zegt dat 1 / 2 = 0, als het
gaat over natuurlijke getallen. En het is slechts een kwestie van afspraak
(en context) of je uitgaat van natuurlijke getallen of juist niet.
--
Inca
NEE - Geen handel met voorkennis
JA - Wel met een gouden tip
http://www.poldermodelstickers.nl/

Rene Pijlman

26/11/03, 20:30

Marcus:
>Rene Pijlman:
>> Datzelfde kan van de bewering 1/2 = 0,5 niet gezegd worden. Die houdt in
>> alle mij bekende varianten van de wiskunde stand.
>
>Wij leerden anders op de middelbare school dat dit fout is.
>0,5 == 1/2 +/- 1/20

Dat waren eigenwijze natuurkunde-, scheikunde- en biologie-leraren die hun
eigen wending aan de wiskunde gaven.

Het zit zo:

0,5 = 1/2
0,5 +/- 0,05 = 1/2 +/ 1/20

Onnauwkeurigheden, afrondingen en onzekerheden moeten expliciet gemaakt
worden. Ik kan mij die benadering (pun intended) herinneren van het
natuurkundig prakticum in het eerste studiejaar _na_ de middelbare school.

--
René Pijlman

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

Inca

26/11/03, 20:30

Daniel Tryba wrote:
> maar python is toch volledig OO! Dat betkent toch dat 1/2 een object
> naar een integer met de waarde 0 oplevert. Het object bestaat en dus
> dient 1/2 true op te leveren! Of is python weer zo'n vage halve
> implementatie?

In dat geval lijkt me de test volledig zinloos, want dan krijg je toch
altijd true? 0/2 levert ook een object op. En zelfs 'false' zou dan een
object op moeten leveren en derhalve evalueren naar true. Ergens moet je een
keer de conversie maken naar een waarde, en wel een boolean. Het moment
waarop dat gebeurt is slechts een afspraak.

Overigens vermoed ik dat je in een pure OO-omgeving niet eens zoiets mag
schrijven. Het lijkt me eerder dat er dan een foutmelding moet komen dat er
een conversiefout is opgetreden (van een integer-object naar een
bool-object).
--
Inca
JA - Wel liberalisatie stroomnet
NEE - Geen stroom
http://www.poldermodelstickers.nl/

Jaap Beetstra

26/11/03, 21:45

Inca wrote:
> Ergens
> moet je een keer de conversie maken naar een waarde, en wel een
> boolean. Het moment waarop dat gebeurt is slechts een afspraak.

Je hoeft geen conversie te maken: als ik het mij goed herinner wordt in
SmallTalk het bericht 'ifTrue' gestuurd naar het object, met als argument
een block; een 'False' object negeert dat block, een 'True' object voert het
uit.

> Overigens vermoed ik dat je in een pure OO-omgeving niet eens zoiets
> mag schrijven. Het lijkt me eerder dat er dan een foutmelding moet
> komen dat er een conversiefout is opgetreden (van een integer-object
> naar een bool-object).

Doorredenerend op het voorgaande zou ook een integer-object een ifTrue
message kunnen ondersteunen, waarbij '0' het argument niet uitvoert en alle
anderen wel. Ik kan mij niet herinneren of SmallTalk dat doet, maar ik
vermoed van niet. Het lijkt me ook niet intuitief, maar aan het OO-zijn of
niet doet het niets af.

Groet, Jaap

Daniel Tryba

26/11/03, 22:00

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > maar python is toch volledig OO! Dat betkent toch dat 1/2 een object
> > naar een integer met de waarde 0 oplevert. Het object bestaat en dus
> > dient 1/2 true op te leveren!
>
> Zodat een Boolean-object met waarde false ook true oplevert? ;)

Correct. IMHO is de if van python net zo consequent als de if van php.

Bij een string wordt niet naar de waarden van het object gekeken maar
naar of het object bestaat, bij een integer is opeens de waarde van het
object van belang. Althans zo komt het over, het zal wel een enge
afspraak zijn net zoals de string "0" false oplevert in php. Zelfs java
(met z'n primitieven en wrapperclasses voor deze primitieven) doet het
in dit geval beter. Daar dient de expression van een if een boolean (de
primitieve dus) op te leveren. bv:

class Foo
{
public static void main(String args[])
{
Boolean t=new Boolean(true);

if(t)
{
System.out.println("true");
}
else
{
System.out.println("false");
}
}
}

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())

--

Daniel Tryba

Daniel Tryba

26/11/03, 22:00

Inca <shadow*movements@wanadoo.nospam.invalid> wrote:
>> naar een integer met de waarde 0 oplevert. Het object bestaat en dus
>> dient 1/2 true op te leveren! Of is python weer zo'n vage halve
>> implementatie?
>
> In dat geval lijkt me de test volledig zinloos, want dan krijg je toch
> altijd true? 0/2 levert ook een object op. En zelfs 'false' zou dan een
> object op moeten leveren en derhalve evalueren naar true. Ergens moet je een
> keer de conversie maken naar een waarde, en wel een boolean. Het moment
> waarop dat gebeurt is slechts een afspraak.
>
> Overigens vermoed ik dat je in een pure OO-omgeving niet eens zoiets mag
> schrijven. Het lijkt me eerder dat er dan een foutmelding moet komen dat er
> een conversiefout is opgetreden (van een integer-object naar een
> bool-object).

Dat is wat ik persoonlijk logisch zou vinden, er is op zo'n moment zeer
weinig twijfel aan wat de expressie in een if betekent.

--

Daniel Tryba

Daniel Tryba

26/11/03, 22:00

Marcus <mark@ijbema.xs4all.nl.invalid> wrote:
>> Datzelfde kan van de bewering 1/2 = 0,5 niet gezegd worden. Die houdt in
>> alle mij bekende varianten van de wiskunde stand.
>
> Wij leerden anders op de middelbare school dat dit fout is.
> 0,5 == 1/2 +/- 1/20

Beide beweringen zijn waar. De eerste (1/2=0.5) is namelijk een
definitie en 0.5~=0.5 +/- 0.05 is een afspraak die gemaakt is omtrendt de
sygnificantie van gemeten waarden.

--

Daniel Tryba

Daniel Tryba

26/11/03, 22:00

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>maar python is toch volledig OO!
>
> Als je met "volledig" bedoelt dat er uitsluitend objecten bestaan in de
> zin van "een instantie van een klasse" dan moet ik je teleurstellen.

Auw, en het leek me nog wel zo'n zinnige taal.

>>Of is python weer zo'n vage halve implementatie?
>
> Van wat?

Het OO paradigma (alles is een object).

--

Daniel Tryba

Rene Pijlman

26/11/03, 22:15

Daniel Tryba:
>Rene Pijlman:
>>>maar python is toch volledig OO!
>>
>> Als je met "volledig" bedoelt dat er uitsluitend objecten bestaan in de
>> zin van "een instantie van een klasse" dan moet ik je teleurstellen.
>
>Auw, en het leek me nog wel zo'n zinnige taal.

Nou ja, als jij alleen met objecten wil werken dan kan dat. Maar voor de
liefhebbers van eenvoud en performance zijn er ook nog gewoon integers
enzo.

>>>Of is python weer zo'n vage halve implementatie?
>>
>> Van wat?
>
>Het OO paradigma

Is dat welgedefinieerd? Op welke standaard, specificatie of publicatie
doel je?

>(alles is een object).

If all you have is a hammer... :-)

Ik vind dit toch net zoiets als de relativiteitstheorie samenvatten als
"alles is relatief" of de aquadynamica als "alles stroomt".

Vanwaar die intellectuele armoede? Wees welkom, builtin types!

--
René Pijlman

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

Rene Pijlman

26/11/03, 22:15

Daniel Tryba:
>0.5~=0.5 +/- 0.05 is een afspraak die gemaakt is

Niet met mij.

--
René Pijlman

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

Daniel Tryba

26/11/03, 23:00

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>> Als je met "volledig" bedoelt dat er uitsluitend objecten bestaan in de
>>> zin van "een instantie van een klasse" dan moet ik je teleurstellen.
>>
>>Auw, en het leek me nog wel zo'n zinnige taal.
>
> Nou ja, als jij alleen met objecten wil werken dan kan dat. Maar voor de
> liefhebbers van eenvoud en performance zijn er ook nog gewoon integers
> enzo.

Kijk dat is nou een taak voor de compiler. In de syntax van de taal
hoeft deze niets te weten van wat sneller is. Zo kan het natuurlijk zijn
dat een 32bit integer op sommige platformen sneller is dan een 64bit
integer, performance betrekken in de syntax is IMHO dus volkomen fout.
Dat je wil kunnen forceren dat een int die je gebruikt daadwerkelijk
maximaal maar 256 waarden kan hebben is wel handig, maar dat zou
betekenen dat er gewoon een Byte object is wat een afgeleide is van het
Integer object.

>>>>Of is python weer zo'n vage halve implementatie?
>>> Van wat?
>>
>>Het OO paradigma
>
> Is dat welgedefinieerd?

Vast niet. Boeit ook niet. Er zijn meerdere beschikbare implentaties die
precies voldoen aan de "alles is een object" houding die ik al noemde.

> Op welke standaard, specificatie of publicatie doel je?

Vanwaar deze starre houding en de drang naar regels? Ik kan helaas geen
publicaties voor je vinden aangezien er schijnbaar netwerk problemen
zijn in het netwerk waarin ik zit. Maar volgens mij kan je voorbeelden
vinden bij de smalltalk implementaties (en wellicht in de C# specs,
immers op pagina 331 van "A programmer's introduction to C#" ISBN:
1-893115-86-0 staat beschreven dat primitieven afgeleiden zijn van de
ultimime bases classe).

>>(alles is een object).
> If all you have is a hammer... :-)

Het haer als object is toch echt multifunctioneel. Zo kan je er spijkers
mee in een muur rammen, maar ook een ruimte mee ventileren. Dit zijn
slechts 2 voorbeelden.

> Ik vind dit toch net zoiets als de relativiteitstheorie samenvatten als
> "alles is relatief" of de aquadynamica als "alles stroomt".

> Vanwaar die intellectuele armoede? Wees welkom, builtin types!

En waarom zouden builtins geen object kunnen zijn?

--

Daniel Tryba

Daniel Tryba

26/11/03, 23:00

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
> Daniel Tryba:
>>0.5~=0.5 +/- 0.05 is een afspraak die gemaakt is
>
> Niet met mij.

Tsja, ik heb ook geen goedkeuring gegeven voor de huidige definitie van
de meter of gram of seconde. Ik zal dit nog eens aankaarten zodra ik
weer eens op m'n flikker krijg dat ik volgens mijn werkgever te laat
kom :)

--

Daniel Tryba

Rene Pijlman

26/11/03, 23:30

Daniel Tryba:
>Rene Pijlman:
>>Daniel Tryba:
>>>Het OO paradigma
>>
>> Is dat welgedefinieerd?
>
>Vast niet. Boeit ook niet.

Tsja, daar houdt het voor mij op. Zo werkt het gewoon niet in de techniek.

>Er zijn meerdere beschikbare implentaties

"Van wat?" Is dan de enige zinnige vraag, maar in deze context kennelijk
retorisch.

>> Op welke standaard, specificatie of publicatie doel je?
>
>Vanwaar deze starre houding en de drang naar regels?

Nou ja, je kunt natuurlijk als kunstenaar naar computerprogramma's kijken.
Dan kun je er mooi behang mee maken enzo.

Maar ik bekijk het als techicus. Ik wil software construeren die bepaalde
functionaliteit garandeert. Dat kun je een starre houding noemen, maar het
is de houding waardoor vliegtuigen vliegen en treinen
rijd^H^H^H^H^H^H^H^H^H^H^H^Hboten blijven drijven.

>>Wees welkom, builtin types!
>
>En waarom zouden builtins geen object kunnen zijn?

Omdat ik "types" zei, niet "classes".

--
René Pijlman

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

Daniel Tryba

26/11/03, 23:45

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>>>Het OO paradigma
>>> Is dat welgedefinieerd?
>>Vast niet. Boeit ook niet.
> Tsja, daar houdt het voor mij op. Zo werkt het gewoon niet in de techniek.

IMHO werkt het zo wel. Ongeacht of je weet waarom iets daadwerkelijk
functioneerd, het functioneerd (zo geeft een metalen draad licht indien
je er een spanningspotentiaal overheen zet). Het kan natuurlijk een leuk
streven zijn voor personen om daadwerkelijk te doorgronden waarom/hoe en
of iets werkt. Maar zelfs voor Newton een appel op z'n kop kreeg deed de
zwaartekracht het toch ook gewoon.

>>Er zijn meerdere beschikbare implentaties
> "Van wat?" Is dan de enige zinnige vraag, maar in deze context kennelijk
> retorisch.

Mijn nederlands is niet geweldig, maar waar dat op slaat lijkt me
duidelijk. Maar als je een poging doet om de discussie te laten
verzanden in gezeur over wat-tjes en dat-tjes dan geef ik me bij deze
gewonnen (ik heb geen tolerantie voor personen die zich dom voordoen):
Je hebt gelijk.

>>> Op welke standaard, specificatie of publicatie doel je?
>>Vanwaar deze starre houding en de drang naar regels?
>
> Nou ja, je kunt natuurlijk als kunstenaar naar computerprogramma's kijken.
> Dan kun je er mooi behang mee maken enzo.
>
> Maar ik bekijk het als techicus. Ik wil software construeren die bepaalde
> functionaliteit garandeert. Dat kun je een starre houding noemen, maar het
> is de houding waardoor vliegtuigen vliegen en treinen
> rijd^H^H^H^H^H^H^H^H^H^H^H^Hboten blijven drijven.

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.

>>>Wees welkom, builtin types!
>>En waarom zouden builtins geen object kunnen zijn?
> Omdat ik "types" zei, niet "classes".

Waarom sluit dat elkaar uit? BTW waarom zou een class een object moeten
zijn?

--

Daniel Tryba

Rene Pijlman

27/11/03, 00:15

Daniel Tryba:
>Het kan natuurlijk een leuk streven zijn voor personen om daadwerkelijk te
>doorgronden waarom/hoe en of iets werkt.

Inderdaad, dat heet "wetenschap" :-)

>Maar zelfs voor Newton een appel op z'n kop kreeg deed de zwaartekracht
>het toch ook gewoon.

Jawel, maar de zwaartekracht is geen techniek. Het is niet door mensen
geconstrueerd.

In de wetenschap (althans, in de exacte wetenschap) ontdekt men wiskundige
formules, die de werkelijkheid om ons heen vooralsnog lijken te
beschrijven.

In de techniek construeren mensen dingen die bepaalde functionaliteit
garanderen, aangenomen dat de werkelijkheid zich houdt aan voornoemde
formules van de wetenschap.

De zwaartekracht valt onder de wetenschap, de slingerklok onder de
techniek.

>Mijn nederlands is niet geweldig

Mwa, dat valt wel mee. Neem me niet kwalijk dat ik enkele spelfouten in de
quotes heb gecorrigeerd.

>>>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.

Ik vergelijk het maar met "het relationele model", waarover - o.a. wegens
commerciële belangen - allerlei vage onzin is beweerd, terwijl met name
mijnheer Codd het zeer concreet heeft gemaakt.

>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 :-)

>>>>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.

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

>BTW waarom zou een class een object moeten zijn?

Van mij hoeft dat niet hoor. Maar van jou toch wel? Jij bepleitte: "Het OO
paradigma (alles is een object)".

--
René Pijlman

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

robert

27/11/03, 10:15

Marcus <mark@ijbema.xs4all.nl.invalid>:
> robert wrote:
>> C en C++ zijn wat dat betreft gewoon ouderwets, met hun "alles is een
>> integer" aanpak.
>
> 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 :)

--
robert

Marcus

27/11/03, 10:15

robert wrote:
> Marcus <mark@ijbema.xs4all.nl.invalid>:
> > robert wrote:
> >> C en C++ zijn wat dat betreft gewoon ouderwets, met hun "alles is een
> >> integer" aanpak.
> >
> > 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".

Mark

robert

27/11/03, 10:15

Inca <shadow*movements@wanadoo.NOSPAM.invalid>:
> robert wrote:
>> > Definieer logisch?
>>
>> Dusdanig dat ik niet na hoef te denken of de gebruikte
>> programmeertaal zelf gaat afronden.
>
> (-: Dan moet je zelf een programmeertaal schrijven.

Of gewoon geen Python ;)

>> Ik kan de logica daarachter niet vinden: ik deel het ene getal door het
>> andere, en dan verwacht ik een wiskundig kloppend antwoord.
>
> Verdiep je eens in discrete wiskunde en wie weet wordt het 'logischer'?
> Bij mij werd bij wiskunde al vrij snel erin gehamerd dat je natuurlijke
> en reele (gebroken) getallen hebt, en dat dat heel verschillende dingen
> zijn. En dat het wiskundig prima kloppend is als je zegt dat 1 / 2 = 0,
> als het gaat over natuurlijke getallen. En het is slechts een kwestie
> van afspraak (en context) of je uitgaat van natuurlijke getallen of
> juist niet.

Als het gaat over natuurlijk getallen klopt je redenering inderdaad, maar
vooral in context van een deling lijkt het mij logischer dat er een reeël
getal uitkomt.

--
robert

robert

27/11/03, 10:15

Marcus <mark@ijbema.xs4all.nl.invalid>:
> robert wrote:
>
>> Marcus <mark@ijbema.xs4all.nl.invalid>:
>>
>> > robert wrote:
>> >
>> >> C en C++ zijn wat dat betreft gewoon ouderwets, met hun "alles is
>> >> een integer" aanpak.
>> >
>> > 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".

Nee, want het optellen van strings is niet duidelijk gedefinieerd in de
wiskunde, voor zover ik weet.

--
robert

Marcus

27/11/03, 11:15

robert wrote:
> Marcus <mark@ijbema.xs4all.nl.invalid>:
> > robert wrote:
> >
> >> Marcus <mark@ijbema.xs4all.nl.invalid>:
> >>
> >> > robert wrote:
> >> >
> >> >> C en C++ zijn wat dat betreft gewoon ouderwets, met hun "alles is
> >> >> een integer" aanpak.
> >> >
> >> > 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".
>
> Nee, want het optellen van strings is niet duidelijk gedefinieerd in de
> wiskunde, voor zover ik weet.

Maar wel in programmeertalen.

Mark

robert

27/11/03, 12:45

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?

--
robert

Michiel de Roo

27/11/03, 20:45

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.

Michiel.

Michiel de Roo

27/11/03, 21:00

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.

Rene Pijlman

27/11/03, 21:30

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);
}
}

--
René Pijlman

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

Michiel de Roo

27/11/03, 22:00

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.

Michiel.

Rene Pijlman

27/11/03, 23:15

Michiel de Roo:
>Rene Pijlman wrote:
>> Michiel de Roo:
>>>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.

Jawel, daardoor is i geen onderdeel van een object. Er wordt nergens een
HalloWereld ge-instantieerd.

--
René Pijlman

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

Michiel de Roo

27/11/03, 23:30

Rene Pijlman wrote:
> Michiel de Roo:
>
>>Rene Pijlman wrote:
>>
>>>Michiel de Roo:
>>>
>>>>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.
>
>
> Jawel, daardoor is i geen onderdeel van een object. Er wordt nergens een
> HalloWereld ge-instantieerd.
>

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

Michiel.

Inca

27/11/03, 23:45

Michiel de Roo wrote:
>> Jawel, daardoor is i geen onderdeel van een object. Er wordt nergens
>> een HalloWereld ge-instantieerd.
>
> Wat betref het instantieren denk ik toch van wel. Waarschijnlijk doet
> de ClassLoader dit voor je op het moment dat je java.exe aanroept.

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?
--
Inca
NEE - Geen handel met voorkennis
JA - Wel met een gouden tip
http://www.poldermodelstickers.nl/

Daniel Tryba

28/11/03, 00:30

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

Rene Pijlman

28/11/03, 00:30

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/tutorial/java/javaOO/classvars.html

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

--
René Pijlman

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

Daniel Tryba

28/11/03, 00:30

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/api/java/lang/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

Daniel Tryba

28/11/03, 00:30

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

Rene Pijlman

28/11/03, 01:30

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/developer/Books/effectivejava/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

robert

28/11/03, 08:15

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

Marcus

28/11/03, 10:00

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

Marcus

28/11/03, 10:00

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

robert

28/11/03, 10:15

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

Rene Pijlman

28/11/03, 11:00

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

robert

28/11/03, 11:15

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

Michiel de Roo

28/11/03, 12:00

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.

Rene Pijlman

28/11/03, 12:15

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

Rene Pijlman

28/11/03, 12:15

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

robert

28/11/03, 12:15

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

Michiel de Roo

28/11/03, 13:00

Rene Pijlman wrote:
> 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.?
>

Momenteel betaal ik EU 14. Het mag best iets duurder, maar boven de 20
wordt het minder interessant voor de gemiddelde website.

Het hangt ook van de klant af natuurlijk. Als ik een klant krijg die 5000
visits per dag heeft, worden servlets ineens wel een heel stuk
interessanter. Dan zouden de hosting kosten ook zowieso een stuk hoger zijn.

Ik ben ook vooral geinteresseerd in MMBase.

Michiel.

Rene Pijlman

28/11/03, 14:15

Michiel de Roo:
>Ik ben ook vooral geinteresseerd in MMBase.

Maar MMBase hosting is tegenwoordig toch goed verkrijgbaar?
http://www.backsoft.nl/mmbase/MMBase-hosting.htm
http://www.amaze.nl/products/hosting/
.... om er maar eens een paar te noemen.

Maar ik betwijfel eerlijkgezegd een beetje of zo'n Java-platform zich
leent voor goedkope mass hosting.

--
René Pijlman

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

Jaap Beetstra

28/11/03, 19:00

Rene Pijlman wrote:
> 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.

Heb je het nou over 'even een scrippie' of over iets met 487 signatures :)
Maar even serieus: Hoe kun je dit vermijden als je procedureel programmeert?
en waarom kan dat in een OO taal niet op dezelfde manier?

>
> 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/developer/Books/effectivejava/Chapter5.pdf

Maar daarin worden juist de tekortkomingen van de C enum construct
beschreven, en hoe het gebruik van OO helpt deze te overbruggen.

Groet, Jaap

Rene Pijlman

28/11/03, 19:15

Jaap Beetstra:
>Rene Pijlman:
>> 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.

>Hoe kun je dit vermijden als je procedureel programmeert?
>en waarom kan dat in een OO taal niet op dezelfde manier?

Het is volgens mij niet zozeer een kwestie van OO vs. procedureel, maar
van 1) "typed exceptions in signatures" vs. 2) untyped exceptions of 3)
exceptions die geen onderdeel uitmaken van de signature.

En 2 en 3, of 1 samen met de eerder genoemde abstracties van de
programmeur, zijn volgens mij de manieren om de kwestie te vermijden.

>> 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/developer/Books/effectivejava/Chapter5.pdf
>
>Maar daarin worden juist de tekortkomingen van de C enum construct
>beschreven, en hoe het gebruik van OO helpt deze te overbruggen.

Hoezo "maar"? Dit doet niets af aan mijn punt over de Java-code die nodig
is om het equivalent van de enum in C te krijgen.

--
René Pijlman

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

Jaap Beetstra

28/11/03, 22:00

Rene Pijlman wrote:
> Het is volgens mij niet zozeer een kwestie van OO vs. procedureel,
> maar van 1) "typed exceptions in signatures" vs. 2) untyped
> exceptions of 3) exceptions die geen onderdeel uitmaken van de
> signature.
>
> En 2 en 3, of 1 samen met de eerder genoemde abstracties van de
> programmeur, zijn volgens mij de manieren om de kwestie te vermijden.

Ok, maar checked excepties zijn geen noodzakelijk onderdeel van OO (ik neem
aan dat je checked bedoelt ipv typed?). En in Java kun je ze altijd nog `of
wrappen in een unchecked exception, `of ze volledig negeren. Dan hoef je de
signature niet te veranderen.
Het al dan niet zinnig zijn van de 'alles is een object' gedachtengang (waar
het eerst over ging) is een andere issue.

>>> 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/developer/Books/effectivejava/Chapter5.pdf
>>
>> Maar daarin worden juist de tekortkomingen van de C enum construct
>> beschreven, en hoe het gebruik van OO helpt deze te overbruggen.
>
> Hoezo "maar"? Dit doet niets af aan mijn punt over de Java-code die
> nodig is om het equivalent van de enum in C te krijgen.

Je claimt dat het hoofdstuk gaat over wat je allemaal moet doen om een
enum-equivalent te krijgen. Het hoofdstuk gaat niet over hoe enums te
simuleren, maar over hoe OO enums kan vervangen/verbeteren. De directe
mapping van een enum is een simpele constante, maar dit is lang zo krachtig
niet. Met weinig moeite kun je in een OO-taal dingen bereiken die je met
enums in een procedurele taal veel meer moeite kosten, en tot hogere
complexiteit leiden.

Groet, Jaap

Rene Pijlman

28/11/03, 23:00

Jaap Beetstra:
>Het al dan niet zinnig zijn van de 'alles is een object' gedachtengang (waar
>het eerst over ging) is een andere issue.

Had je dit niet gezien? :-)
>>>> Maar goed, ik dwaal af van jouw vraag.

>Het hoofdstuk gaat niet over hoe enums te simuleren, maar over hoe OO enums
>kan vervangen/verbeteren.

OK, het is meer dan een equivalent, dat is waar.

Maar dat dit soort complexe patronen [1] nodig zijn voor een conceptuele
trivialiteit als een type dat bestaat uit een lijstje waarden, vind ik
maar bizar.

[1] "... define a class representing a single element of the enumerated
type, and don’t provide any public constructors. Instead, provide public
static final fields, one for each constant in the enumerated type."

--
René Pijlman

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

Daniel Tryba

29/11/03, 05:45

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>Het hoofdstuk gaat niet over hoe enums te simuleren, maar over hoe OO enums
>>kan vervangen/verbeteren.
>
> OK, het is meer dan een equivalent, dat is waar.
>
> Maar dat dit soort complexe patronen [1] nodig zijn voor een conceptuele
> trivialiteit als een type dat bestaat uit een lijstje waarden, vind ik
> maar bizar.

Maar je hebt zo'n complex ding helemaal niet nodig om de enum te
emuleren. Immers:

> [1] "... define a class representing a single element of the enumerated
> type, and don?t provide any public constructors. Instead, provide public
> static final fields, one for each constant in the enumerated type."
>

Enumerated type! In C is dat gewoon altijd een int(?)! Dus als je dat
wilt kan je met

public class EnumFruit
{
private static final int APPEL=0;
private static final int PEER=1;
private static final int BANAAN=2;
}

volstaan.

De classe kan je dan misbruiken als:

public class Foo
{
public static void main(String[] args)
{
switch(args[0])
{
case EnumFruit.APPEL:
System.out.println("arg0 was 0");
break;
default:
System.out.println("arg0 was geen 0");
}
}
}

Mocht je EnumFruit.FOO te veel tik werk vinden dan kan je EnumFruit als
interface bestempelen en die implementen in de Foo classe.

Een leuke URL mbt dit onderwerp:
http://developer.java.sun.com/developer/Books/shiftintojava/page1.html

Bevat voorbeelden die wel duidelijk maken dat het verdomd handig is om
de "complexe" methode te implementeren:
<q>
Not only is this legal C:

typedef enum {FUJI, PIPPIN, GRANNY_SMITH} apple_t;
typedef enum {NAVEL, TEMPLE, BLOOD} orange_t;

/* Mixing apples and oranges */
orange_t myFavorite = PIPPIN;

but so is this atrocity:

/* Tasty citrus-flavored applesauce!!! */
orange_t x = (FUJI - PIPPIN)/TEMPLE;
</q>

--

Daniel Tryba

Daniel Tryba

29/11/03, 06:15

Rene Pijlman <reply.in.the.newsgroup@my.address.is.invalid> wrote:
>>> 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.

Dat snap ik dus niet, ik heb niets met filosofie, je zult het me dus
moeten uitleggen.

> 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.

Daar is niet bijzonders aan, die zelfde wensen heeft vrijwel iedere
programmeur.

> Als Java in al die dingen goed was dan gebruikte ik uitsluitend Java.

Ik moet er niet aan denken me zelf slechts 1 taal op te leggen. En 1
taal voor alle momenten lijkt me (tot nu toe) onmogelijk.

> 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.

Dat is in een procedurele taal niet anders. Als je de return value
veranderd zul je overal moeten checken of die nieuwe (extra) waarde
overal netjes afgevangen wordt.

> 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/developer/Books/effectivejava/Chapter5.pdf
>
> Is een taal met een builtin enum nou niet veel makkelijker? Mis ik ook
> bij Python trouwens.

Dat kan ik niet bevestigent beantwoorden, zelfs in deze pdf staat al een
simpele Java implementatie van een enum:
<q page='16'>
The typesafe enum pattern has few disadvantages when compared to the
int pattern. Perhaps the only serious disadvantage is that it is more
awkward to aggre- gate typesafe enum constants into sets. With int-based
enums, this is traditionally done by choosing enumeration constant
values, each of which is a distinct positive power of two, and
representing a set as the bitwise OR of the relevant constants:

// B it-flag variant of int enum pattern
public static final int SUIT_CLUBS = 1;
public static final int SUIT_DIAMONDS = 2;
public static final int SUIT_HEARTS = 4;
public static final int SUIT_SPADES = 8;
public static final int SUIT_BLACK = SUIT_CLUBS | SUIT_SPADES;
</q>

> 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.

Nou kan ik persoonlijk ook niet programmeren met pointers. Zelf hou ik
dan ook nog eens van static type checking ( if(1) of if("") dienen te
worden vermeden ten voorkeur van eenduidige expressies). Een taal als
Java met zowel objeten en primitieven en statisch types is IMHO een
goede manier waar je in een OO taal geen primitieven wilt (het jongleren
met types (eventueel in container objecten) is een ramp).

Op papier zit C# (heb alle de reference gelezen) er stukken beter uit
wat de voor Java genoemde nadelen betreft, puur omdat daar wel alle
primitieven gewone objecten zijn (bv 1.toString() itt
Integer.toString(1) (kan ook met '""+1' echter dat geeft leuke effecten
als bv: 'a'+1+"foo" (tgv operator overloading )). Er zijn wel weer
andere nadelen zoals operator overloading (maakt dingen onzichtbaar
complexer).

--

Daniel Tryba

Daniel Tryba

29/11/03, 06:30

robert <{n.i.w.s}@allyourbass.org.invalid> wrote:
> > 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.

Het lijkt me vooral lastig als je met code van andere moet werken, in
python is een coding standard nog velen malen belangrijker. En aangezien
de enige goede standaard de standaard van elke onafhankelijke progger is
voorzie ik een probleem.

Verder vind ik het uiterst goor dat de markup van je code de
functionaliteit bepaalt.

--

Daniel Tryba