[java] #define

[Verwijderd]

<help>Is het mogelijk om in java net als in c #define te gebruiken, zo ja hoe?
Ik gebruik textpad als editor, deze licht bekende syntaxen op in blauw bijvoorbeeld import public KeyListener, define ook dus ik denk dit moet wel kunnen ik krijg echter de melding: illegal character: \35 op het #. </help>

[Glimi]

Define? Je bedoelt een constant declaren oid?
Wat moet het doen?

[Tuinhark]

Ik heb wel eens een tooltje gezien dat als een precompiler werkte en #define's omzette naar actuele waarden... Maar het is geen standaard Java nee.

[Verwijderd]

het is de bedoeling om bijvoorbeeld de System.out.println("lange zin") om te zetten naar out("korterder") dan is de bedoeling

[Glimi]

Dat komt de leesbaarheid niet tengoede he IMHO.

In dit geval kun je het oplossen door System.out z'n outputstream te pakken en die in een variabele gebruiken. Echter het absolute voordeel zie ik niet echt van zo'n #define

[Alarmnummer]

define is er niet zonder reden uitgelaten. Je moet gewoon System.out.... schrijven..

[drm]

hofstee:
het is de bedoeling om bijvoorbeeld de System.out.println("lange zin") om te zetten naar out("korterder") dan is de bedoeling

Dus je bent gewoon lui?
Je moet idd gewoon System.out gebruiken, want als je dat soort dingen toe gaat laten in je eigen code begrijp je het op een gegeven moment zelf niet meer. Een van de voordelen van Java is juist dat dit soort dingen netjes gecode moeten worden. Zo hou je altijd goed het overzicht over de OO-structuur, en weet je ook altijd waar je naar moet zoeken als je je code nog eens reviewt.

En wat misschien nog wel belangrijker is, andere programmeurs hoeven niet eerst de kam door de code te halen om het te kunnen lezen.

* drm is ook geen fan van C(++) macro's

_edit:

Alarmnummer:
define is er niet zonder reden uitgelaten. Je moet gewoon System.out.... schrijven..

* drm hoopte dat jij dat ging vertellen, wat die reden dan was?

[Alarmnummer]

Op dinsdag 28 mei 2002 18:49 schreef drm het volgende:
* drm is ook geen fan van C(++) macro's

_edit:
[..]

* drm hoopte dat jij dat ging vertellen, wat die reden dan was?

Voornamelijk tegenstrijdige define`s.

[drm]

Alarmnummer:
Voornamelijk tegenstrijdige define`s.

Semantisch, bedoel je?

[Alarmnummer]

het is al weer een hele tijd geleden dat ik iets met c heb gedaan, en de define syntax die ken ik niet meer uit mijn hoofd. Maar je kan in verschillende source files dezelfde define maken, bv TRUE = 1, FALSE = 0 .. en verderop maak je een TRUE = 0 en FALSE =1. En helemaal niemand die erom klaagt.

[ACM]

Als je echt graag out(); wilt schrijven, maak dan een functie hetzelfde doet

[drm]

Alarmnummer:
het is al weer een hele tijd geleden dat ik iets met c heb gedaan, en de define syntax die ken ik niet meer uit mijn hoofd. Maar je kan in verschillende source files dezelfde define maken, bv TRUE = 1, FALSE = 0 .. en verderop maak je een TRUE = 0 en FALSE =1. En helemaal niemand die erom klaagt.

Voor C geldt dat wel, ja, dat klopt.

Maar dat is nog geen reden dat het bij Java niet geimplementeerd is. Het is dan namelijk gewoon de taak van de precompiler om bij te houden of een bepaalde define al bestaat of niet. Dat lijkt me nou niet zo ingewikkeld

_edit:

ACM:
Als je echt graag out(); wilt schrijven, maak dan een functie hetzelfde doet

Dan zou ik zo'n functie schrijven, maar 'm dan abstract maken, en een interface "Outputtable" maken, om die vervolgens te implementeren. Dat zou imo dan nog de netste oplossing zijn. (op het gebruik van System.out na, natuurlijk)

[Alarmnummer]

Als ik eerlijk ben is dit het enigste wat me bijstaat, maar er zijn wel een goeie redenen dat define`s zijn weggelaten uit Java. Ik kan je helaas niet verder meer helpen

[farlane]

Macros zijn o.a. evil omdat ze onverwachte bijwerkingen kunnen hebben en omdat geen typechecking wordt gedaan op de argumenten.

Ze zijn wel handig als je conditioneel wilt compileren, of bugs wilt omzeilen in MS compilers.

[Alarmnummer]

Op dinsdag 28 mei 2002 20:00 schreef farlane het volgende:
Macros zijn o.a. evil omdat ze onverwachte bijwerkingen kunnen hebben en omdat geen typechecking wordt gedaan op de argumenten.

Ze zijn wel handig als je conditioneel wilt compileren, of bugs wilt omzeilen in MS compilers.

Ik gebruikt dit wel eens om conditioneel te compileren. Maarja. niet zo krachtig als een define.

code:

public class Blaat{
   final public static DEBUG = true;

   public void mekker(){
    if(DEBUG){
        controleerMekker();
    }
    ...mekkerfuncties(); 
   }
}

Omdat de conditie of wel of niet houdt (afhankelijk van de DEBUG waarde) word compile time de controleerMekker er wel of niet ingezet.

[serkoon]

Voor #define IETS 15 wil ik nog wel eens een private final static int IETS 15; doen, maar da's misschien wel tegen de regels

[farlane]

Op dinsdag 28 mei 2002 20:05 gaf Alarmnummer een voorbeeld

Dat is een manier, maar een nadeel daarvan is dat er extra instructies moeten worden uitgevoerd, ook als je DEBUG uit hebt staan. Dit is niet het geval als je van macro's gebruikt maakt.

Overigens was er sinds JDK 1.4 ook een Assert(...) sinds JDK1.4. Volgens mij is dat ook wel iets voor je.

[drm]

Alarmnummer:
Ik gebruikt dit wel eens om conditioneel te compileren.

code:

[snip]

... wordt compile time de controleerMekker er wel of niet ingezet.

Wordt dit compile-time geoptimaliseerd? Dat is wel netjes

farlane:
een nadeel daarvan is dat er extra instructies moeten worden uitgevoerd als DEBUG uitstaat

Als dat dus compile-time wordt geoptimaliseert is dat dus niet het geval...


_edit:
gek genoeg staat-ie hier niet bij
http://developer.java.sun.com/developer/Books/shiftintojava/page1.html
je kan je dan natuurlijk afvragen of het wel een C construct is, maar goed...

[Alarmnummer]

Op dinsdag 28 mei 2002 20:14 schreef farlane het volgende:

[..]

Dat is een manier, maar een nadeel daarvan is dat er extra instructies moeten worden uitgevoerd, ook als je DEBUG uit hebt staan. Dit is niet het geval als je van macro's gebruikt maakt.

Wordt eruit gecompileerd, dus heb je geen last van.

Overigens was er sinds JDK 1.4 ook een Assert(...) sinds JDK1.4. Volgens mij is dat ook wel iets voor je.

ik neem aan dat je bedoelt assert ipv Assert.

code:

private void setLeeftijd(int leeftijd){
   assert leeftijd>=0:"leeftijd can`t be smaller than 0, leeftijd="+leeftijd;
   _leeftijd = leeftijd;
}

Het voordeel aan assert is dat als je het hebt uitstaan, dat hij de commando`s negeerd en het kost je geen tijd. Helaas mag je assert niet overal gebruiken. Oa niet bij publieke en protected methodes.

Ik gebruik zelf de Assert class van JUnit, en dat werkt erg fijn.

code:

public void setLeeftijd(int leeftijd){
   Assert.assertTrue("leeftijd moet ...",leeftijd>=0);
   _leeftijd = leeftijd;
}

Dit is een stuk beter te lezen dan een if constructie + je kan nu duidelijker zien wat je pre condities zijn ipv 'echte' code.

[Bobco]

Op dinsdag 28 mei 2002 15:07 schreef hofstee het volgende:
het is de bedoeling om bijvoorbeeld de System.out.println("lange zin") om te zetten naar out("korterder") dan is de bedoeling

Tja, het is maar wat je wilt. Een editor met een goede expansie mogelijkheid kan je hier natuurlijk ook bij helpen. In Jext tik je hiervoor bijvoorbeeld sout[Esc] en opeens staat er System.out.println() op het scherm

Naar mijn idee komt het de leesbaarheid van programma's niet ten goede als alles maar zo kort mogelijk wordt opgeschreven. Korte statements zijn leuk, maar leesbaarheid is nog veel leuker, zeker een paar maanden later.