Discussions

EJB design: Clean design solution for NULLs with Java primitives

  1. Hi everyone,

    In almost every project I struggle with the primitive types and possibility to have "empty" value (aka NULL value)

    This problem shows when I do mapping to relational database.

    So, I populate my Java bean with the values from DB record and then my application code looks like this:

    MyBean bean = new MyBean();
    //...POPULATE from ResultSet

    perform app specific logic:

    if (bean.getPersonName() != null)
    {
      // do something...
    }
    else
    {
      // handle null value
    }


    if (bean.getPersonAge() > 0)
    {
      // do something...
    }
    else
    {
      // handle null value
    }
    ---------
    In other words, I do not see how practically use primitive types (or its object couterparts) effectively and conveniently for the development with DBs...

    In opposite collections can have empty value and have check method “isEmpty()” and “clear()”, which is quite convenient, since it can hold both NO VALUE and VALUE(s)

    Any thoughts & ideas?

    Threaded Messages (45)

  2. Don't use primitives. Use the corresponding java class. java.lang.Long, java.lang.String. That way you can use a java null reference to communicate a database null.

    Testing a database value for null is an unfortunate necessity in most cases, however, for your person_name, you might consider making this a non-null field and allowing a null string. Also, make person_age a non-null field and therefore you can assume that it will always be popluated. You don't really need to make it not null on the database, but you can ensure programatically that the field will always be populated.

    If you want null for these fields to mean something like "I don't know these values" then the null test is a necessity.
  3. Hi Kris,

    Thank you for sharing/suggesting your opinion.

    I was thinking about it (not to allow usage of Java primitives)...

    But then their object counterparts (java.lang.Integer and so on) are quite clumzy. They do not have unified access method like "getValue()". Instead each has some ugly type specific way to get value (e.g. "intValue()")

    So, this kind of things turns me off from using them.

    I'm thinking to define a small guideline for developers on how to use/write their Java beans - that DAL (Data Access Layer) classes will use for DB (in/out) data traffic.

    So, my example with person_name was an application specific attribute. What I'm trying to say is that on this generic level it is not possible to dictate to developers to not use primitive types, or suggest to use immutable primitive wrappers like java.lang.Integer.

    May be instead, it would be a good idea to develop my own primitive value holder classes (mutable) that han also hold "EMPTY value"?

    Something like this:

    class MyInteger
    {
      private int value;
      private boolean noValue = true;

      public int getValue() { return value; }
      public void setValue(int newValue) { value=newValue; setNull(); }
      public boolean isNull() { return noValue; }
      public void setNull() { noValue=true; }

    }

    What do you think?
  4. Very noisy. You'll end up duplicating Java standard classes.
    On the other hand, allowing null values or not is a matter of semantics.
    If you need to expose attributes as primitives and still handle nulls, what about this?

    public class MyValue
    {
        Integer value;

        public int getValue()
        {
            return (value != null) ? value.intValue() : 0;
        }

        public void setValue(int pValue)
        {
            value = new Integer(pValue);
        }
    }

    This way, you can have a null value in the DB but the users of MyValue will never know... but perhaps returning 0 when value is null is not correct. There's no general approach to solve this, and it's fine by me.

    Regards,
    Martin
  5. ... but perhaps returning 0 when value is null is not correct. There's no general approach to solve this...

    Exactly, that is the problem. Primitive type holders do not have EMPTY value indicator.

    For example Collections do have. there is a flag method "isEmpty()", so my code never changes. If I have iteration over collection it stays always the same even if collection has no values (e.g. collection of size 0)

    In contrary it is not possible to do with primitive types and their counterpart in java.util
  6. Primitives will never be nullable, nor should they be.
    the question is whether java should have lighter
    weight Numerical classes that overload the arithmetic
    operators.

    Typically i avoid primitives as they dont tend to fit my code very well and classes aren't that much more expensive
    in most instances.

    either you could write said lightweight classes.
    which should be immutable, non-serializable non-clonnable.
    and which support arithmetic functions.

    not recommended unless you only allow arithmetic on the
    same class types.

    otherwise I would suggest instead of creating your own wrapper classes that you just put the mechanisms in your transport objects so they identify nulled fields.

    for instance

    class myto

     int field1 = 0;
     boolean field1null = true;

    public int getField1(){
      return field1;
    }

    public boolean field1IsNull(){
      return field1null;
    }

    public void setField1(){
      this.field1null = true;
      this.field1 = 0;
    // what happens when you do arithmetic on nulls?
    }

    public void setField1(int value){
      this.field1 = value;
      this.field1null = false;
    }

      .... repeat for all nullable fields.

    }

    then your extenal code is

    if (to.field1IsNull()){
    do...
    }else{
    do...
    }

    the only real difference between doing the code this way
    and having primitives that are nullable is that

    String.valueOf(to.getField1()) would return "null".
  7. That would work if you want to go to that length. In general this violates my laziness directive among other alerts going off in my head...

    One problem with creating your own wrapper for primitives is complexity. This may seem like a simple task, but you better REALLY know what you are doing to truly make it usefull... Implement Serializabe, Clonable, etc. Create clone, toString, compare, equals, etc.

    Second, most Java developers are already aware of the API for the java.lang wrapper classes. There would be a learning curve (hopefully small) for these new primitives.

    I think you'll find that there are other ways to treat these existing wrappers generically where you need to, and once you use them a bit you'll be able to get past the awkwardness of their API.

    I've been writing a tool that uses this approach to deal with database interaction. A JSP style code page is used to autogenerate the Value Object and DAO classes that directly corrolate to a table's definition. If your interested, look for it at http://www.krishuggins.com early next year.

    From my experiences with this, I'm happy with using the primitive wrappers and once you get the Java 1.5, Autoboxing (and auto-unboxing? if it does do that) will make this awkwardness disappear.
  8. I've been writing a tool that uses this approach to deal with database interaction. A JSP style code page is used to autogenerate the Value Object and DAO classes that directly corrolate to a table's definition.

    Interesting. How then in your implementation are you dealing with null value and primitives?

    For example, if your Value Object has primitive type "int", e.g. public int getAge() and DB allows to have NULLs for this field?

    How do you indicate to the user of your VO that sometimes "getAge()" has no value?
  9. It will not use primitives. It will use the wrappers. getCustId() will return a Long. If the object reference is null then the database column is null. Otherwise, the value of the column will be wrapped in the Long object instance.

    My idea here is to give the Value object and the DAO object code to you for free. The object will correlate directly to the table definition.
  10. Here is a sample of the auto-generated VO based on this table def. The cool thing is the is generated from a JSP style template which can be modified to your liking.

    order
    ------------------------
    order_id NUMBER
    cust_id NUMBER
    card_num VARCHAR2[32]

    package org.fadung.mydomain;

    public class Order {
        public Order() {
        }

        private Long orderId;
        private Long custId;
        private String cardNum;
        
        public Long getOrderId() {
            return orderId;
        }
        public void setOrderId(Long orderId) {
            this.orderId = orderId;
        }

        public Long getCustId() {
            return custId;
        }
        public void setCustId(Long custId) {
            this.custId = custId;
        }

        public String getCardNum() {
            return cardNum;
        }
        public void setCardNum(String cardNum) {
            this.cardNum = cardNum;
        }
    }
  11. It will not use primitives. It will use the wrappers.

    Yes. In your case, since you have control over how your VOs are generated, this could be a solution for NULLs.

    But unfortunately in my case, it is a developer that has to write its own VO class or BO (business object).

    And I don't want to limit them with primitive type wrappers ONLY because of NULLs...

    In fact, primitive types were introduced in Java for a reason - very convenient to use in calculations and performance wise they are most optimal.

    I'm just afraid that developers would end up writing their "primitive type VO wrappers" on top of "official" VOs...
  12. NULL handling with Java primitives[ Go to top ]

    May be I will try to clearly describe this generic problem...

    I'm looking for clean solution on how to handle NULL values for primitive types.

    Consider this example:

    public class Person
    {
      private boolean smoker;
      private String name;
      private int age;
      // getters and setters…
    }

    Now lets say in the data store I can have (for sake of this example) "smoker", "name" and "age" fields as NULLABLE.

    Then somehow DAO can map DB storage with Person class.

    Now the question is: How application developers can test fields of Person class if "smoker", "name" and "age" are NULL or not?
    Is there any common development pattern or clean solution exists?
  13. NULL handling with Java primitives[ Go to top ]

    There is ABSOLUTELY NO WAY to test if a primitive is null... because they CAN'T be null. I guess you already know that. ;)
    Considering you are kind of in a rush with this, since you seem to crave for a quick answer, I'll make this easy for you: there is no common approach, or pattern, or usual solution, because it all depends on the SEMANTICS related to each attribute. You are approaching the problem from a data-centric view ("my table can have null values, how do i represent that in Java?") when you should analyze it differently: "this class can have a null attribute; how can I persist it (in a database, a file or whatever)".
    If your application is indeed data centric and not object oriented, then why do you worry about this? Use primitives' wrappers and be happy.
    The rest of the post was getting interesting, though. I'd very much like to continue this discussion.


    Regards,
    Martin
  14. NULL handling with Java primitives[ Go to top ]

    There is ABSOLUTELY NO WAY to test if a primitive is null... because they CAN'T be null. I guess you already know that.

    Yes I know this shortcoming. I think this is related to the fact that primitive types are projecting underlying hardware architecture. Therefore, since modern CPUs cannot have such datatype (e.g. it is too low level data types they handle), the Java primitives inherit this as well.
    there is no common approach, or pattern, or usual solution, because it all depends on the SEMANTICS related to each attribute...

    That what I'm trying to establish - if there absolutely no solution(pattern) for this... kind of hard to believe after so many years of Java being a popular programming language...
     You are approaching the problem from a data-centric view ("my table can have null values, how do i represent that in Java?") when you should analyze it differently: "this class can have a null attribute; how can I persist it (in a database, a file or whatever)"

    I thing the problem exists regardless of the approach. Even if it has nothing to do with DB persistence...

    For example, if I want to pass a "transfer object" from one layer to another in my application. I want to keep these layers loosely coupled.

    So, I would end up with defining a "contract" AKA Java interface that will specify my public attributes of the transfer object.
    .If your application is indeed data centric and not object oriented, then why do you worry about this? Use primitives' wrappers and be happy.

    Imagine that I have hundreds developers at my disposal and I will tell them:
    Ok guys, here is the pattern we have to use in order to handle NULL values for the attributes - primitive Java types are not allowed in transfer objects...
    It does not sound right to me...since the developers will be forced later to convert all these “java.util.*” wrappers into primitives to use in their calculations...very intrusive.
  15. NULL handling with Java primitives[ Go to top ]

    Imagine that I have hundreds developers at my disposal and I will tell them:Ok guys, here is the pattern we have to use in order to handle NULL values for the attributes - primitive Java types are not allowed in transfer objects...

    That's no pattern at all.
    It all comes down to the very basics: we have this problem because we have primitives, period. Thus, it doesn't matter how many years Java's been around. Still, I believe there's no need to define a "pattern" like the one I quoted from your post. Call it a rule, a standard or whatever, but not a pattern. Like you said, it would be extremely intrusive and would not follow the principles of patterns.
    Everywhere you see an object reference in Java, you must assume it's not null (based on a contract, most likely) or verify it yourself - "if (code != null) this.blah()".
    I really don't see the point of forcing a pattern-like solution into this.

    Regards,
    Martin
  16. NULL handling with Java primitives[ Go to top ]

    Like you said, it would be extremely intrusive and would not follow the principles of patterns.Everywhere you see an object reference in Java, you must assume it's not null (based on a contract, most likely) or verify it yourself - "if (code != null) this.blah()".I really don't see the point of forcing a pattern-like solution into this.

    Thanks Martin for your thoughts. Yeah may be I should not call it "pattern" but "rule".

    In anyway, if I formulate this rule like this:

    "Use in your Java bean primitive types ONLY if they cannot be NULLABLE, otherwise use primitive type Object wrappers."

    This could work for some projects, but later when the project is deployed to different location (or new requirements) it could be that some of the NON-NULLABLE attributes will become NULLABLE (and visa versa)

    That where the problem will start...developers will need to re-code their Java bean and all the application code that deals with it...since they will need to replace primitive type with its Object wrapper...

    Quite taxing...the impact on the application code is quite huge.

    I wonder if it was ever some attempt to introduce into Java some kind of "emptyable" primitive type?

    So, my code would look like this:

    {
      int myVar = EMPTY;

      //...
      if (myVar valueof EMPTY)
      {
        // invoke logic for undefined var
      }
      else
      {
        // do smthg....
      }
    }
  17. NULL handling with Java primitives[ Go to top ]

    IMO There are are 2 solutions to your problem.

    1. Tell your developers to not use primitives for these types of objects. Using the wrappers is not that intrusive and if something can be null you need to test that no matter which way you represent null.

    2. Convert to C# (2.0 I think) where you can have null primitives using something like "int ?myint;" syntax.
  18. NULL handling with Java primitives[ Go to top ]

    IMO There are are 2 solutions to your problem.1. Tell your developers to not use primitives for these types of objects. Using the wrappers is not that intrusive and if something can be null you need to test that no matter which way you represent null.
    I guess you are right... that is the only least evil solution out of over ones...

    Still it is not quite clean. Every time I need to include my primitive wrappers into calculations I need "unwrap" my primitive types.

    Something like this:

    if (myBean.getAge() != null)
    {
      int age = myBean.getAge().intValue();

      // do calculations...
      long totalIndex = age*someConst/365+peopleCount/age%20;
    }

    of even worse: long totalIndex = myBean.getAge().intValue()*someConst/365+peopleCount/myBean.getAge().intValue()%20;

    Quite ugly looking code... but well I must admit nothing else is provided in Java for such things...too bad :(
    2. Convert to C# (2.0 I think) where you can have null primitives using something like "int ?myint;" syntax.
    Well, that would be a good idea if I had no ties with Java...but we have tons of projects written in Java.
    I must admit C# looks superior in this regard.

    I just amazed that JDK1.5 adding new features like auto-boxing because it is trying to catch-up with its counterpart C# (and horrible static imports), but at the same time still missing solution such fundamental as nullable primitives...
    Really bizarre...
  19. NULL handling with Java primitives[ Go to top ]

    Writing calculations like that once shouldn't be a huge deal. it is Ugly, true.

    One thing to consider if you are going to be reusing a calculation is to abstract it into its own class, or at least have a class that abstracts a bunch of related functions.

    The functions on the class can implement these calculations, so these calcualtion functions will be ugly internally to those classes, but the business logic that calls these wont looks so horrible. These functions can be overridden to take both primitives and wrappers (unless you need to pass null then pass the wrapper).

    int totalIndex = IndexCalculator.getTotalIndex(myBean.getAge(), peopleCount);

    You can even hide the constant and the percentage in the function or expose those in more overloaded functions.
  20. NULL handling with Java primitives[ Go to top ]

    Minor Correction: For clarity I would prefer to call the function calcTotalIndex as opposed to getTotalIndex which I used in my last post.

    I felt this was worth noting.
  21. NULL handling with Java primitives[ Go to top ]

    Yes. That what I will have to resort to... :(

    But my point was that this is a "work around" of the problem that Java primitives have.

    I must conclude that there is NO CLEAN SOLUTION for Java primitives...

    They just simply do not fit into Object oriented language.
  22. NULL handling with Java primitives[ Go to top ]

    IF you consider primitives a problem...
  23. NULL handling with Java primitives[ Go to top ]

    IF you consider primitives a problem...
    Yes. In some cases the way Java primitives are implemented - represent a problem for application developers and as a results lots of extra "plumbing" has to be done in the application in order to overcome this limitation of primitives...

    But still in the end it looks ugly...

    I was hoping that might be someone did solve this somehow in elegant way...
  24. NULL handling with Java primitives[ Go to top ]

    This could work for some projects, but later when the project is deployed to different location (or new requirements) it could be that some of the NON-NULLABLE attributes will become NULLABLE (and visa versa)That where the problem will start...

    Ah! You're right about that...
    Still, I think "int i = EMPTY" makes no sense, given the naturo of primitive in Java; int are numbers in the integer realm, and EMPTY is no number; "infinite" is no number either.
    In order to implement something like that, we should change the semantics of primitive types... an old disussion in the Java world. ¿Primitives should be objects?
    Another choice is to change the semantics of primitives' wrappers, so that we could do this: "Integer i = 0; Integer j = i + 1". AutoUNboxing... ;)
    Kind of a compile-time shorthand that would translate the previous expression into this one:

    Integer i = new Integer(0); // this far, autoboxing
    int temp = i.intValue() + 1; // autounboxing :P
    Integer j = new Integer(temp); // autoboxing again

    Or is this already supported in JDK 1.5?

    Regards,
    Martin
  25. NULL handling with Java primitives[ Go to top ]

    Cheezus! I hate my spelling... :D
  26. NULL handling with Java primitives[ Go to top ]

    I'm not sure if "auto-boxing" and "unboxing" is a good thing in general.

    By using it you loose control over "what is going on"

    Introduction of "auto-boxing" in Java starts smell like a C++ operator overloading feature...
  27. NULL handling with Java primitives[ Go to top ]

    ...Introduction of "auto-boxing" in Java starts smell like a C++ operator overloading feature...

    Operator overloading is good when you need it.

    Autoboxing feels more like breaking strong typing ala VB which DOES stink.
  28. NULL handling with Java primitives[ Go to top ]

    Autoboxing feels more like breaking strong typing ala VB which DOES stink.

    Why do think so? You cannot assign a String to an int, you cannot assign an int to a String. That's pretty strong-typed to me. And we already had that kind of "shortcuts" in earlier Java versions.

    int i = 0;
    System.out.println("a" + i);

    is a shortcut to

    int i = 0;
    System.out.println((new String("a")).concat(String.valueOf(i)));

    I consider these features more a source preprocessing than compiler flexibility.
  29. NULL handling with Java primitives[ Go to top ]

    ...Introduction of "auto-boxing" in Java starts smell like a C++ operator overloading feature...
    Operator overloading is good when you need it.

    But unfortunately most of the time you don't... and this "feature" of the C++ just is too powerful for average programmer.

    Many projects are simply polluted by abusing this feature and become extremely hard to maintain (especially when original “author-genius” has departed)
  30. Thread gank /apol[ Go to top ]

    Why do think so? You cannot assign a String to an int, you cannot assign an int to a String. That's pretty strong-typed to me. And we already had that kind of "shortcuts" in earlier Java versions.

    int i = 0;
    System.out.println("a" + i);

    Feels like "breaking strong typing" = I know it is not the same, but it makes me think of "breaking strong typing".

    String s1 = "a";
    String s2 = "a";

    s1 == s2

    String s1 = new String("a");
    String s2 = new String("a");

    s1 != s2

    Thus "a" != new String("a");

    Incidently your example is also a perfect example of suns inconsistency when it comes to operator overloading.

    Letting "+" operator work on String is dodgy at best.

    Would've been much more sensible to have "+" work on Double, Long, Float, BigInt etc.
    But unfortunately most of the time you don't... and this "feature" of the C++ just is too powerful for average programmer.

    This is a bogus argument, whats the next thing deemed to powerfull for average programmer? regexp? threads?

    It's kinda sad that after Java been around for decades new algorithms for serious numbercrunching still being developed in C(++), when a certain class has well defined and consistent semantics for specific operators, denying overloading is just plain silly.
  31. Thread gank /apol[ Go to top ]

    Would've been much more sensible to have "+" work on Double, Long, Float, BigInt etc.

    Perhaps, if the semantics related to those classes was different. Remember there's no string primitive, and primitives' wrappers do not have cool mathematical operations...
    If we had more mathematical functions in numeric wrapper classes, we'd miss operator overloading a little less. And please note I said "a LITTLE less" before roaring... :D
    I mean, I certainly don't like to do this:

    float f = Math.abs((new Float(10.5)).floatValue());

    Instead, I should be able to do

    float f = (new Float(10.5)).abs();

    or, better still...

    Float f = (new Float(10.5)).abs();

    And NO: extending the hole class library is not an option.
    This thread took a very philosophical turn, by the way... ;)
    What about gathering these and other ideas from other threads and designing yet another OO language? Jeje... We could build it in an academic fashion, secretly hoping to conquer the world with it when every coffe-maker and wasing machine ran on it...

    Regards,
    Martin
  32. Thread gank /apol[ Go to top ]

    Not sure I agree with your fix. Math.abs(x) looks more like math notation to me than x.abs(). Even if your fix was a step in the right direction, it would be like a bandaid on papercut to a patient with a bullit wound.
  33. Thread gank /apol[ Go to top ]

    But unfortunately most of the time you don't... and this "feature" of the C++ just is too powerful for average programmer.
    This is a bogus argument, whats the next thing deemed to powerfull for average programmer? regexp? threads?It's kinda sad that after Java been around for decades new algorithms for serious numbercrunching still being developed in C(++), when a certain class has well defined and consistent semantics for specific operators, denying overloading is just plain silly.
    I understand that C++ is more "flexible" than Java in this regard...
    But, then I think it is a question of finding a right balance between the language expression flexibility and usability by a population of programmers...
    In some way it is like Assembler compared to C. You can do anything in it but readability is poor and there is a good chance that less systematic programmer can "hang" <him|her>self with its own code...

    I think C++ is quite limiting the "audience" of programmers who can effectively take advantage of all its features.

    On the other hand Java is more balanced language (with removed multi inheritance, memory allocation/de-allocation and so on...)

    But I'm not saying that Java is perfect. It missing lots of things (like this primitives problem (C# solved it), ability to make "friend" class like in C++, properties like in Delphi Object Pascal)

    So on the long run I foresee lots of room for improvement and I think it might actually result in creating a new language with even more clearer semantics to express logic…
  34. Thread gank /apol[ Go to top ]

    I understand that C++ is more "flexible" than Java in this regard...
    But, then I think it is a question of finding a right balance between the language expression flexibility and usability by a population of programmers...
    In some way it is like Assembler compared to C. You can do anything in it but readability is poor and there is a good chance that less systematic programmer can "hang" <him|her>self with its own code...

    I think C++ is quite limiting the "audience" of programmers who can effectively take advantage of all its features.

    I have not seen any concrete evidence that operator overloading was being extensively abused for writing bad code in C++. In any case if operator overloading was being used for bad things to justify a ban (to the grief of people who write programs that actually need this feature), sun could have chosen a different strategy; stronger semantics could've preventented abuse to a large extent.

    For example:
    Compiler could require that overloading '+'-operator should satisfy certain rules like:
    - If A + B = C then B + A = C.

    '-' could have semantics tied to '+' like:
    - If A + B = C then C - A = B and C - B = A.

    If classes attempted overloading and didn't satisfy these rules compiler could report an error just like when a class extends an abstract class but doesnt implemen't abstract methods.

    Remember that with operator overloading, language could become simpler in other areas. Would we need simple types at all if we had overloading?

    Regards
    Jan
  35. Thread gank /apol[ Go to top ]

    If A + B = C then B + A = C

    Impossible to verify at compile time. Should the compiler compile the class, and unit-test it in order to verify this? What if "A" and "B" are chemical components, and for some reason (which I wouldn¿t know) the order of opperands is semantically relevant? The compiler has NO WAY of knowing that; and ehy should the compiler impose such a restriction, anyway?
    Operator overloading let's you do things that look crazy in code, but code is just a syntactic convention to express some semantics. i = i + 1 is no semantically different from i++. So, I guess you can achieve the same results by using METHOD overloading... you only lose all that pretty looking syntaxis.
  36. Thread gank /apol[ Go to top ]

    MS:"Should the compiler compile the class, and unit-test it in order to verify this?"

    I guess so.

    MS:"What if "A" and "B" are chemical components, and for some reason (which I wouldn¿t know) the order of opperands is semantically relevant?"

    Then you shouldn't overload + operator to represent mixing chemicals.

    MS:"i = i + 1 is no semantically different from i++"

    Not true.
    int i = 0;
    i = i++;
    i==0;

    int i = 0;
    i = i = i+1
    i==1;

    Some say operator overloading is bad, cos devs can do crazy stuffs.
    Some say we need operator overloading to keep make math related stuffs recognizable.
    I suggest adding semantic rules to operator overloading so crazy stuffs prevented while math related stuffs can still be implemented.
  37. Thread gank /apol[ Go to top ]

    MS:"Should the compiler compile the class, and unit-test it in order to verify this?"I guess so..

    You GUESS so or you KNOW so? I'd be really dissapointed if the compiler offered me candy and wouldn't let me eat them.
    MS:"What if "A" and "B" are chemical components, and for some reason (which I wouldn¿t know) the order of opperands is semantically relevant?"Then you shouldn't overload + operator to represent mixing chemicals.

    Which suggests that operator overloading is restricted to the arithmetic semantics associated with each operator, which in turn restricts the use of operator overloading to arithmetic expressions. I mean numeric operands. And I know you can add might want to

    Color violet = new Color(BLUE) + new Color(RED);

    But arithmetic addition has nothing to do with mixing colors. What is the remainder of WHITE / VERY_BRILLIANT_RED?
    MS:"i = i + 1 is no semantically different from i++"Not true.int i = 0;i = i++;i==0;int i = 0;i = i = i+1 i==1;

    Not true? You wrote "i = i++;", which is NOT "i++;". And "i = i = i+1;" is NOT "i = i+1;". Last time I checked, "i++;" was a sentence by itself.
    I suggest adding semantic rules to operator overloading so crazy stuffs prevented while math related stuffs can still be implemented.

    Perhaps you should note that "math related stuffs" can be implemented.

    Regards,
    Martin
  38. Thread gank /apol[ Go to top ]

    I'd be really dissapointed if the compiler offered me candy and wouldn't let me eat them.

    Considder this to be beer rather than candy, you won't get any unless compiler can be fairly sure you won't puke on the floor.
    arithmetic addition has nothing to do with mixing colors.

    Not entirely sure I agree with this. If color defined 0xRRGGBB. Color.Blue + Color.Red = Color.Magenta which makes perfect sense to me.

    If your colors are a property of paint '-' may not make that much sense, since you can't remove green from yellow to make blue by stiring your bucket of paint counter clockwise.

    I am fine with restricting overloading of arithmetic operators to arithmetic operations though.
    Not true? You wrote "i = i++;", which is NOT "i++;". And "i = i = i+1;" is NOT "i = i+1;". Last time I checked, "i++;" was a sentence by itself.

    if a == b then k+a == k+b
    thus
    if (i++) == (i = i + 1) then i = i++ == i = i=i+1 which is not the case therefore i++ != i=i+1;

    i=i+1 is semantically different from i++, but identical to i+=1

    Regards
    Jan H. Hansen
  39. Thread gank /apol[ Go to top ]

    Considder this to be beer rather than candy, you won't get any unless compiler can be fairly sure you won't puke on the floor.

    I don't agree, but you sure made me laugh!! ;)
    If color defined 0xRRGGBB. Color.Blue + Color.Red = Color.Magenta which makes perfect sense to me.

    Perhaps you could answer my previous question, then.
    i=i+1 is semantically different from i++, but identical to i+=1

    I'm sad to see you're still forgetting the semicolon. "i++" is an expression, and "i++;" is a sentence. You should see the difference by now.
    So, "i++;" means "add 1 to i". "i = i + 1;" also means "add 1 to i" or "assign the result of i + 1 to i", which are two different ways (sintaxis) to say the same thing (semantics). Linguistics in a nutshell.
    if (i++) == (i = i + 1) then i = i++ == i = i=i+1 which is not the case

    I agree with that, but as I said, my sample had semicolons. That changes everything, in my humble opinion. In your argument "i = i++;" means "assign the value of i, then add 1 to i", and "i = i = i+1;" means "assign the value of i+1 to i, then assign the value of i to i".

    Really, we should open a new thread to discuss this. Perhaps NOT in theserverside.com?

    Regards,
    Martin
  40. Thread gank /apol[ Go to top ]

    When executing "i=i++;" the expression "i++" evaluates to be "i BEFORE adding 1" and then adds 1 to i. So, once i++ is evaluated you are left with i="i BEFORE adding 1". When that is evaluated, i is assigned to be its original value overwriting the increment performed when evaluating "i++";

    a=3;
    b=13;
    c=23;
    System.out.print(a++); // outputs "3" and sets a to 4
    System.out.print(++b); // sets b to 14 and outputs "14"
    c=c++; // sets c to 24 when evaluating "c++" and sets it back to 23 when evaluating "c=23"
  41. Thread gank /apol[ Go to top ]

    That's what we've been saying for like 10 posts.
  42. Thread gank /apol[ Go to top ]

    I think an interesting tech talk from C# land has emerged:
    http://www.theserverside.net/news/thread.tss?thread_id=30916

    ------
    ...It was important to have some conceptual simplicities in the language, and one of them that I think is fairly subtle, but I am really happy that we got in, is the unified type system. The notion that in C# you can just say everything is an object. You can start with that premise and then you can later delve into the sort of subtle differences between reference types, value type, but you can put anything in an object to begin with and the mechanisms, like boxing for value types, and so forth are all sort of technically interesting. But the broad simplification or the deep simplification you get by starting there, as opposed to say a language like Java, where you have to immediately up front say well there are classes and everything is class, except these eight guys over here that are specially blessed and only the language will do those.
    ---------
  43. Thread gank /apol[ Go to top ]

    And I guess you think the "everything is an object" attitude (je) saw daylight with C#...
  44. C# has improved recently[ Go to top ]

    C# has improved recently on the null support:
    http://blogs.msdn.com/somasegar/archive/2005/08/11/450640.aspx

    Would be nice if such language feature were existent in Java!
  45. Man get the real... Use .NET for the most things and use Java for things that .NET does not cover yet. .NET is much more productive and easy to use than Java is. .NET can turn your costs with software more cheaper than Java and the two platforms can interoperate by now. There's no reason to get pain... Come on realize the real.
  46. I would not agree that by using .NET it would be possible to cover all.

    How would I deliver on AS400 or Unix platform with .NET?

    By having 2 platforms in house (Java & .NET) the cost will actually increase.

    As for Java, it is possible these days to build up complete enterprise software stack for free (based on Open Source products)

    In case of .NET not much choice in the vendor and OS supported...