Path: csiph.com!usenet.pasdenom.info!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED.c-24-60-169-94.hsd1.ma.comcast.net!not-for-mail From: Eric Sosman Newsgroups: comp.lang.java.programmer Subject: Re: multiple inheritance in Java Date: Tue, 02 Jul 2013 00:30:18 -0400 Organization: A noiseless patient Spider Lines: 59 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Tue, 2 Jul 2013 04:24:54 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="c-24-60-169-94.hsd1.ma.comcast.net:24.60.169.94"; logging-data="4428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="esosman" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:24573 On 7/1/2013 10:32 PM, Stefan Ram wrote: > markspace 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