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: Sat, 8 Jul 2017 21:13:39 -0400 Organization: Aioe.org NNTP Server Lines: 55 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:36841 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. > 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. > And yes, > the derived class can change the behavior of the base class - either > with or without default values. But then that is part of the reason for > having a derived class, is it not? Actually not. Changing behavior is a very suspicious activity for a sub class. Adding missing behavior or adding behavior is what derived classes are supposed to do. > 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. Arne