Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] Java question

Expand Messages
  • Chris Hanson
    ... I have the opposite issue, coming from an Objective-C (effectively Smalltalk) background: There is functionality I find I need that isn t in Java. Others
    Message 1 of 54 , Sep 1, 2003
      On Monday, September 1, 2003, at 03:35 PM, Victor wrote:
      > Is
      > there any Java functionality you find you don't need, or use very
      > infrequently, either in general, or because you are using some XP
      > aspect,
      > like TDD?

      I have the opposite issue, coming from an Objective-C (effectively
      Smalltalk) background: There is functionality I find I need that isn't
      in Java.

      Others have mentioned Smalltalk-style blocks, which I too simulate with
      anonymous inner classes. (This is actually a minor benefit of Java
      over Objective-C; blocks are one of the few Smalltalk constructs the
      language doesn't have and that can't be simulated easily. But
      simulating blocks in Java is, as others have noted, kind of ugly...)

      Another thing I generally need is easy introspection. Java supports
      introspection, but makes it cumbersome. Delegation is a very common
      design pattern in Cocoa and WebObjects, and one that I find myself
      using in my own development as well. (This is different from what C#
      calls a "delegate," by the way -- Cocoa delegates came first by over a
      decade.)

      So, in Cocoa and Objective-C, let's say I have a generic object of
      class Foo that needs to ask its delegate what color it should be. Its
      delegate can be an object of any class -- there isn't really a type
      relationship there, delegates just need to respond to individual
      messages. This allows for very loose coupling between classes, and
      results in much more re-use than I've experienced in other languages
      like C++.

      So in Objective-C I'd write:

      @implementation Foo
      - (NSColor *)color {
      NSColor *color;
      id delegate = [self delegate];

      if ([delegate respondsToSelector:@selector(colorOfFoo:)]) {
      color = [delegate colorOfFoo:self];
      } else {
      color = [self defaultColor];
      }

      return color;
      }
      @end

      (To explain one quirk of Objective-C, "id" is a type that stands for
      "an instance of any class." It's needed because even though
      Objective-C as a message-based language uses single inheritance, it
      supports multiple root classes. Even so, the runtime requires a
      certain minimum amount of functionality from any root class, including
      support for -respondsToSelector:.)

      In Java it's quite a bit more difficult to find out whether an
      individual object can respond to a particular message at run-time and
      then send that message.

      Fortunately, when doing Cocoa development in Java and when doing
      WebObjects development, Apple provides an NSSelector convenience class:

      class Foo {
      public NSColor color() {
      NSColor color;
      Object delegate = delegate();
      NSSelector selector = new NSSelector("colorOfFoo", new Class[] {
      Foo.class });

      if (selector.implementedByObject(delegate)) {
      try {
      color = (NSColor) selector.invoke(delegate, new Object[] {
      this });
      }
      catch (Exception exception) {
      throw new RuntimeException(exception);
      }
      } else {
      color = defaultColor();
      }

      return color;
      }
      }

      It's a bit uglier and less concise than the Objective-C version, thanks
      in part to Java's obsession with type safety, but it's still reasonably
      functional. If I were doing pure Java development, I expect I'd evolve
      something very similar to the NSSelector class very quickly.

      -- Chris

      --
      Chris Hanson, bDistributed.com, Inc. | Email: cmh@...
      Custom Mac OS X Development | Phone: +1-847-372-3955
      http://bdistributed.com/ | Fax: +1-847-589-3738
      http://bdistributed.com/Articles/ | Personal Email: cmh@...
    • Ron Jeffries
      ... Yes ... I was wondering, though, if it would be acceptable to have it be that they can t even add lines or change them if they cause a conflict? Ron
      Message 54 of 54 , Sep 7, 2003
        On Sunday, September 7, 2003, at 8:35:58 PM, Jeff Grigg wrote:

        > We read Header & Details from a database and populate a web page
        > (header and table of details, of course). The user can add, change
        > and delete lines to their heart's content and then save/submit the
        > page back to the server. (Yes, this means JavaScript and DOM
        > manipulation -- to add new Detail objects.) The server has a
        > framework that will fetch existing objects from the database, check
        > optimistic locks (timestamps) and apply all user changes
        > (add/change/delete).

        > This subroutine is a last minute validation that occurs before the
        > results are saved back to the database. If it fails (IE: finds
        > conflicts), we display an error message on the screen and allow the
        > user to keep changing and submitting until it's acceptable.

        Yes ... I was wondering, though, if it would be acceptable to have it be
        that they can't even add lines or change them if they cause a conflict?

        Ron Jeffries
        www.XProgramming.com
        It is not because things are difficult that we do not dare,
        it is because we do not dare that they are difficult. --Seneca
      Your message has been successfully submitted and would be delivered to recipients shortly.