[Edu-sig] Properties use case

[kirby urner]

On 3/17/06, ajsiegel at optonline.net <ajsiegel at optonline.net> wrote:
> > Well, philosophically, I could see where a lot of CS types might have
> > a problem with mutable numbers, complex or otherwise.
>
> Are you a CS type? If so, speak directly.
>

I flirt with the idea, but feel more drawn to American Literature. 
Hoping for some honorary degree from UC Santa Cruz maybe, or Berkeley
even.

> If not, why do you feel compelled to speak on their behalf.
>

I'm volunteering this information.  I read a lot of CS type stuff and
know that Guido finds mutable strings an abomination in Ruby. 
Mutability must be tastefully applied.  Doing it to a primitive number
type should at least be on the table for discussion, even in polite
company.

> As an OOP devotee I am surpirsed you find this as much of an issue as you seem to.
>

I've written polyhedron, vector and modulo integer types, and
generally come to wanting to return a new object as the result of any
operation, even rotations in the case of polyhedra.  I'll use
reassignment to save namespace, but I prefer mypoly = mypoly('X', 90)
over mypoly('X',90) and a side-effect.

> My complex number is an old fashioned object.  For my purposes - destroying it and
> recreating another every time a value changes is wasteful, (and cruel ;))
>

"Old fashioned object" isn't clear enough.  It's as easy to return a
new object as not.  Neither approach is intrinsically "old fashioned".
 Look at strings.  'kirby'.uppercase() returns the string 'KIRBY'.  If
I want to keep the result, I need to assign it a reference.  That's
how primitive numbers behave too.  -2 .__invert__() returns 3, doesn't
alter -2 in any way.

> Instead of having my geometric objects of the complex plane *be* complex numbes,
> there is certainly the solution of having a complex number as an attribute of these objects

It'd see that as a separate issue.  Even if you demote the identity to
an attribute, you're still not compelled to implement that much
mutability.

> and then I can take more your approach, and at the speed of C, since I would then
> be using the built-in for arithmettic operations.
>
> There remained something unsatisfying to me about that approach.
>
> Until something blows up about my current approach, I am quite happy with it.
>

That's what I was asking.  Do you feel compelled or are you more just
freely experimenting with an approach that gives you pleasure.  I
think you've answered my question.  I'm only giving substance to my
adjective "quirky".  It's OK to be quirky and have fun, in my book
anyway.

>  And if and when something does blow up, I will know what it is  and will have
> developed some *real* expertise on the problem of mutable complex numbers, beyond
> the fear of distrubing the sleep of some abstract CS type. And will report back in.
>

Fair enough.  Just be aware of the many skeptics in your audience,
who'll think you're off on some wild goose chase in search of a
superior paradigm.

> At the moment I don't expect that to happen - but my mind is open - as it has been from
> the beginning - to the possbility that I have made a wrong turn here.
>
> Art

It all depends on your goals.  If your goal is a working PyGeo with
code your well understand, then the mutable complex number may be no
hindrance at all.  If your goal is to get your source code studied in
CS departments, as exemplary of how to go about coding such a VPython
app, that'd be a different challenge.

Probably why I'm drawn to American Literature is I think that's where
my own brand of quirkiness will find more acceptance.  I *do* want to
have my fun and need a fair amount of freedom to do so.

Likewise in the Python community, I'd hope fun experiments like yours
get a lot of latitude to just develop as they develop.  You'll solicit
feedback, sure, but there's nobody here pretending to be your boss in
any way.

Kirby