Re: Downgrading to D7

Daniel Mantione wrote:

Craig Stuntz [TeamB] wrote:

Rudy Velthuis [TeamB] wrote:

And yet, even if Daniel thinks it is not much use to store structured
items (objects, records) on the stack [...]

I'm not sure he actually said that. It's hard to tell.

I think there is a lot of use to store things on the stack, but in managed
environment this seems more the responsibility of the VM than that of the
programmer. I.e. you declare variables as value or reference,

Assumption: I'm talking about .NET / CLI here.

Your types (rather than your variables) are defined as value or
reference, and it makes a big difference.

but what a
reference means is totally up to the VM, the concepts stack and heap or not
defined.

Stack and heap are unhelpful red herrings when discussing the
distinction between value and reference types, because value types may
be on the heap too, if they're boxed or contained inside a reference
type.

Anyway, what I wanted to say is that in garbage collected language there is
no need to have value classes because of the easier memory management.

Value types have different semantics to reference types. It's not a
matter of them being unnecessary; it's a matter of them being different,
and serving a different purpose. It primarily crops up when passing
parameters.

When a value of a value type is passed by value, it is copied in toto;
thus, modifying the instance in the called function won't change the
original passed-in value.

When a value of a reference type is passed by value, the reference is
copied, and thus there will be an extra reference to the same instance
data, and therefore modifying the instance in the called function will
affect the original passed-in value.

These semantics combine to make value types quite appropriate for value
scenarios, such as e.g. a Complex (number) type. If you've got a
variable of a complex number type somewhere in your program, you
probably don't expect it to randomly change value if you happened to
have passed it to other code, which might themselves have held onto
references.

Reference types can get most of the semantic benefits of value types by
adopting an immutable design. System.String in the BCL is a good example
of this. Since it's not of a fixed size, it's a natural for a
heap-allocated structure, yet it still needs value semantics (i.e. no
random and possibly unauthorised changes simply by sharing the
reference). The (semantic) benefit that gets left behind is obviously
mutability that preserves value semantics.

For an example of the horrors of a mutable reference-type string by
default:

---8<---
type
T = class
private
F: MutableString;
public
property P: MutableString read F;
end;

// ...

begin
T.Create.P[1] := 'x'; // modifying read-only property - oh dear!
end.
--->8---

To avoid these problems with mutable reference types, you have to be
paranoid and continuously make copies, in order to preserve value
semantics.

This whole shebang has interesting ramifications, BTW., with respect to
current Delphi semantics. The standard party line on properties is that
it doesn't matter if you make your accessors fields, you're always free
to make them methods later. In order to preserve that, Delphi actually
has a C++-like concept of constness baked in, but it doesn't go the
whole way and that causes other problems. Consider:

---8<---
type
R = record
X: Integer;
procedure M(Y: Integer);
end;

T = class
private
F: R;
function GetF: R;
public
property P: R read F;
property P2: R read GetF;
end;

procedure R.M(Y: Integer);
begin
X := Y;
end;

function T.GetF: R;
begin
Result := F;
end;

begin
// T.Create.P.X := 42; // can't do, P is const
T.Create.P.M(42); // oh dear, no notion of const methods
T.Create.P2.M(42); // oh dear, different semantics to field accessor
end.
--->8---

-- Barry

--
http://barrkel.blogspot.com/
.

Relevant Pages