Issue1645

This will allow for users to extend these types in interesting ways, as seen in processing.py, and should not have a performance impact on any modern JVM. (It's already consistently done in PyInteger.)

This refactoring would probably be reasonable for PyDictionary and other types, but deferring that for now, so changing the title.

Because PyBoolean is a subclass of PyInteger (due to int/bool compatibility in Python, which stems from the lack of bool prior to 2.2), you need to override getBooleanValue, which is then used by getValue.

Fixed in r7097, but marking as pending because we need unit tests around how this can be used to support user type extension.

The enclosed patch fixes a couple of lingering non-encapsulated references to the field, and creates unit tests for each of the affected classes. The unit tests can and will be improved in the coming days to exercise more __magic__ operator methods, but this puts the basic format in place.

I think I understand why you'd want to construct mutable versions of these types for something like processing.py, but two cautions if this is representative of your code:

1) Obviously objects of these types are no longer hashable as such and thus will really screw things up if they're placed in a Map. You may want to change their hashCode to be on their object identity, or throw a TypeError, like PyList.

2) Normally you should consider making the underlying fields volatile.

Mutation likely impacts PyString/PyUnicode even more.
 
Also, the current field in PyString is string, so should it be getValue or getString? I tend to favor the latter form this moment.

> 1) Obviously objects of these types are no longer hashable as such and thus
> will really screw things up if they're placed in a Map. You may want to
> change their hashCode to be on their object identity, or throw a TypeError,
> like PyList.
>

Excellent advice. Your intuition is right, that this is a peculiar use case.
It would be bizarre for a processing user to use, say, the current mouse x
position in pixels as a dictionary key.

Devil's advocate: given your legitimate concern that PyInteger and its kin
represent immutable values, why isn't "value" immutable?

Finally, I should say that given how idiosyncratic my use case is, I
wouldn't have any hard feelings if the committers thought it best to go back
to direct field access on an i

> 2) Normally you should consider making the underlying fields volatile.
>

Will do.

> Also, the current field in PyString is string, so should it be getValue or
> getString? I tend to favor the latter form this moment.
>

I'd argue for the former for some sort of "least surprise" aesthetic
relative to the other PyThings, but I'm very new to the project, and
wouldn't want to argue strongly for anything!

Very kind regards,
-- 
Jonathan Feinberg  jdf@pobox.com  http://MrFeinberg.com/

PyInteger.value not being final is definitely an oversight, like so much discussed here. I actually changed the other fields to be final. I will make that change too, as well as try out the patch.

Committed Jonathan's patchset in r7100. Thanks!

We still need more tests around PyString, PyUnicode, as well as the whole hashing discussion, but it's looking good.

Closing this bug out. We always need more tests, but it's enough for now.