[Edu-sig] Properties use case

[Scott David Daniels]

Arthur wrote:
>  
> ...
> Isn't the creation of any class the creation of one's own type? Now what am
> I missing now? 
Ahh, I thought we were talking about language primitives.  The range of
behavior for non-primitives is larger.  For example, a Vertex in 3-space
for a polyhedron might have mutable x, y, and z properties just so that
shared points and coincident points are distinguished.

> My class - unless I am missing something else - does complex mathematics
> exactly as does the built-in type. But it is now the Complex type, say.
> Which allows me to say a=Complex(5,3) on creation, and a.real = 6 somewhere
> down the line. Obviously notation ally, a=5 +3j will still return the Python
> immutable built-in type. Which is fine by me.    
I thought you had been asking why it was wrong to make a primitive mutable.

> That's exactly why I am having so much trouble with the problem I seem to be
> causing here. I understand next to nothing about threading, but can't
> understand why this particular class is any less safe than any other class
> one might create and use. 
It is not, except for one thing: one often thinks of complex numbers as
values, and when they are mutable, they are more objects than values.
It is dangerous in that users of the type may have wrong intuitions.

> ...But no, *don't* like to give up performance, and have been happy to have had
> a discussion that led me to a possible alternative that is prettier, *and*
> faster. 
OK, so one big performance gain is that immutable values can be safely
shared, a copy is never a meaningful operation on an immutable type.

--Scott David Daniels
Scott.Daniels at Acm.Org