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

Re: [XP] Value Vs. References

Expand Messages
  • Marty Nelson
    Kent - ... value vs. ... places where ... disadvantages ... Are you using Value Object to mean an immutable object? Strictly speaking, isn t the difference
    Message 1 of 9 , May 24, 2008
      Kent -

      > "Implementation Patterns" has more of my recent thinking about
      value vs.
      > reference types. Mostly now I'm trying to expand the number of
      places where
      > I can use value types, since the advantages are large and the
      disadvantages
      > (primarily performance) are shrinking.

      Are you using Value Object to mean an immutable object?

      Strictly speaking, isn't the difference that the memory for a value
      type is directly stored on the stack, whereas a reference type stores
      a memory pointer on the stack that points to a memory location on the
      heap?

      I don't know about java, but in .net, they have something called a
      struct that allows you to define a complex value type. I've seen no
      end of trouble when people basically take what should be a class and
      make it into a struct because they think it will perform better.

      But I think you're talking about something different, which is
      striving for immutable objects that don't change once they're
      instantiated and the shift from procedural to functional programming.

      I'm not sure what Amol meant, but I wanted to avoid any confusion.

      Here are two interesting links (from the c# world), one about types
      of immutability and one on the value v ref performance issue in the
      modern CPU/memory management world:

      http://blogs.msdn.com/ericlippert/archive/2007/11/13/immutability-in-
      c-part-one-kinds-of-immutability.aspx

      http://en.csharp-online.net/CSharp_Coding_Solutions%E2%80%
      94Immutable_Types_Are_Scalable_Types
    Your message has been successfully submitted and would be delivered to recipients shortly.