Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #24573

Re: multiple inheritance in Java

From Eric Sosman <esosman@comcast-dot-net.invalid>
Newsgroups comp.lang.java.programmer
Subject Re: multiple inheritance in Java
Date 2013-07-02 00:30 -0400
Organization A noiseless patient Spider
Message-ID <kqtkmm$4ac$1@dont-email.me> (permalink)
References <multiple-inheritance-20130702024630@ram.dialup.fu-berlin.de> <kqtbs2$ou6$1@dont-email.me> <multiple-inheritance-20130702042118@ram.dialup.fu-berlin.de>

Show all headers | View raw


On 7/1/2013 10:32 PM, Stefan Ram wrote:
> markspace <markspace@nospam.nospam> writes:
>> With private fields, you can enforce some constraint on color and
>> position.  Without it, you'll constantly have to check in every method
>> if those constrains are still valid or not.
>
>    I only deal with cases where no additional constraints are required.

     So, just a struct?

>> There's other reasons.  Public final fields aren't thread safe, for
>> example, so you're encouraging bad style, imo.
>
>    I don't actually know what it means for a field to be thread
>    safe. But I was talking about final fields (see also below).
>    Those fields are only written to in the constructor.

     Yeah, but they are references to objects with non-final fields.
If thread T1 does cp.color.setR(42) and T2 does r=pc.color.getR()
while cp and pc refer to the same ColorPoint instance (or to distinct
ColorPoint instances that refer to the same Color instance), you've
got a race.

>> You also allow any arbitrary changes to your class this way, and forgo
>> encapsulation.  This also seems bad style.
>
>    A class in Java can only be changed by the programmer.
>    Possibly you are speaking of an instance of that class.
>    Since the fields I gave where final (see also below),
>    they cannot be changed outside of the constructor.

     A non-final class in Java can only be changed by *any*
programmer, via the mechanism of extension.  For example,
I might write

	/**
	 * A specialized ColorPoint that automatically adjusts
	 * its "saturation" depending on the distance from a
	 * designated origin position.
	 */
	public class RadialColorPoint extends ColorPoint {
	    ...
	}

... and suddenly I've got constraints not anticipated by the
original author -- without changing a single line of his code.
With (overridable) accessors I could manage those constraints;
with exposed fields I could not.

>> What's your goal here?
>
>    It seems best to me to implement something this way, and I wonder
>    whether I have missed potential issues with it.

     "It seems best" isn't a goal, it's at most a whimsy.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: multiple inheritance in Java markspace <markspace@nospam.nospam> - 2013-07-01 18:59 -0700
  Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 00:30 -0400
    Re: multiple inheritance in Java Eric Sosman <esosman@comcast-dot-net.invalid> - 2013-07-02 08:17 -0400
    Re: multiple inheritance in Java Arne Vajhøj <arne@vajhoej.dk> - 2013-07-04 16:31 -0400

csiph-web