Darren New <dne### [at] sanrrcom> wrote:
> Yes! Precisely. You're not changing the value of 5. You're changing the 
> value of 'a'.

  I'm sorry, but I'm having difficult time understanding what you are
talking about. It just seems inconsistent and incoherent.

  In a previous post you argued how you are not changing the value of 'a'
and now you are saying that you are.

> Contrast with
> a = " hello  "; b = a;  a.trim();

> Whether you changed 'b' depends on whether string literals have value or 
> reference semantics. *Unless* strings are read-only, in which case a.trim() 
> returns a new string which gets discarded.

  I don't really understand what's your point.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Or, maybe more clearly....

> a = 5; b = a; a++;

> This doesn't change the value in 'b'.

  I don't even understand why it should, if you are handling value-based
variables.

> You're not incrementing the value in 
> 'a'. You're replacing the value in 'a' with a new value.

  "a++" probably results in an assembler machine code which makes the CPU
increment the value of a memory location by one. Exactly how the bits go
through the transistors in order to achieve this feels irrelevant. It's
the end result that matters: You modified the value of the variable.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I don't really understand what's your point.

Did you read the link about DDD?

If you design software that way, one of the rules can be summarized as 
"objects which you can copy must have value semantics" by which it is meant 
that they must be immutable once created, like integers or Java strings.

On the other hand, objects which have an identity (i.e., which correlate to 
real world entities or get stored persistently) cannot be duplicated.

In other words (and over-simplifying), your objects either represent things 
related to the domain (and thus have an identity and thus make no sense to 
duplicate in memory) or they represent attributes of those things (and thus 
have no identity but also don't make sense to modify, being the values an 
attribute in the modifiable entity takes on).

Given that, a language where anything big enough to hold a pointer needs to 
be treated as a reference doesn't seem like a burden. That a pixel may need 
to get accessed with a syntax like a "friend function" provides instead of 
distinguished-caller doesn't seem problematic to me in the big picture, if 
indeed your language requires such a change.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message