Path: csiph.com!aioe.org!.POSTED!not-for-mail From: =?UTF-8?Q?Arne_Vajh=c3=b8j?= Newsgroups: comp.lang.java.programmer Subject: Re: How to assign an object to another in it method? Date: Tue, 11 Jul 2017 20:16:51 -0400 Organization: Aioe.org NNTP Server Lines: 85 Message-ID: References: <46334961-cc18-491f-828c-32e7401c7832@googlegroups.com> NNTP-Posting-Host: PBuS014lhzVyHjLbXmo/ZQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Language: en-US Xref: csiph.com comp.lang.java.programmer:36851 On 7/8/2017 10:12 PM, Jerry Stuckle wrote: > On 7/8/2017 9:13 PM, Arne Vajhøj wrote: >> On 7/4/2017 10:18 PM, Jerry Stuckle wrote: >>> On 7/4/2017 9:46 PM, Arne Vajhøj wrote: >>>> On 7/3/2017 11:15 PM, Jerry Stuckle wrote: >>>>> On 7/3/2017 10:04 PM, Arne Vajhøj wrote: >>>>>> I hope that a static code analysis tool create warnings >>>>>> about doing something like that. >>>>> >>>>> Why should they, Arne? Default values are just that - values used when >>>>> no others are given. They are not the only valid values, and are there >>>>> to be overridden. >>>> >>>> It indicates that the author of the super class and the author of the >>>> sub class seems to disagree on at least one aspect of how the method >>>> should be. That is something that should always be examined. Do the >>>> classes really reflect an "is a" relation or is the difference a >>>> symptom of a bigger difference/problem. >> >>> If that is the case, then the author of the superclass didn't design it >>> properly. Default values are not there to indicate the only valid >>> values for a class. They are there to allow for some (or all) values to >>> be assumed. >>> >>> If there is a restriction in what the values can be, then that needs to >>> be in the appropriate function. Otherwise, there is no restriction. >> >> Yes. But the topic was not valid values but default values. > > That is correct. And while the default values will be valid, if there > are restrictions on non-default values those go in the function. > >>> If the subclass does not reflect an "is-a" relationship, that is a >>> design problem which has nothing to do with default values. >> >> If it is the default values that break the "is a" then it has >> something to do with it. >> > > No, values don't break an is-a relationship. If the default values do, > then you have an invalid relationship in the first place. It is rather simple English. Type X is feature set X with a default value of A. Type Y is a feature set of X + Y with a default value of B. Y "is a" X is false. Y "is almost a" X is true. >>> The bottom line here is - none of your arguments are related to the >>> presence or absence of default arguments. All can occur either with or >>> without default arguments. >> >> My argument relates specifically to different default values, so >> it can not happen without default arguments. > > I stand by my statement. Given that the argument above very clearly relates to "default value" then you are proven wrong. > Default values in a derived class which are > not valid for the base class indicates an invalid relationship in the > first place. Yes. But that is a straw man argument because my reasons do not relate to valid values at all. > I would like to see an example of a valid relationship where your > default values cause a problem. It is obvious that there is a problem with "is a". It could be totally harmless. Or it could be a good indication of a problem. It would be worth investigating what it is. Arne