[Java] [s]InputStream to String[/s] Generics :)

[hobbit_be]

Een heel simpel vraagje maar snuffelen door de Java-docs was niet echt helpful.

Ik lees een File en moet in 1 keer de content ervan hebben.

het is 100% zeker een Character File en dus niets binairs...

Java:

new FileReader(aResource)

maar nu zit ik vast aan die InputStream, een constructor voor String met Reader bestaat niet moet ik nou echt een .read(char[]) gaan doen of bestaat er een standaard help-classes oid? ...

als die read(char[]) moet - hoe zou ik dat doen aangezien een Reader geen size meegeeft (om die char ineens te size)? Toch geen loopje met read's ofzo?

beginners vraagje vast

[Verwijderd]

hobbit_be schreef op 17 maart 2003 @ 13:51:
maar nu zit ik vast aan die InputStream, een constructor voor String met Reader bestaat niet moet ik nou echt een .read(char[]) gaan doen of bestaat er een standaard help-classes oid? ...

Ik heb dit zelf nooit echt gewild, maar in principe kan het wel met read(). Met read moet je echter een geinitialiseerde array meegeven (dwz char[] buf = new char[xxx]). Daaruit is dus al op te maken hoeveel characters er gelezen moeten worden (lengte van het array). Als je hier een array van maakt met net zoveel elementen als het bestand lang is moet dat in principe goed gaan.

[mbravenboer]

Java:

  public String getString(InputStream stream) throws IOException {
    StringBuffer result = new StringBuffer();
    Reader reader = new BufferedReader(new InputStreamReader(stream));

    char[] buffer = new char[4096];
    int nch;

    while ((nch = reader.read(buffer, 0, buffer.length)) != -1) {
      result.append(buffer, 0, nch);
    }

    reader.close();
    return result.toString();
  }

[mbravenboer]

Dat stond trouwens hier: org.mbravenboer.io.DefaultStreamReadTools

[hobbit_be]

yo sniff - nog nooit een filetje moeten inlezen ofzo? daar wordt ik nou zo moe van he in Java. al die normale dingen - doe maar zelf. Nog een pittig detail: heb het dus idd zo opgelost maar heb er ook nog even Unicode case checking moeten bijsteken... Ik begin al te denken dat zo'n loopje het enige viable is.

edit:
net voor mbravenboer gepost dus niet gezien - bedankt - weer 5 minuten minder werk ... nou wat een collectie aan spul ook ga ik eens in snollen

[ Voor 23% gewijzigd door hobbit_be op 17-03-2003 14:10 ]

[.oisyn]

mbravenboer schreef op 17 maart 2003 @ 14:05:
Dat stond trouwens hier: org.mbravenboer.io.DefaultStreamReadTools

beetje offtopic, maar ik zat eens naar deze code te kijken:

Java:

  public Iterator<String> getIterator(InputStream stream)  throws IOException {
    return getList(stream).iterator();  
  }

  public List<String> getList(InputStream stream) throws IOException {
    ArrayList<String> result = new ArrayList<String>();
    String s;

    BufferedReader data = new BufferedReader(new InputStreamReader(stream));
    while((s = data.readLine())!=null) {
      result.add(s);
    }            
        
    data.close();
    return result;
  }

En dan heb ik het met name over die getIterator () functie... is het handiger om een eigen iterator te schrijven die bij elke next () een readLine () uitvoert (of eigenlijk 1 regel gebufferd, omdat je anders de hasNext () niet kunt implementeren)? Want nu lees je eerst de hele file in, en dat lijkt me nogal geheugen-vretend bij grote files

[mbravenboer]

.oisyn: En dan heb ik het met name over die getIterator () functie... is het handiger om ...

Zeker, dat is een prima idee. De code zal ook typisch geen kandidaat zijn voor een standaard library. Vaak moet je echter een afweging maken tussen efficientie, requirements en benodigde tijd. Bij beperkte requirements kom je dan op deze oplossing .

Het aardig is wel dat alles volledig verborgen is voor de gebruikers van StreamReadTools. Mocht ik dus ook tijd over hebben, dan kan ik het aanpassen zonder dat dit invloed heeft op de clients.

[hobbit_be]

hey nu merk ik pas op:

Iterator<String> Templates In Java? nou val ik dood (quasi) is dit standaard?

ik gebruik JDK 1.4.1 ... (en gaat dat nog werken op een oudere JRE - daarmee bedoel ik compileert ie 'gewone' byte-code of blijft die informatie bestaan (voor mogelijke reflectie toestanden)). If not kan ik weer honderden Casts gaan weggooien. Maar zou wel erg lekker zijn.

edit:
JBuilder geeft alvast aan dat ie er niets van wil weten..

[ Voor 11% gewijzigd door hobbit_be op 17-03-2003 14:28 ]

[mbravenboer]

hobbit_be: Iterator<String> Templates In Java? nou val ik dood (quasi) is dit standaard?

Het komt in 1.5, was al tijden beschikbaar buiten Sun om (GJ) en is op dit moment early access beschikbaar bij Sun zelf (klik maar eens op Java Generics hieronder )

en gaat dat nog werken op een oudere JRE

In theorie wel, maar onlangs hebben ze bij Sun besloten dat hun eigen compiler oudere targets niet zal supporten. Op dit moment nog wel.

[hobbit_be]

ben al effe gaan zien (vond ik wel belangrijk zo'n dingen) maar blijkbaar very beta en is niets anders dan een precompiler. Echt portable nog niet dus. Nog effe wachten op 1.5 (alhoewel ik tegen die tijd liever met C# aan het knoeien gaan )

toch wel leuk dat het kan. Doet me denken aan die Virtual C++ compilers toen er nog alleen C waren .

[mbravenboer]

hobbit_be: blijkbaar very beta

Die disclaimers moet je een beetje met een korreltje zout nemen: de codebase is in feite hetzelfde als die van de compiler in 1.4.1. De compiler is al ongeveer (schatting) 2 jaar beschikbaar in early access vorm en is in feite gewoon overgenomen van het GJ project.

en is niets anders dan een precompiler.

De methode van compilatie is heel anders dan C++ templates, maar dat mag je denk ik wel als positief zijn. Generics worden echter niet doorgevoerd tot in de bytecode (in tegenstelling tot generics in C#, waarvoor de IL wel wordt aangepast). Precompiler is een wat rare term: het is gewoon de Java compiler van de toekomst.

Echt portable nog niet dus. Nog effe wachten op 1.5

Portable wel, wachten is voor produktie code wel verstandig .

[.oisyn]

mbravenboer schreef op 17 March 2003 @ 14:44:
De methode van compilatie is heel anders dan C++ templates

ik kwam een dergelijke opmerking van je al eerder tegen. Wat is er precies anders aan?

[Soultaker]

Naar ik meende waren Java generieke typen echte typen, in die zin dat ze getypechecked en gecompileerd worden. C++ templates bestaan daarintegen alleen in code-vorm. Zonder de broncode is het niet mogelijk om een template te instantiëren en wordt er geen type checking op de template code uitgevoerd. Dit kan mbravenboer (of iemand anders met verstand ervan) echter misschien beter even verifiëren.

[mbravenboer]

Ja inderdaad, daar komt het wel op neer. C++ templates zijn echte templates: zoals je uiteraard weet wordt er voor elke parameter die je meegeeft code gegenereerd. Generics in C# en Java hebben meer weg van de manier waarop nu al generieke verzamelingen geimplementeerd zijn in Java/C#. Alle instantiaties met parameters delen (in ieder geval in de bytecode of de IL) dus dezelfde code. Het zijn dus echt geparameterizeerde typen (althans in het geval van Java dus minder dan bij C#) en niet stukjes code die je parameterizeert met van alles en nogwat. Je kan dus ook alleen met typen parameterizeren en niet met bijv constanten.

[Verwijderd]

hobbit_be schreef op 17 maart 2003 @ 14:06:
yo sniff - nog nooit een filetje moeten inlezen ofzo? daar wordt ik nou zo moe van he in Java. al die normale dingen - doe maar zelf.

Sniff Tuurlijk heb ik wel eens een file ingelezen, maar dan regel voor regel of character voor character, nooit het de hele file in een keer.

[mbravenboer]

De details kan je overigens nagaan in de publikaties over beide voorstellen:

http://www.mbravenboer.org/java_resources.xhtml
http://www.mbravenboer.org/dotnet_resources.xhtml

[.oisyn]

mbravenboer schreef op 17 March 2003 @ 16:28:
Ja inderdaad, daar komt het wel op neer. C++ templates zijn echte templates: zoals je uiteraard weet wordt er voor elke parameter die je meegeeft code gegenereerd. Generics in C# en Java hebben meer weg van de manier waarop nu al generieke verzamelingen geimplementeerd zijn in Java/C#. Alle instantiaties met parameters delen (in ieder geval in de bytecode of de IL) dus dezelfde code. Het zijn dus echt geparameterizeerde typen (althans in het geval van Java dus minder dan bij C#) en niet stukjes code die je parameterizeert met van alles en nogwat. Je kan dus ook alleen met typen parameterizeren en niet met bijv constanten.

maar de java generics compiler die al beschikbaar was is toch compatible met de java bytecode, en dus wordt er ook code gegenereerd voor elk type? Tenminste, dat dacht ik altijd

Overigens is dat slechts een implementatie-detail, in weze verschilt het niet veel. Goed, je hebt bij C++ een template definitie nodig, maar dat was voor normale classes ook al het geval. De implementatie hoeft volgens de standaard niet bekend te zijn en kan dus gewoon gecompiled worden naar een object-file of library. Nadeel is dat alleen de compiler van Comeau dit ook echt ondersteund

[mbravenboer]

.oisyn: maar de java generics compiler die al beschikbaar was is toch compatible met de java bytecode, en dus wordt er ook code gegenereerd voor elk type? Tenminste, dat dacht ik altijd

Nee, er worden dus casts ingevoegd.

Voorbeeldje:

code:

import java.util.ArrayList;
import java.util.List;

public class Test {

  public void doSomething() {
    List<String> list = new ArrayList<String>();
    list.add("Bla Bla Bla");
    
    String s = list.get(0);
  }
}

code:

// Decompiled by Jad v1.5.8e. Copyright 2001 Pavel Kouznetsov.
// Jad home page: http://www.geocities.com/kpdus/jad.html
// Decompiler options: packimports(3)
// Source File Name:   Test.java

import java.util.ArrayList;
import java.util.List;

public class Test
{

    public Test()
    {
    }

    public void doSomething()
    {
        ArrayList arraylist = new ArrayList();
        arraylist.add("Bla Bla Bla");
        String s = (String)arraylist.get(0);
    }
}

Overigens is dat slechts een implementatie-detail, in weze verschilt het niet veel.

Dat is niet helemaal zo: in een meer dynamische omgeving zoals Java, met veel reflectie mogelijkheden maakt het wel wat verschil of instanties nog steeds tot dezelfde klasse behoren en dergelijke.

[ Voor 12% gewijzigd door mbravenboer op 18-03-2003 09:28 ]

[hobbit_be]

mbravenboer schreef op 18 March 2003 @ 09:28:
[...]

Nee, er worden dus casts ingevoegd.
[...]

vandaar dat ik al zei dat dit een pure preprocessor is: in feite kun je (eenvoudig? die templates zelf genereren. Er is ook ergens een UI Toolkit die zo'n preprocessor heeft en natuurlijk MFC. Maar ik vermoed dat als ze zeggen dat 1.5 niet backwards compatible is ze misschien toch die casting info gaan 'opslagen (C#)' , want zo is de code natuurlijk 100% compatible... of blijven ze bij deze oplossing. Vandaar dat ze ook geen primitives ondersteunen . persoonlijk vind ik die primitives een ronduit schandaal. zo inconsistent! (heb net een reflectie extensie moeten schrijven die met interface moet werken en private members) zodra je daar met primitives begint moet je gaan 'wrappen'... wat vinden jullie daarvan? (qua logica he - ik gebruik ook int's , null, etc)..

[mbravenboer]

hobbit_be: vandaar dat ik al zei dat dit een pure preprocessor is: in feite kun je (eenvoudig? die templates zelf genereren.

Dat is toch niet helemaal zo: wat je hier boven ziet is natuurlijk slechts een representatie in Java van bytecode. Het is geen tussenstap op weg naar de bytecode. Ook zijn preprocessors meestal nogal lexicaal en hier wordt volledige semantische analyse en typechecking gedaan. De bytecode bevat ook attributen die de parameters aangeven, anders zou je voor code met geparameterizeerde typen geen separate compilation hebben, wat het hele systeem gelijk zinloos maakt (Java Collections zijn bijvoorbeeld al gecompileerd).

Maar ik vermoed dat als ze zeggen dat 1.5 niet backwards compatible is ze misschien toch die casting info gaan 'opslagen (C#)'

Er zitten wat attributen in (die een runtime mag begrijpen, maar niet hoeft te begrijpen). Dat is dus de methode waarmee het in de bytecode wordt doorgevoerd. Het punt zit met name in de reflectie en de afhankelijkheid van andere nieuwe taal features van nieuwe klassen in 1.5. De foreach is bijvoorbeeld afhankelijk van java.lang.Iterable, die niet beschikbaar is in oudere JVMs.

Vandaar dat ze ook geen primitives ondersteunen . persoonlijk vind ik die primitives een ronduit schandaal. zo inconsistent!

Het is juist consistent, vanuit het oogpunt van Java. Het zou juist vreemd zijn als ze een gescheiden wereld in stand houden voor "normale" Java, maar wel primitieven toestaan als type parameters. Overigens zal autoboxing ook invloed hebben op Java Generics. Waarschijnlijk komt er binnenkort al wel een early access update met deze zooi.

[hobbit_be]

hmm allemaal wel interessant, maar ivm die primitive doelde ik niet op het gebruik in collections (dat dat rot is weten we allemaal), ik heb het generaal (sorry nederengels) over dat ze bestaan. Een taal die 100% 'oop' wil zijn durft nog afkomen met zo'n dingen heb ik nooit gesnapt. In C# zijn er geen primitives(of ze worden transparent gehide) en 3.toString is perfect normaal , en dat vind ik maar normaal ook. en Strings die eigenlijk opgebouwd zijn op char[] dat is toch ook helemaal te gek vind je niet? Java is teveel C/C++ (zonder de goodies:). en helaas met al hun versies maken ze het zowaar nog moeilijker dan te ontwikkelen dan C++/C# (probeer maar eens uit te leggen dat JDK 1.4 echt wel niet 1.1 is aan een client: java is toch java?).

Vergeef de rant BTW - vandaag weer 2 uur kwijt geraakt om te ontdekken hoedat Swing een event stuurt als de content word gewijzigd: ze extenden de awt maar niet alle functies... Ik apprecieer alle posts van Java op GoT heel erg...

[mbravenboer]

hobbit_be: Een taal die 100% 'oop' wil zijn durft nog afkomen met zo'n dingen heb ik nooit gesnapt. In C# zijn er geen primitives.

Niemand een mooi lijstje van features die een OO taal moet hebben, omdat dat een nogal subjectieve verzameling eisen is. Mag een zichtbaar onderscheid tussen reference types en value types bijvoorbeeld wel in een pure OO taal? Mogen out parameters? Mogen ref arguments?

Zoals je zelf al aangeeft heeft C# wel primitieven, dat ze automagisch object kunnen worden (zoals ook in Java nu schijnt te gaan gebeuren), maakt de zaak naar mijn mening (een subjectieve eis dus) alleen nog maar erger. We hebben er hier op GoT ook wel eens over gediscussieerd wat ik dan wel zou willen zien, maar kan me niet meer herrinneren in wat voor soort topic dat was.

[kenneth]

Ik meen dat het dit topic was: [rml][ Java/.NET] primitieve datatypes[/rml]

[.oisyn]

mbravenboer schreef op 18 March 2003 @ 09:28:
Dat is niet helemaal zo: in een meer dynamische omgeving zoals Java, met veel reflectie mogelijkheden maakt het wel wat verschil of instanties nog steeds tot dezelfde klasse behoren en dergelijke.

Mja, maar wil je wel dat ze tot dezelfde klasse behoren? Imho is een Vector<int> een compleet ander type dan een Vector<String>, en ik zie ook niet hoe die compatible zouden kunnen zijn met elkaar.

Maar ondersteund java nou ook primitieven als template argumenten? En wordt er dan ook ge-autoboxed? Erg fout imho... als ik een vector van ints wil heb ik liever dat ie dat in een int[] opslaat ipv elke int te instantieren als een Integer object en die in een Object[] array te gooien. Maar goed, dat kan natuurlijk weer niet als er geen aparte code wordt gegenereerd

Het mooie van C++ templates vind ik overigens de specialization: je kunt een template klasse specializeren op grond van een bepaald type of constante. Het mooiste (edoch relatief nutteloos ) voorbeeld hiervan kwam ik laatst tegen op flipcode, daar had iemand een template constructie gemaakt om @ compile-time het aantal bits van een int constante te berekenen:

C++:

template <unsigned i> struct NumBits
{
    enum { NUM_BITS = NumBits<i >> 1>::NUM_BITS + 1 };
};

template <> struct NumBits<0>
{
    enum { NUM_BITS = 0 };
};

// vervolgens kun je het aantal bits zo berekenen
int aantal = NumBits<300>::NUM_BITS

/*
   een goed gebruik ervan is het gebruiken van bit fields in een
   class/struct, aan de hand van het aantal mogelijkheden dat een
   attribuut kan hebben:
*/
struct MijnKlasse
{
    enum optie_t
    {
        OPTIE_1, OPTIE_2, BLA, AAP, NOOT, MIES,
        NUM_OPTIES
    };

    optie_t optie   : NumBits<NUM_OPTIES>::NUM_BITS;
};

Compile-time polymorphisme is op deze manier ook mogelijk

Maar goed, het meeste is in java niet eens bruikbaar omdat java de nare eigenschap heeft dat altijd de generaalste conversie wordt gekozen... en ik snap nog steeds niet waarom ze dat nou gedaan hebben

edit:
topictitel aangepast

[Alarmnummer]

.oisyn schreef op 19 March 2003 @ 11:11:

[...]


Mja, maar wil je wel dat ze tot dezelfde klasse behoren? Imho is een Vector<int> een compleet ander type dan een Vector<String>, en ik zie ook niet hoe die compatible zouden kunnen zijn met elkaar.

Een int en een string hebben verder niet veel overeenkomstig, en het grootste gemeenschappelijke type is het top type (het supertype van ieder type). Maar een Vector < Persoon > en Vector <Slager > hebben wel degelijks iets overeenkomstigs.

Trouwens Vector < Persoon > is geen supertype van Vector < Slager >. Convariantie vind niet plaatst over typeargumenten.

Vector < Persoon > v = new Vector < Slager >();

zal dan ook een typefout opgeven. Een uitzondering hierop (in java) is:

Persoon[] p = new Slager[10];

Nu krijg je compiletime geen foutmelding, maar runtime krijg je een foutmelding als je er bv een timmerman in wilt plaatsen.

Maar ondersteund java nou ook primitieven als template argumenten?

nee

En wordt er dan ook ge-autoboxed? Erg fout imho... als ik een vector van ints wil heb ik liever dat ie dat in een int[] opslaat ipv elke int te instantieren als een Integer object en die in een Object[] array te gooien. Maar goed, dat kan natuurlijk weer niet als er geen aparte code wordt gegenereerd

Als een template argument ook echt een primitieve kon zijn, dan heeft autoboxing geen vervelende bijwerkingen. In de collectie zitten dan ook echt primitieven. Alleen kan je door autoboxing het volgende wel schrijven:
intArray[10].toString();

Zo heb je dus het beste van beide werelden.

[ Voor 28% gewijzigd door Alarmnummer op 19-03-2003 11:49 ]

[.oisyn]

[nohtml]

Alarmnummer schreef op 19 maart 2003 @ 11:42:
[...]

Dat is vreemd. Ik zie als ik je quote staan:
vector < int > en vector < string >

kwam door mijn html-rechten
is nu fixed

Een int en een string hebben verder niet veel overeenkomstig, en het grootste gemeenschappelijke type is het top type (het supertype van ieder type). Maar een Vector < Persoon > en Vector hebben wel degelijks iets overeenkomstigs.

mja, Object, maar dat zou ook zijn als het apart gecompileerd werd zoals in C++

Als een template argument ook echt een primitieve kon zijn, dan heeft autoboxing geen vervelende bijwerkingen. In de collectie zitten dan ook echt primitieven. Alleen kan je door autoboxing het volgende wel schrijven:
intArray[10].toString();

nou ik bedoelde meer een soort van autoboxing in het geval van templates. mbravenboer liet een paar posts terug een stukje gedecompilede code zien van een template class aanroep. De casts worden er dus bij gezet, terwijl de code generiek is (en dus met Object werkt). De compiler zou primitieven in principe ook kunnen afvangen, en deze automatisch "casten" van en naar het object-type wat bij de primitive hoort

deze code:

Java:

Vector<int> v = new Vector<int> ();
v.add (23);
int i = v.get (0);

zou dan gecompiled kunnen worden naar zoiets

Java:

Vector v = new Vector ();
v.add (new Integer (23));
int i = ((Integer)v.get (0)).intValue ();

ik snap eigenlijk niet waarom dat er dan niet in zit

[Alarmnummer]

.oisyn schreef op 19 maart 2003 @ 11:49:
[nohtml]
mja, Object, maar dat zou ook zijn als het apart gecompileerd werd zoals in C++

Object is alleen het supertype van alle objecten, maar niet van andere types zoasl een functie type, of een primitief type.

nou ik bedoelde meer een soort van autoboxing in het geval van templates. mbravenboer liet een paar posts terug een stukje gedecompilede code zien van een template class aanroep. De casts worden er dus bij gezet, terwijl de code generiek is (en dus met Object werkt). De compiler zou primitieven in principe ook kunnen afvangen, en deze automatisch "casten" van en naar het object-type wat bij de primitive hoort


deze code:

Java:

Vector<int> v = new Vector<int> ();
v.add (23);
int i = v.get (0);

zou dan gecompiled kunnen worden naar zoiets

Java:

Vector v = new Vector ();
v.add (new Integer (23));
int i = ((Integer)v.get (0)).intValue ();

ik snap eigenlijk niet waarom dat er dan niet in zit

Dat is autoboxing en dat is (helaas) geen onderdeel van gj. Ik ben al blij dat er covariante returntypes inzitten We moeten nog even wachten op jdk1.5 (alias tiger) en dan zijn we weer helemaal blits *kijkt al uit naar attributen*

[ Voor 5% gewijzigd door Alarmnummer op 19-03-2003 11:58 ]

[Verwijderd]

Alarmnummer schreef op 19 maart 2003 @ 11:57:
We moeten nog even wachten op jdk1.5 (alias tiger) en dan zijn we weer helemaal blits *kijkt al uit naar attributen*

offtopic:
Oh? Komen attributen ook in 1.5? Dat wist ik nog niet. Mooi

[Alarmnummer]

Verwijderd schreef op 19 maart 2003 @ 12:04:
[...]

offtopic:
Oh? Komen attributen ook in 1.5? Dat wist ik nog niet. Mooi

check: http://java.sun.com/features/2002/03/totiger.html

En ik ben ook heel blij dat er attributen in komen. Ik heb een paar voorbeeldjes gezien waardoor je weer op een volledig nieuwe manier tegen code aan kan gaan kijken. Zelfs andere paradigma`s zijn hiermee mogelijk zoals AOP (Aspect Oriented Programming). Je kan op bepaalde punten van je code gaan inhaken en daar functionaliteit aan toevoegen. Het zal wel niet zo krachtig zijn als een taal die echt AOP aankan, maar alle beetjes zijn meegenomen.

[ Voor 48% gewijzigd door Alarmnummer op 19-03-2003 12:09 ]

[Verwijderd]

Alarmnummer schreef op 19 maart 2003 @ 12:07:
[...]
check: http://java.sun.com/features/2002/03/totiger.html

Hmm, kennelijk overheen gelezen, gaat het hier om JSR 175? Is hier ergens anders meer (voorbeelden e.d.) over te vinden? (Sorry voor het offtopic brengen van dit op zich toch al offtopic topic )

[Alarmnummer]

Dat is hem idd, zie verder: http://attrib4j.sourceforge.net/ als je met java & attributes wilt experimenteren. En maakt verder niet uit dat het offtopic gaat, hierdoor ontstaan meestal de meest interessante discussies.

[ Voor 7% gewijzigd door Alarmnummer op 19-03-2003 12:30 ]

[.oisyn]

is er iemand die mij een verklaring hierop kan verschaffen:

.oisyn schreef op 19 maart 2003 @ 11:11:
Maar goed, het meeste is in java niet eens bruikbaar omdat java de nare eigenschap heeft dat altijd de generaalste conversie wordt gekozen... en ik snap nog steeds niet waarom ze dat nou gedaan hebben

en dan heb het over zoiets:

Java:

void functie (Object o) { }
void functie (String s) { }

als je functie ("blaat") doet, dan wordt functie (Object) aangeroepen. Waarom is dat in hemelsnaam? Dat is toch totaal niet handig?

[Glimi]

Da's imho alleen zo als je dit geval hebt

Java:

Object s = new String( "Hoi" );
functie( s );

Dan zal idd functie( Object ) aangeroepen worden, maar aanders zal gewoon het passende type (welke compile time gemapt kan worden) genomen worden.
(kan het even niet testen, maar dit stond me bij)

[edit] Ik had gelijk

Java:

class Jhoi  {
    

    public static void main(String args[]) {
        
        Onzin z = new Onzin( );
        Object s = new String( "Hoi!!!" );
        z.functie( "Hoi" );
        z.functie( s ); 
    }
    
}

class Onzin {
    
    
    public void functie( Object o ) {
        
        System.out.println( "Object" );
    }
    
    public void functie( String s ) {
        
        System.out.println( "String" );
    }
}

Geef inderdaad
"String"
"Object" als output

Volgens mij had C++ precies hetzelfde als je met pointers van ruimere types werkte toch?

[ Voor 48% gewijzigd door Glimi op 19-03-2003 12:41 ]

[Alarmnummer]

.oisyn schreef op 19 maart 2003 @ 12:31:
is er iemand die mij een verklaring hierop kan verschaffen:


[...]


en dan heb het over zoiets:

Java:

void functie (Object o) { }
void functie (String s) { }

als je functie ("blaat") doet, dan wordt functie (Object) aangeroepen. Waarom is dat in hemelsnaam? Dat is toch totaal niet handig?

Ben ik helemaal met je eens. Gelukkig zal compiletime ook de meest strakke worden gekozen. Alleen runtime de meest wijde. Ik weet eerlijk gezegd de reden ook niet waarom dit is gedaan.

void foo(String s){}

void foo(Object o){}

Object o = new String("");
foo(o)

Nu zal (runtime) ook foo(Object o) worden gekozen, ipv foo(String s). Als dat trouwens wel kon, had je dat geklungel met die visitors ook niet meer nodig, want dat had je een taal die tenminste dispatch op functie argumenten aankan, ipv alleen een dispatch op het 1e impliciete argument van een methode, this, aankon.

[ Voor 3% gewijzigd door Alarmnummer op 19-03-2003 12:37 ]

[Verwijderd]

Edit: Laat maar, verkeerd begrepen

[ Voor 95% gewijzigd door Verwijderd op 19-03-2003 12:38 ]

[.oisyn]

Hmmm, nu wordt ik gek... ik had het idd over de compiletime bepaling, niet de runtime bepaling. Ik kwam het laatst tegen toen ACM het visitor design pattern wilde maken, maar hij niet een 'default handler' kon maken, omdat anders die altijd aangeroepen werd. De verklaring was dat altijd de meest generieke call werd gekozen.

Maar nu ik het zelf test gaat het idd ook gewoon goed... ik snap er niets van

[Alarmnummer]

.oisyn schreef op 19 maart 2003 @ 12:48:
Hmmm, nu wordt ik gek... ik had het idd over de compiletime bepaling, niet de runtime bepaling. Ik kwam het laatst tegen toen ACM het visitor design pattern wilde maken, maar hij niet een 'default handler' kon maken, omdat anders die altijd aangeroepen werd. De verklaring was dat altijd de meest generieke call werd gekozen.

Maar nu ik het zelf test gaat het idd ook gewoon goed... ik snap er niets van

code:

interface PersoonVisitor{

   visit(Persoon p);

   visit(Slager s);

   visit(Timmerman);
}

interface Persoon{
     void accepts(PersoonVisitor v);
}

class Slager implements Persoon{
    void accepts(PersoonVisitor v){v.visit(this);}
}

Dit zou goed moeten gaan (dus visit(Slager s)). Alleen gaat het volgende niet goed:

code:

abstract class Persoon{
     void accepts(PersoonVisitor v){v.accepts(this);}
}

class Slager extends Persoon{}

Nu zal altijd visit(Persoon) worden aangeroepen.

*zit nu ook ff te twijfelen*

[ Voor 4% gewijzigd door Alarmnummer op 19-03-2003 12:55 ]

[Glimi]

Alarmnummer schreef op 19 maart 2003 @ 12:54:
Nu zal altijd visit(Persoon) worden aangeroepen.

*zit nu ook ff te twijfelen*

Waaraan twijfel je dan? Want wat je zegt klopt gewoon Als namelijk de door een abstracte class de accepts al gedfinieerd kan worden, en dan toch de juiste parameter wordt doorgegeven aan de visitor, dan was de visitor niet nodig

[Verwijderd]

Alarmnummer schreef op 19 March 2003 @ 12:35:
Ben ik helemaal met je eens. Gelukkig zal compiletime ook de meest strakke worden gekozen. Alleen runtime de meest wijde. Ik weet eerlijk gezegd de reden ook niet waarom dit is gedaan.

Een van de redenen om runtime altijd de meest generieke te nemen is complexiteit. Maar de belangrijkste reden is dat multiple dispatch een grote impact heeft op de snelheid van van een method call.

Dat er nog geen autoboxing in java zit kan ik begrijpen, het is een hel om dat efficient te implementeren zonder dat de bytecode het ondersteund.

[Alarmnummer]

Verwijderd schreef op 19 maart 2003 @ 13:02:
[...]

Een van de redenen om runtime altijd de meest generieke te nemen is complexiteit. Maar de belangrijkste reden is dat multiple dispatch een grote impact heeft op de snelheid van van een method call.

Dat vind ik idd een zeer goed argument. Daar had ik zelf nog niet eens aan gedacht *heeft hekel aan snelheid*

Dat er nog geen autoboxing in java zit kan ik begrijpen, het is een hel om dat efficient te implementeren zonder dat de bytecode het ondersteund.

Ik weet niet of er voor 1.5 (tiger) wel een verandering aan de bytecode komt hiervoor. Het is iets dat in principe gewoon compiletime opgelost kan worden.

[Alarmnummer]

Glimi schreef op 19 March 2003 @ 12:58:

[...]

Waaraan twijfel je dan? Want wat je zegt klopt gewoon Als namelijk de door een abstracte class de accepts al gedfinieerd kan worden, en dan toch de juiste parameter wordt doorgegeven aan de visitor, dan was de visitor niet nodig

Dat bij Slager bij het 1e voorbeeld wel visit(Slager s) wordt aangeroepen. Wat ik zeg klopt wel, maar ik heb wel eens ruzie gehad met mijn visitor hierom. Dat is een van de redenen dat ik de default visit (die ik alleen declareer bij een VisitorAdapter) een andere naam geef. De andere reden dat ik hem een andere naam geef is dat ik dan niet hoef te downcasten.

Nog een goeie reden om de visit(Persoon) methode niet aan je visitor toe te voegen is, dat je dan per ongeluk visit methodes zou kunnen vergeten te declareren. Tenslotte kan desnoods die visit(Persoon p) worden aangeroepen als er niets beters is te vinden.

[ Voor 17% gewijzigd door Alarmnummer op 19-03-2003 13:14 ]

[.oisyn]

hmmm, raar, het ging toen over deze topic van ACM: [rml][ java] Generieke html-forms en sql-code dmv Visitors[/rml]

dit is mijn icq history:

.oisyn 17-1-200 1:31 vanwaar dan deze vraag:

"is hier een generieke oplossing voor bedacht
waarbij er wel een default-methode op te geven *
is zonder dat er aanpassingen in de
Visitable-Objecten nodig zijn?"

ACM 17-1-200 1:31 nou...

als ik
Visit(Blaat b)
Visit(SubBlaat b)

doe, zal de tweede nooit gebruikt worden...
en DAT wil ik juist wel, maar als er ook een
SubBlaat2 is dan moet die weer door de eerste
afgehandeld worden

.oisyn 17-1-200 1:33 waarom zou de 2e nooit aangeroepen worden?

ACM 17-1-200 1:33 omdat Java de meest generieke variant van de
methode pakt...

dus voor SubBlaat pakt ie de Blaat variant

.oisyn 17-1-200 1:34 niet als er ook een methode voor Blaat is

ACM 17-1-200 1:34 das trouwens een bekend probleem met Visitors
geloof ik, wil wel es weten of er een oplossing
voor is

.oisyn 17-1-200 1:34 of ben ik nu gek

ACM 17-1-200 1:35 euh... overnieuw:
Blaat is een superclass van SubBlaat en SubBlaat2
// default
Visit(Blaat)
// specialisatie, dus NIET de default uitvoeren
voor deze
Visit(SubBlaat)
// de specialisatie wordt nooit gebruikt

.oisyn 17-1-200 1:35 lijkt me best lomp als dat zo is

een visit (SubBlaat) matcht toch veel beter dan
een visit (Blaat) als het een SubBlaat betreft

dus het lijkt me dat dan visit (SubBlaat) ook
aangeroepen wordt

ACM 17-1-200 1:35 denk dat je het niet helemaal snapt

ACM 17-1-200 1:35 ja, dat WIL ik, maar dat doet java niet...

.oisyn 17-1-200 1:35 dat, of jou uitleg zuigt

.oisyn 17-1-200 1:35 niet?

ACM 17-1-200 1:35 nope

test maar

.oisyn 17-1-200 1:35 oh ok

ja in C++ is dat wel zo, maar van java weet ik
het dus niet zeker

.oisyn 17-1-200 1:36 ok


.oisyn 17-1-200 1:36 hmm kut, jdk niet geinstalleerd

ACM 17-1-200 1:37 haha, ik zal het es met een simpel voorbeeld
testen

.oisyn 17-1-200 1:40 maar je kan idd wel eens gelijk hebben, volgens
mij ben ik hier eerder al eens over gevallen

in een topic van alarmnummer of mbravenboer ofzo


ACM 17-1-200 1:44 ::::::::::::::
Caller.java
::::::::::::::
class Caller
{
Caller(Test test)
{
System.out.println("Called with
test");
}

Caller(SubTest s)
{
System.out.println("Called with
subtest");
}

public static void main(String[] argv)
{
Test test = new Test();
new Caller(test);
SubTest s = new SubTest();
new Caller(s);
Test t = new SubTest();
new Caller(t);
}
}
::::::::::::::
SubTest.java
::::::::::::::
class SubTest extends Test
{
}
::::::::::::::
Test.java
::::::::::::::
class Test
{
Test()
{
new Caller(this);
}
}

heeft als output:
Called with test
Called with test
Called with test
Called with subtest
Called with test
Called with test

kortom... ipv 4x de Called with subtest alleen
maar in de expliciete variant...

ACM 17-1-200 1:44 en laat dat nou net niet kunnen als je Visitors
enzo gebruikt

.oisyn 17-1-200 1:46 hmm, vervelend

ACM 17-1-200 1:46 yups, dat doet c++ wel goed?

.oisyn 17-1-200 1:46 ja


ACM 17-1-200 1:46 wow

een pluspunt voor c++

.oisyn 17-1-200 1:47 idd ^_^

uit deze discussie maak ik op dat het ook niet at compile time goed ging... maar goed, bij dat code voorbeeld dat ie gaf klopt het idd wel. Maar goed, ik zal het wel weer compleet verkeerd begrepen hebben

[Alarmnummer]

Volgens mij is er in dat opzicht geen verschil tussen c++ en java. Java zal compiletime ook de meest strakke versie kiezen van een methode.

void foo(String){}

void foo(Object o){}

String s = "";
foo(s) => foo(String s).

[Glimi]

Alarmnummer schreef op 19 maart 2003 @ 13:35:
Volgens mij is er in dat opzicht geen verschil tussen c++ en java. Java zal compiletime ook de meest strakke versie kiezen van een methode.

Klopt Volgens mij was de visitor code van het GoF boek ook in C++ geschreven

[.oisyn]

idd, daar ben ik nu ook achter
destijds dacht ik dus gewoon dat dat in java anders was (en dat vond ik ook al zo raar), en begreep ik ACM gewoon verkeerd. En ik kon toen niet zelf testen omdat ik de jdk niet had geinstalleerd

maar goed, dan heb ik dus niets gezegd

[ Voor 9% gewijzigd door .oisyn op 19-03-2003 13:37 ]

[Alarmnummer]

Glimi schreef op 19 March 2003 @ 13:37:

[...]

Klopt Volgens mij was de visitor code van het GoF boek ook in C++ geschreven

Bij het GoF voorbeeld zal het probleem zich ook niet voordoen, omdat ze dus iedere visitmethode een andere naam geven.

C++:

    class Visitor {
    public:
        virtual void VisitElementA(ElementA*);
        virtual void VisitElementB(ElementB*);
    
        // and so on for other concrete elements
    protected:
        Visitor();
    };

    class Element {
    public:
        virtual ~Element();
        virtual void Accept(Visitor&) = 0;
    protected:
        Element();
    };
    
    class ElementA : public Element {
    public:
        ElementA();
        virtual void Accept(Visitor& v) { v.VisitElementA(this); }
    };
    
    class ElementB : public Element {
    public:
        ElementB();
        virtual void Accept(Visitor& v) { v.VisitElementB(this); }
    };

[ Voor 3% gewijzigd door Alarmnummer op 19-03-2003 13:44 ]

[hobbit_be]

het is nou net door die rotte downcasting van Java dat ik een eigen reflectie wrapper heb moeten bouwen omdat ie zoals vermeld het gewoon vertikt effe deftig te introspecten... Had hele rotte bugs zodra ik met interfaces begin (iets wat normaal toch wel aan te raden is).

stel:

Java:

interface ICoolDude {}
class CoolDude implements ICoolDude{}
class CoolerDude extends CoolDude{}

wat blijkt nou:

dat als ik een invoke doe op een functie

Java:

void setMyCoolDude(ICoolDude aCoolDude)
{}

void callSomeDude(Object aCoolDude)
{
   getMethod("setMyCoolDude",aCoolDude.getClass());
}

callSomeDude(new CoolerDude());

dat laatste lukt dus niet - hij vind namelijk geen functie met definitie:

: setMyCoolDude(CoolerDude aObject)

hij beseft dus niet dat CoolerDude wel degelijk een ICoolDude is, en dit
omdat ie genest is terwijl als je effe logisch nadenkt een interface op alle
levels zou moeten tellen. Ik heb het zelf moeten oplossen door de tree
af te lopen , alle classes+interfaces zelf te halen en te matchen...

om het snel te houden cache ik dan de gevonden method dus de penalty is
dan weer niets (quasi niets). (het leuke is dat je die globaal kunt cachen aangezien het toch alleen op classe niveau werkt)

Goed voor snelheid maar als reflectie niet werkt zoals de taal dan slaan ze toch weer de mist in... (vind ik)...

[.oisyn]

Maar in C++ kan het nog veel mooier (en bovendien vrijwel automatisch)

C++:

// dispatcher definitie
struct base_dispatcher
{
    template <class T, class F> static void dispatch (T & t, F & f)
    {
        f (t);
    }
};

template <class S, class N = base_dispatcher>
struct dispatcher
{
    template <class T, class F> static void dispatch (T & t, F & f)
    {
        S * s = dynamic_cast<S *> (&t);
        if (s)
            f (*s);
        else
            N::dispatch (t, f);
    }
};

#define DISPATCHER_TYPE_2(a,b)        dispatcher<a, dispatcher<b> >
#define DISPATCHER_TYPE_3(a,b,c)        dispatcher<a, DISPATCHER_TYPE_2 (b, c) >
#define DISPATCHER_TYPE_4(a,b,c,d)    dispatcher<a, DISPATCHER_TYPE_3 (b, c, d) >
#define DISPATCHER_TYPE_5(a,b,c,d,e)    dispatcher<a, DISPATCHER_TYPE_4 (b, c, d, e) >


// implementatie van een Base klasse en 3 Derived klassen
struct Base
{
    virtual ~Base () { }
};

struct D1 : public Base { };
struct D2 : public Base { };
struct D3 : public Base { };

typedef DISPATCHER_TYPE_3(D1, D2, D3) Base_dispatcher;



struct Receiver
{
    operator () (Base &)
    {
        cout << "Base" << endl;
    }

    operator () (D1 &)
    {
        cout << "D1" << endl;
    }
    
    operator () (D2 &)
    {
        cout << "D2" << endl;
    }
    
    operator () (D3 &)
    {
        cout << "D3" << endl;
    }
};


int main ()
{
    Receiver r;
    Base *array[] = { new Base, new D1, new D2, new D3 };

    for (int i = 0; i < 4; i++)
        Base_dispatcher::dispatch (*array[i], r);
}

heeft wel wat haken en ogen, namelijk dat als bijvoorbeeld D3 weer wat subclasses heeft, dat je die dan voor D3 zelf moet zetten, aangezien anders alleen de D3 methode wordt aangeroepen, en niet die methoden die een subclass van D3 accepteren. Is wel weer op te lossen door bijvoorbeeld een speciale dispatcher te bouwen die eerst kijkt of het een D3 is, en dan alle subclasses van D3 afgaat... zoiets zeg maar:

C++:

template <class B, class S, class N = base_dispatcher>
struct sub_dispatcher
{
    template <class T, class F> static void dispatch (T & t, F & f)
    {
        if (dynamic_cast<B *> (&t))
            S::dispatch (t, f);
        else
            N::dispatch (t, f);
    }
};
#define SUB_DISP_TYPE_2(base,a,b)       sub_dispatcher<base, DISPATCHER_TYPE_2 (a, b) >
#define SUB_DISP_TYPE_3(base,a,b,c)   sub_dispatcher<base, DISPATCHER_TYPE_3 (a, b, c) >
#define SUB_DISP_TYPE_4(base,a,b,c,e)   sub_dispatcher<base, DISPATCHER_TYPE_4 (a, b, c, d) >
#define SUB_DISP_TYPE_4(base,a,b,c,e,f)  sub_dispatcher<base, DISPATCHER_TYPE_4 (a, b, c, d, f) >


// en Base_dispatcher wordt dan:
DISPATCHER_TYPE_3 (D1, D2, SUB_DISP_TYPE_2 (D3, D3_1, D3_2) )

[ Voor 32% gewijzigd door .oisyn op 19-03-2003 14:23 ]

[Alarmnummer]

Waar is setMyCoolDude gedeclareerd?

[ Voor 18% gewijzigd door Alarmnummer op 19-03-2003 14:11 ]

[hobbit_be]

Alarmnummer schreef op 19 maart 2003 @ 14:11:
Waar is setMyCoolDude gedeclareerd?

oh gewoon in een of ander object waardat later die getmethod moet worden uitgevoerd:

Java:

public class ooCoolFamily
{
    void setCoolDad(ICoolDude aDude);
    void setCoolMum(ICoolDude aDudesse);
}

ooCoolFamily tFamily  = new ooCoolFamily();

//somewhere in the code (tFamily will most likely be somewhere in Collection

foreach(ooCoolFamily fam in ooAllCoolFamilies) //:)
{
     fam.invoke("setCoolDad", new CoolerDude()); //of course nonsens maar je begrijpt wel wat in de plaats moet komen.  
}

needless to say dat code is nonsens het gaat em enkel dat ie niet werkt met reflectie...