Re: News for Java?

Discussion in 'Java' started by Tim Slattery, Jan 4, 2011.

  1. Tim Slattery

    Tim Slattery Guest

    Tim Slattery, Jan 4, 2011
    #1
    1. Advertising

  2. On 04/01/2011 6:29 AM, Midnightmare wrote:
    > "Tim Slattery" <> ha scritto:
    >
    >> I have no clue what you mean by this.

    >
    > Introduction of overload of operators, fuctional programming, parameters
    > passed by reference, safe and unsafe context, etc...


    http://openjdk.java.net/projects/jdk7/features/

    IMHO,

    Overload of operators: over-rated ("Sounds like you've been burned with
    them in C++, Travers." "Only by people who followed the anti-patterns
    for operator overloading, and there are a lot of those people...")

    Functional programming: Lambda expressions are in 7

    Passed by reference: *splurts coffee* am I the only programmer that
    hates this? I hate sending 10 parameters in when I can just send in a
    class/structure.

    Safe/unsafe: Technically, it's always been in Java -- it's called JNI

    The only thing in C# I really like is the property syntax. And the
    latest versions of C# where you can just type { get; set; }. That I
    have always wanted in Java. Eclipse has nice auto-generators for
    properties, but I like the idea of not cluttering my classes with
    brain-dead getters and setters. :)
    Travers Naran, Jan 4, 2011
    #2
    1. Advertising

  3. Tim Slattery

    Tim Slattery Guest

    Travers Naran <> wrote:


    >Passed by reference: *splurts coffee* am I the only programmer that
    >hates this? I hate sending 10 parameters in when I can just send in a
    >class/structure.


    And objects are passed by reference. All non-basic Java variables
    (everything except char, int, float, double, boolean...) are
    references to an object.

    >The only thing in C# I really like is the property syntax. And the
    >latest versions of C# where you can just type { get; set; }. That I
    >have always wanted in Java. Eclipse has nice auto-generators for
    >properties, but I like the idea of not cluttering my classes with
    >brain-dead getters and setters. :)


    Yeah, a shortcut syntax for that would be a good thing. Getters and
    setters are not always one-liners, but the overwhelming majority of
    them are.

    --
    Tim Slattery

    http://members.cox.net/slatteryt
    Tim Slattery, Jan 4, 2011
    #3
  4. On 01/04/2011 11:04 AM, Travers Naran wrote:
    > Functional programming: Lambda expressions are in 7


    The last I heard, this was shoved off until Java 8.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Jan 4, 2011
    #4
  5. Tim Slattery

    Travers Guest

    On Jan 4, 9:26 am, Tim Slattery <> wrote:
    > Travers Naran <> wrote:
    > >Passed by reference: *splurts coffee* am I the only programmer that
    > >hates this?  I hate sending 10 parameters in when I can just send in a
    > >class/structure.

    >
    > And objects are passed by reference. All non-basic Java variables
    > (everything except char, int, float, double, boolean...) are
    > references to an object.


    Let me clarify. My understanding of pass by reference, in this C#
    context, is:

    public void createStream(out StreamClass b) {
    b = new StreamClass();
    }

    public void main() {
    ...
    StreamClass b = null;
    createStream(b);
    // b is now magically filled with a reference to a new StreamClass
    }

    It's _this_ kind of C# pass by reference I am opposed to. In OOP, I
    don't believe one needs this kind of pass by reference for anything.
    I can think of maybe one case for optimization:

    class Coord {

    public void toPixelXY(out int x, out int y) {
    x = ...;
    y = ...;
    }
    }

    In this case, the overhead of creating a new class just to pass two
    integers back may be overkill. But I'd still say, "Profile first,
    Optimize Second". Also, one could use instead:

    class WorldCoord {

    public void toPixelXY( PixelCoord coord ) {
    coord.x = ...;
    coord.y = ...;
    }
    }

    Which could potentially be just as efficient, especially in case like:

    PixelCoord pc = new PixelCoord();
    for {i = 0; i <= MAX_POINTS; i++ ) {
    wc.toPixelXY(pc);
    // Draw with pc
    }
    Travers, Jan 4, 2011
    #5
  6. Tim Slattery

    Travers Guest

    On Jan 4, 9:44 am, Joshua Cranmer <> wrote:
    > On 01/04/2011 11:04 AM, Travers Naran wrote:
    >
    > > Functional programming: Lambda expressions are in 7

    >
    > The last I heard, this was shoved off until Java 8.


    Motherfuh... *shakes head*

    I would have dearly loved lambda expressions. They're my favorite
    thing from LISP (only one of 2 things I like about LISP).
    Travers, Jan 4, 2011
    #6
  7. Tim Slattery

    markspace Guest

    On 1/4/2011 11:10 AM, Chris Uppal wrote:

    > I dislike "accessors" more -- much more -- than I dislike
    > pass-by-reference-to-variable parameters.
    >
    > Pass-by-ref[etc] is an invitation to abuse, but isn't all that often abused
    > simply because it isn't often "needed"; but accessors are more like an /order/
    > to abuse -- they teach you wrong by their mere existence.
    >
    > The "accessors of evil", as I think someone once said.



    Huh, I don't think I understand. I don't recall hearing a sentiment
    like this expressed before. At worst, Java's accessors (getter/setters)
    have a vertical problem where a code listing is longer than it strictly
    needs to be.

    But that's the worst I've heard about them. Everything elese I've heard
    says that accessors are a good way of encapsulating your code.

    What's the argument advocating avoiding accessors?
    markspace, Jan 4, 2011
    #7
  8. On 11-01-04 04:05 PM, markspace wrote:
    > On 1/4/2011 11:10 AM, Chris Uppal wrote:
    >
    >> I dislike "accessors" more -- much more -- than I dislike
    >> pass-by-reference-to-variable parameters.
    >>
    >> Pass-by-ref[etc] is an invitation to abuse, but isn't all that often
    >> abused
    >> simply because it isn't often "needed"; but accessors are more like an
    >> /order/
    >> to abuse -- they teach you wrong by their mere existence.
    >>
    >> The "accessors of evil", as I think someone once said.

    >
    >
    > Huh, I don't think I understand. I don't recall hearing a sentiment like
    > this expressed before. At worst, Java's accessors (getter/setters) have
    > a vertical problem where a code listing is longer than it strictly needs
    > to be.
    >
    > But that's the worst I've heard about them. Everything elese I've heard
    > says that accessors are a good way of encapsulating your code.
    >
    > What's the argument advocating avoiding accessors?
    >

    It's obviously not black and white. It's a question of what are you
    using the getters and setters for. There's way too much code out there
    that extracts fine-grained state from objects using getters, then does
    logic using all that state, when it should have been the object itself
    that was asked to do it, and provide the final result.

    Except in special situations that require fine-grained accessors, like
    JPA entities or JSF backing beans, when it comes time to design a class
    I start with one that has constructors, and _no_ getters/setters. It's
    then up to a solid design process to justify the need for a basic getter
    or setter.

    AHS
    Arved Sandstrom, Jan 4, 2011
    #8
  9. Tim Slattery

    markspace Guest

    On 1/4/2011 3:06 PM, Arved Sandstrom wrote:

    > It's obviously not black and white. It's a question of what are you
    > using the getters and setters for. There's way too much code out there
    > that extracts fine-grained state from objects using getters, then does
    > logic using all that state, when it should have been the object itself
    > that was asked to do it, and provide the final result.



    Ah, OK. Thanks for the explanation. I was not aware of this. I'm not
    sure I agree -- "way too much" I think might be a gross exaggeration, a
    straw man. But at least I now understand the general direction of the
    argument.
    markspace, Jan 5, 2011
    #9
  10. Tim Slattery

    Arne Vajhøj Guest

    On 04-01-2011 12:26, Tim Slattery wrote:
    > Travers Naran<> wrote:
    >> Passed by reference: *splurts coffee* am I the only programmer that
    >> hates this? I hate sending 10 parameters in when I can just send in a
    >> class/structure.

    >
    > And objects are passed by reference. All non-basic Java variables
    > (everything except char, int, float, double, boolean...) are
    > references to an object.


    All non simple types is passing a reference by value.

    Which is somewhat different.

    You can change the content of the object but you can not
    get the reference to point to another object.

    >> The only thing in C# I really like is the property syntax. And the
    >> latest versions of C# where you can just type { get; set; }. That I
    >> have always wanted in Java. Eclipse has nice auto-generators for
    >> properties, but I like the idea of not cluttering my classes with
    >> brain-dead getters and setters. :)

    >
    > Yeah, a shortcut syntax for that would be a good thing. Getters and
    > setters are not always one-liners, but the overwhelming majority of
    > them are.


    On the other hand adding getters and setters will introduce
    two syntaxes for method calls.

    Because properties does actually not enforce any rules
    about what the code does.

    Arne
    Arne Vajhøj, Jan 5, 2011
    #10
  11. On 01/04/2011 03:05 PM, markspace wrote:
    > What's the argument advocating avoiding accessors?


    I think the complaint is generally about giving accessors to many/most
    private variables, i.e. a "have them unless there's no reason not to"
    versus a "don't have them unless there's a reason to".

    In my opinion, the property accessor shorthand is not worthwhile since
    a) It would probably encourage ignorant overuse of accessors
    b) It would probably encourage underdocumentation, i.e., "how does
    setting this property affect internal state of others"
    c) It would also likely encourage the use of mutable POD-ish classes
    instead of immutable ones.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
    Joshua Cranmer, Jan 5, 2011
    #11
  12. Tim Slattery

    Arne Vajhøj Guest

    On 04-01-2011 15:05, markspace wrote:
    > On 1/4/2011 11:10 AM, Chris Uppal wrote:
    >> I dislike "accessors" more -- much more -- than I dislike
    >> pass-by-reference-to-variable parameters.
    >>
    >> Pass-by-ref[etc] is an invitation to abuse, but isn't all that often
    >> abused
    >> simply because it isn't often "needed"; but accessors are more like an
    >> /order/
    >> to abuse -- they teach you wrong by their mere existence.
    >>
    >> The "accessors of evil", as I think someone once said.

    >
    > Huh, I don't think I understand. I don't recall hearing a sentiment like
    > this expressed before. At worst, Java's accessors (getter/setters) have
    > a vertical problem where a code listing is longer than it strictly needs
    > to be.
    >
    > But that's the worst I've heard about them. Everything elese I've heard
    > says that accessors are a good way of encapsulating your code.
    >
    > What's the argument advocating avoiding accessors?


    One well known argument is that the object should expose
    real methods with business logic and let those change the
    state instead of letting the calling code change whatever
    it wants.

    It has some theoretical merit. But from a practical point
    of view it is bullshit. There are no real problems having
    setters.

    Arne
    Arne Vajhøj, Jan 5, 2011
    #12
  13. On 04-01-2011 20:57, Peter Duniho wrote:
    > On 1/4/11 11:43 AM, Travers wrote:
    >> [...]
    >> It's _this_ kind of C# pass by reference I am opposed to. In OOP, I
    >> don't believe one needs this kind of pass by reference for anything.

    >
    > Well, since you can write pretty much any program in Java that you can
    > in any other language, strictly speaking that's a clearly true statement.
    >
    > But, pass-by-reference when used sparingly can simplify certain kinds of
    > APIs. The "TryX" pattern is reasonably common in .NET, where the method
    > returns a boolean, indicating whether or not the method was successful,
    > and if it was successful, the result is written to a by-ref argument.


    It can be practical because it makes it easy to return
    more than one value.

    But it is not good for code readability.

    C# somewhat mitigated that by requiring a keyword in
    the actual call.

    Arne
    Arne Vajhøj, Jan 5, 2011
    #13
  14. "Chris Uppal" <-THIS.org> wrote in message
    news:...
    > Travers Naran wrote:
    >
    >> Passed by reference: *splurts coffee* am I the only programmer that
    >> hates this?

    >
    > No.
    >
    > Sorry, let me expand on that:
    >
    > NO NO NO NO NO !!!


    Stop equivocating.
    Mike Schilling, Jan 5, 2011
    #14
  15. "Peter Duniho" <> wrote in message
    news:...
    >
    > Even Java has at least one place I know of where the JDK API requires you
    > to pass an array so that the method can return more than one value and do
    > so without allocating a new object each call.


    It would be neater (IMHO) for InputStream.get() to be defined

    boolean get(out char c)

    than

    int get()

    with a special return value that means "there wasn't one".
    Mike Schilling, Jan 5, 2011
    #15
  16. On 11-01-04 09:19 PM, markspace wrote:
    > On 1/4/2011 3:06 PM, Arved Sandstrom wrote:
    >
    >> It's obviously not black and white. It's a question of what are you
    >> using the getters and setters for. There's way too much code out there
    >> that extracts fine-grained state from objects using getters, then does
    >> logic using all that state, when it should have been the object itself
    >> that was asked to do it, and provide the final result.

    >
    > Ah, OK. Thanks for the explanation. I was not aware of this. I'm not
    > sure I agree -- "way too much" I think might be a gross exaggeration, a
    > straw man. But at least I now understand the general direction of the
    > argument.


    Well, not a straw man. It's a personal opinion; it's anecdotal; it's
    what I have observed. I've noticed that since modern IDEs make it easy
    to do the "JavaBean thing", then many coders take advantage of that.

    But that's the general thrust of the argument, that object accessors -
    probably more getters than setters - are abuse enablers.

    AHS
    Arved Sandstrom, Jan 5, 2011
    #16
  17. On 11-01-04 10:12 PM, Arne Vajhøj wrote:
    > On 04-01-2011 15:05, markspace wrote:
    >> On 1/4/2011 11:10 AM, Chris Uppal wrote:
    >>> I dislike "accessors" more -- much more -- than I dislike
    >>> pass-by-reference-to-variable parameters.
    >>>
    >>> Pass-by-ref[etc] is an invitation to abuse, but isn't all that often
    >>> abused
    >>> simply because it isn't often "needed"; but accessors are more like an
    >>> /order/
    >>> to abuse -- they teach you wrong by their mere existence.
    >>>
    >>> The "accessors of evil", as I think someone once said.

    >>
    >> Huh, I don't think I understand. I don't recall hearing a sentiment like
    >> this expressed before. At worst, Java's accessors (getter/setters) have
    >> a vertical problem where a code listing is longer than it strictly needs
    >> to be.
    >>
    >> But that's the worst I've heard about them. Everything elese I've heard
    >> says that accessors are a good way of encapsulating your code.
    >>
    >> What's the argument advocating avoiding accessors?

    >
    > One well known argument is that the object should expose
    > real methods with business logic and let those change the
    > state instead of letting the calling code change whatever
    > it wants.
    >
    > It has some theoretical merit. But from a practical point
    > of view it is bullshit. There are no real problems having
    > setters.
    >
    > Arne
    >

    There are no real problems having setters??? Come on, Arne, are you just
    being rambunctious these past few or what? Leaving aside getters
    completely (and all the real-world problems associated with over-use of
    those), every setter on a class introduces a vulnerability: it's an
    additional worry when you reason about what external code is modifying
    instances of that class.

    You're either advancing the argument that the majority of coders are
    sparing and conservative when it comes to providing setters - which I
    sure as hell haven't seen - or that the majority of coders are sparing
    and conservative when it comes to using the setters that have been so
    helpfully provided for them...and I haven't seen that general discipline
    either.

    Either of _our_ observations are just single data points, so either one
    of us could be mistaken. But until I see studies saying I'm wrong, if I
    think that the idea that setters are problematic has theoretical merit
    (which you tepidly agreed with), then I'll assume it has practical merit
    also.

    AHS
    Arved Sandstrom, Jan 5, 2011
    #17
  18. Tim Slattery

    Tom Anderson Guest

    On Tue, 4 Jan 2011, Peter Duniho wrote:

    > On 1/4/11 11:43 AM, Travers wrote:
    >> [...] It's _this_ kind of C# pass by reference I am opposed to. In
    >> OOP, I don't believe one needs this kind of pass by reference for
    >> anything. I can think of maybe one case for optimization:
    >>
    >> class Coord {
    >> public void toPixelXY(out int x, out int y) {
    >> x = ...;
    >> y = ...;
    >> }
    >> }

    >
    > Ironically, if Java had user-defined value types, then the "avoid creating a
    > new object to return multiple values" would be a less compelling argument in
    > favor of pass-by-reference in Java. A method could just return a compound,
    > user-defined value type instead.


    Multiple return values would also do that, with less verbiage, and be a
    simpler change at the language and VM levels.

    > But Java doesn't have that feature either. :)


    That too. Not enough Dutchmen at Sun, obviously.

    tom

    --
    20 Minutes into the Future
    Tom Anderson, Jan 5, 2011
    #18
  19. Tim Slattery

    Tom Anderson Guest

    On Tue, 4 Jan 2011, Mike Schilling wrote:

    > "Peter Duniho" <> wrote in message
    > news:...
    >
    >> Even Java has at least one place I know of where the JDK API requires
    >> you to pass an array so that the method can return more than one value
    >> and do so without allocating a new object each call.

    >
    > It would be neater (IMHO) for InputStream.get() to be defined
    >
    > boolean get(out char c)
    >
    > than
    >
    > int get()
    >
    > with a special return value that means "there wasn't one".


    Even better:

    byte get() throws EndOfFileException

    Although i know that many would not agree with me on that.

    tom

    --
    20 Minutes into the Future
    Tom Anderson, Jan 5, 2011
    #19
  20. Tim Slattery

    Stefan Ram Guest

    Tom Anderson <> writes:
    >byte get() throws EndOfFileException


    Or, java.util.Iterator<java.lang.Byte>:
    boolean hasNext(), java.lang.Byte next().
    Stefan Ram, Jan 5, 2011
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Paul Briggs
    Replies:
    1
    Views:
    391
    Mitja
    Jun 8, 2004
  2. Talimore
    Replies:
    4
    Views:
    529
    T. Audry Glamour
    Jul 18, 2004
  3. Amy
    Replies:
    0
    Views:
    491
  4. Replies:
    1
    Views:
    309
    Steve Holden
    Oct 16, 2005
  5. Guest
    Replies:
    1
    Views:
    343
    Matt H
    Apr 14, 2006
Loading...

Share This Page