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

Groups > comp.lang.java.programmer > #36669 > unrolled thread

How to assign an object to another in it method?

Back to article view | Back to comp.lang.java.programmer

Contents

  How to assign an object to another in it method? parmenides <xparmenides@yahoo.com> - 2017-06-18 20:02 +0800
    Re: How to assign an object to another in it method? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-18 08:09 -0400
    Re: How to assign an object to another in it method? Robert Klemme <shortcutter@googlemail.com> - 2017-06-18 15:31 +0200
    Re: How to assign an object to another in it method? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-19 10:22 -0400
      Re: How to assign an object to another in it method? Eric Douglas <e.d.programmer@gmail.com> - 2017-06-19 08:13 -0700
        Re: How to assign an object to another in it method? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-19 11:53 -0400
          Re: How to assign an object to another in it method? Eric Douglas <e.d.programmer@gmail.com> - 2017-06-19 09:06 -0700
            Re: How to assign an object to another in it method? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-19 13:56 -0400
        Re: How to assign an object to another in it method? lewbloch@gmail.com - 2017-06-27 13:49 -0700
          Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-06-28 12:20 +0000
            Re: How to assign an object to another in it method? Eric Douglas <e.d.programmer@gmail.com> - 2017-06-28 05:51 -0700
              Re: How to assign an object to another in it method? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-06-28 14:03 -0400
              Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-02 21:23 -0400
                Re: How to assign an object to another in it method? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-03 10:59 +0000
                  Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-03 08:38 -0400
                    Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-03 14:04 +0000
                      Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-03 10:39 -0400
                        Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-03 16:28 +0000
                          Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-03 16:52 -0400
                      Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-03 22:04 -0400
                        Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-03 23:15 -0400
                          Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-04 21:46 -0400
                            Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-04 22:18 -0400
                              Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-08 21:13 -0400
                                Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-08 22:12 -0400
                                  Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-11 17:56 +0000
                                    Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-11 15:40 -0400
                                      Re: How to assign an object to another in it method? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-11 13:49 -0700
                                        Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-11 17:41 -0400
                                      Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 20:27 -0400
                                        Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-11 21:43 -0400
                                          Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 21:49 -0400
                                            Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-12 17:20 -0400
                                              Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-13 10:08 +0000
                                                Re: How to assign an object to another in it method? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-13 11:35 +0000
                                                  Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 08:14 -0400
                                                    Re: How to assign an object to another in it method? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-13 14:29 +0000
                                                      Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 13:47 -0400
                                                        Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-13 18:09 +0000
                                                          Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 15:01 -0400
                                                            Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-13 19:19 +0000
                                                              Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 15:39 -0400
                                                  Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-13 16:49 +0000
                                                Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-13 10:24 -0400
                                                  Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-13 17:19 +0000
                                                    Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-13 21:17 -0400
                                                      Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-14 06:40 +0000
                                                        Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-14 14:26 -0400
                                                          Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-15 14:36 +0000
                                                    Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-14 12:10 -0400
                                                      Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-14 14:40 -0400
                                                        Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-14 14:51 -0400
                                                          Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-14 21:05 -0400
                                                        Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-14 21:06 -0400
                                            Re: How to assign an object to another in it method? lewbloch@gmail.com - 2017-07-14 14:44 -0700
                                          Re: How to assign an object to another in it method? Andreas Leitgeb <avl@logic.at> - 2017-07-12 16:23 +0000
                                            Re: How to assign an object to another in it method? Eric Douglas <e.d.programmer@gmail.com> - 2017-07-12 10:12 -0700
                                  Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 20:16 -0400
                                    Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-11 21:46 -0400
                                      Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 21:52 -0400
                                  Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 20:24 -0400
                                    Re: How to assign an object to another in it method? Jerry Stuckle <jstucklex@attglobal.net> - 2017-07-11 21:49 -0400
                                      Re: How to assign an object to another in it method? Arne Vajhøj <arne@vajhoej.dk> - 2017-07-11 21:55 -0400
                  Re: How to assign an object to another in it method? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-03 12:37 +0000
                    Re: How to assign an object to another in it method? Eric Sosman <esosman@comcast-dot-net.invalid> - 2017-07-03 11:34 -0400
                      Re: How to assign an object to another in it method? Martin Gregorie <martin@address-in-sig.invalid> - 2017-07-03 17:28 +0000
    Re: How to assign an object to another in it method? v_borchert@despammed.com (Volker Borchert) - 2017-06-19 17:13 +0000
    Re: How to assign an object to another in it method? Eric Douglas <e.d.programmer@gmail.com> - 2017-06-19 13:40 -0700

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#36803

On 7/3/2017 10:04 PM, Arne Vajhøj wrote:
> On 7/3/2017 10:04 AM, Andreas Leitgeb wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> That is what I consider the missing default parameter issue.
>>>        // **** NOT JAVA ****
>>>        public Demo(String name, int answer = 6, boolean prisoner =
>>> false)
>>
>> Imho this is one thing that Java actually got right, by *not* supporting.
>>
>> In C++, default values can give a hard time when overiding methods with
>> defaults, as the default value depends on the static target object
>> type even for virtual methods.
> 
> Yes.
> 
> But is that really a problem?
> 
> It seems like what one would expect.
> 
> And changing the default value when overriding should be
> documented rather well as it is a somewhat suspicious
> thing to do.
> 
> I hope that a static code analysis tool create warnings
> about doing something like that.
> 
> Arne
> 

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.

If there are other restrictions on the value(s), they need to be checked
in the appropriate function - not depend on default values.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36804

On 7/3/2017 11:15 PM, Jerry Stuckle wrote:
> On 7/3/2017 10:04 PM, Arne Vajhøj wrote:
>> On 7/3/2017 10:04 AM, Andreas Leitgeb wrote:
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> That is what I consider the missing default parameter issue.
>>>>         // **** NOT JAVA ****
>>>>         public Demo(String name, int answer = 6, boolean prisoner =
>>>> false)
>>>
>>> Imho this is one thing that Java actually got right, by *not* supporting.
>>>
>>> In C++, default values can give a hard time when overiding methods with
>>> defaults, as the default value depends on the static target object
>>> type even for virtual methods.
>>
>> Yes.
>>
>> But is that really a problem?
>>
>> It seems like what one would expect.
>>
>> And changing the default value when overriding should be
>> documented rather well as it is a somewhat suspicious
>> thing to do.
>>
>> 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.

On top of that comes the problem Andrea brought up where change
to variable type can change behavior due to default values
being non-polymorphic in nature.

But I am more concerned about the first issue. As the second
issue would be the same for a non-virtual method without default
values.

Arne

[toc] | [prev] | [next] | [standalone]

#36805

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:
>>> On 7/3/2017 10:04 AM, Andreas Leitgeb wrote:
>>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>>> That is what I consider the missing default parameter issue.
>>>>>         // **** NOT JAVA ****
>>>>>         public Demo(String name, int answer = 6, boolean prisoner =
>>>>> false)
>>>>
>>>> Imho this is one thing that Java actually got right, by *not*
>>>> supporting.
>>>>
>>>> In C++, default values can give a hard time when overiding methods with
>>>> defaults, as the default value depends on the static target object
>>>> type even for virtual methods.
>>>
>>> Yes.
>>>
>>> But is that really a problem?
>>>
>>> It seems like what one would expect.
>>>
>>> And changing the default value when overriding should be
>>> documented rather well as it is a somewhat suspicious
>>> thing to do.
>>>
>>> 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.
> 
> On top of that comes the problem Andrea brought up where change
> to variable type can change behavior due to default values
> being non-polymorphic in nature.
> 
> But I am more concerned about the first issue. As the second
> issue would be the same for a non-virtual method without default
> values.
> 
> Arne
> 
> 
> 

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.

If the subclass does not reflect an "is-a" relationship, that is a
design problem which has nothing to do with default values.  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?

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.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#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

[toc] | [prev] | [next] | [standalone]

#36842

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.

>>                                                                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.
> 

Not at all.  One of the purposes of a derived class might be to limit
the base class, for instance.  Take the relationships

Person -> Employee -> Manager

Manager is much more restrictive than Employee, which in turn is much
more restrictive than person.

> Adding missing behavior or adding behavior is what derived classes
> are supposed to do.
> 

That may be *one* of the things a derived class can do.  But one must be
careful - adding a behavior which is not normal to the base class
generally indicates an invalid relationship.

>> 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
> 
> 

I stand by my statement.  Default values in a derived class which are
not valid for the base class indicates an invalid relationship in the
first place.

I would like to see an example of a valid relationship where your
default values cause a problem.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36847

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> Default values in a derived class which are not valid for the base class
> indicates an invalid relationship in the first place.

That's correct, but not relevant.

It's not about whether one of the class's default would be "valid"
for the other, but instead, that the subclass's default value might
just be a better fit than the superclass's one, and that shouldn't
depend on the compile-time type of the reference (or pointer)...


In the example of employee and manager, the manager might just have
a different "default" wage:

   Manager *mgr = new Manager();
   mgr->setWage( /* uses Manager's default wage */ );
   Employee *emp = mgr;
   emp->setWage( /* uses Employee's default wage */ );

[toc] | [prev] | [next] | [standalone]

#36848

On 7/11/2017 1:56 PM, Andreas Leitgeb wrote:
> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>> Default values in a derived class which are not valid for the base class
>> indicates an invalid relationship in the first place.
> 
> That's correct, but not relevant.
>

Arne is attempting to make it relevant.

> It's not about whether one of the class's default would be "valid"
> for the other, but instead, that the subclass's default value might
> just be a better fit than the superclass's one, and that shouldn't
> depend on the compile-time type of the reference (or pointer)...
> 
> 
> In the example of employee and manager, the manager might just have
> a different "default" wage:
> 
>    Manager *mgr = new Manager();
>    mgr->setWage( /* uses Manager's default wage */ );
>    Employee *emp = mgr;
>    emp->setWage( /* uses Employee's default wage */ );
> 

Sure.  But that doesn't make the wave in Employee invalid, like Arne
claims it might.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36849

On Tuesday, July 11, 2017 at 3:40:12 PM UTC-4, Jerry Stuckle wrote:
> Sure.  But that doesn't make the wave in Employee invalid, like Arne
> claims it might.
> 

I'm not sure what this discussion is about validation.  If you allow your class to be sub-classed with a parameter you have to validate it.

public class Employee {
  public Employee() {
    this(getMinimumWage()); // static process
  }
  public Employee(BigDecimal wage) {
    // wage must be >= minimum
  }
}
public class Manager extends Employee {
  public Manager() {
    super(2); // crash
  }
}

[toc] | [prev] | [next] | [standalone]

#36850

On 7/11/2017 4:49 PM, Eric Douglas wrote:
> On Tuesday, July 11, 2017 at 3:40:12 PM UTC-4, Jerry Stuckle wrote:
>> Sure.  But that doesn't make the wave in Employee invalid, like Arne
>> claims it might.
>>
> 
> I'm not sure what this discussion is about validation.  If you allow your class to be sub-classed with a parameter you have to validate it.
> 
> public class Employee {
>   public Employee() {
>     this(getMinimumWage()); // static process
>   }
>   public Employee(BigDecimal wage) {
>     // wage must be >= minimum
>   }
> }
> public class Manager extends Employee {
>   public Manager() {
>     super(2); // crash
>   }
> }
> 

Yes, and it is the responsibility of the superclass to define the values
legal to it.

However, if the Employee class requires a minimum wage, then all
subclasses must also require at least that same wage.  In this case,
Manager would not, so Manager would not have an "is-a" relationship with
Employee.

One alternative would be to have an abstract class Employee.  Derive
from that HourlyEmployee and Manager.  HourlyEmployee would have a
minimum wage, Manager would not (or would at least have a different
minimum wage).

When building a class hierarchy, the restrictions on class members are
important - and have to be considered.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36853

On 7/11/2017 3:40 PM, Jerry Stuckle wrote:
> On 7/11/2017 1:56 PM, Andreas Leitgeb wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>> Default values in a derived class which are not valid for the base class
>>> indicates an invalid relationship in the first place.
>>
>> That's correct, but not relevant.
> 
> Arne is attempting to make it relevant.

No.

I did not bring valid values up.

You brought that up.

>> It's not about whether one of the class's default would be "valid"
>> for the other, but instead, that the subclass's default value might
>> just be a better fit than the superclass's one, and that shouldn't
>> depend on the compile-time type of the reference (or pointer)...
>>
>>
>> In the example of employee and manager, the manager might just have
>> a different "default" wage:
>>
>>     Manager *mgr = new Manager();
>>     mgr->setWage( /* uses Manager's default wage */ );
>>     Employee *emp = mgr;
>>     emp->setWage( /* uses Employee's default wage */ );
>>
> 
> Sure.  But that doesn't make the wave in Employee invalid, like Arne
> claims it might.

In the strictest sense of "is a" it does.

Manager does not have the setWage that Employee has.

Arne

[toc] | [prev] | [next] | [standalone]

#36855

On 7/11/2017 8:27 PM, Arne Vajhøj wrote:
> On 7/11/2017 3:40 PM, Jerry Stuckle wrote:
>> On 7/11/2017 1:56 PM, Andreas Leitgeb wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>> Default values in a derived class which are not valid for the base
>>>> class
>>>> indicates an invalid relationship in the first place.
>>>
>>> That's correct, but not relevant.
>>
>> Arne is attempting to make it relevant.
> 
> No.
> 
> I did not bring valid values up.
> 
> You brought that up.
>

Nope, I never said anything about values until you brought it up, Arne.
Look back at the thread.

>>> It's not about whether one of the class's default would be "valid"
>>> for the other, but instead, that the subclass's default value might
>>> just be a better fit than the superclass's one, and that shouldn't
>>> depend on the compile-time type of the reference (or pointer)...
>>>
>>>
>>> In the example of employee and manager, the manager might just have
>>> a different "default" wage:
>>>
>>>     Manager *mgr = new Manager();
>>>     mgr->setWage( /* uses Manager's default wage */ );
>>>     Employee *emp = mgr;
>>>     emp->setWage( /* uses Employee's default wage */ );
>>>
>>
>> Sure.  But that doesn't make the wave in Employee invalid, like Arne
>> claims it might.
> 
> In the strictest sense of "is a" it does.
> 
> Manager does not have the setWage that Employee has.
> 
> Arne
> 
> 

Nope.  In the strictest sense is is NOT a valid derived class.  The
rules given for Employee were that wage must be >= minimum wage.  The
rules for Manager do not include that restriction.  Therefore it is an
invalid inheritance - no matter what you name them.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36858

On 7/11/2017 9:43 PM, Jerry Stuckle wrote:
> On 7/11/2017 8:27 PM, Arne Vajhøj wrote:
>> On 7/11/2017 3:40 PM, Jerry Stuckle wrote:
>>> On 7/11/2017 1:56 PM, Andreas Leitgeb wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>>> Default values in a derived class which are not valid for the base
>>>>> class
>>>>> indicates an invalid relationship in the first place.
>>>>
>>>> That's correct, but not relevant.
>>>
>>> Arne is attempting to make it relevant.
>>
>> No.
>>
>> I did not bring valid values up.
>>
>> You brought that up.
>>
> 
> Nope, I never said anything about values until you brought it up, Arne.
> Look back at the thread.

I think you should take you own advice.

I wrote:

#And changing the default value when overriding should be
#documented rather well as it is a somewhat suspicious
#thing to do.
#
#I hope that a static code analysis tool create warnings
#about doing something like that.

You replied:

#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.
#
#If there are other restrictions on the value(s), they need to be checked
#in the appropriate function - not depend on default values.

My post does not contain "valid values".

Your post containa "valid values".

Arne

[toc] | [prev] | [next] | [standalone]

#36871

On 7/11/2017 9:49 PM, Arne Vajhøj wrote:
> On 7/11/2017 9:43 PM, Jerry Stuckle wrote:
>> On 7/11/2017 8:27 PM, Arne Vajhøj wrote:
>>> On 7/11/2017 3:40 PM, Jerry Stuckle wrote:
>>>> On 7/11/2017 1:56 PM, Andreas Leitgeb wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> wrote:
>>>>>> Default values in a derived class which are not valid for the base
>>>>>> class
>>>>>> indicates an invalid relationship in the first place.
>>>>>
>>>>> That's correct, but not relevant.
>>>>
>>>> Arne is attempting to make it relevant.
>>>
>>> No.
>>>
>>> I did not bring valid values up.
>>>
>>> You brought that up.
>>>
>>
>> Nope, I never said anything about values until you brought it up, Arne.
>> Look back at the thread.
> 
> I think you should take you own advice.
> 
> I wrote:
> 
> #And changing the default value when overriding should be
> #documented rather well as it is a somewhat suspicious
> #thing to do.
> #
> #I hope that a static code analysis tool create warnings
> #about doing something like that.
> 
> You replied:
> 
> #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.
> #
> #If there are other restrictions on the value(s), they need to be checked
> #in the appropriate function - not depend on default values.
> 
> My post does not contain "valid values".
> 
> Your post containa "valid values".
> 
> Arne

Sorry, you are correct.  It was Andreas who brought up the default
values.  My mistake - I didn't read closely enough.



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#36877

Jerry Stuckle <jstucklex@attglobal.net> wrote:
> On 7/11/2017 9:49 PM, Arne Vajhøj wrote:
>> My post does not contain "valid values".
>> Your post containa "valid values".
> Sorry, you are correct.  It was Andreas who brought up the default
> values.  My mistake - I didn't read closely enough.

The sub-topic of "default values" was what triggered me into entering 
the discussion.  I brought up the problem(imho) of overriding methods with
changed default values for arguments, which in C++ are static type matter
(non-polymorphic).

Apparently this triggered someone else to think that if I even want to 
use a different default value in the override, then "obviously" the
original would necessarily be inappropriate or "invalid" for the subclass.

I think that's how validity entered this thread.

PS: my Manager/Employee adaption did not yet have a minimumWage constraint.
  If it had one, then Manager would probably have a "more constraining" one.
  I.e.: his minimum wage would be even higher. (Assuming that the Manager
  is still an Employee, too, and not already the owner of the company.)

Going back to Java and the Rectangle/Square example: What would be
Square's appropriate way to deal with the setDimensions(int height,int width)
inherited from Rectangle?  Apparently it would need to still offer it and
thus introduce a new potential for runtime-errors with currently no way to
have already the compiler warn about "square.setDimensions(1,2)" being fishy.

Ideally, a subclass should be allowed to "remove" methods in a way that the
compiler could preempt some mistakes: "If you already know you're dealing
with a Square, then rather use Square's setDimension(int length) instead of
the inherited setDimension(int,int)".  Obviously the compiler couldn't catch
cases like ((Rectangle)square).setDimensions(1,2), so not all runtime
errors can be prevented at compile time, but at least some.

[toc] | [prev] | [next] | [standalone]

#36881

On Thu, 13 Jul 2017 10:08:52 +0000, Andreas Leitgeb wrote:

> Ideally, a subclass should be allowed to "remove" methods in a way that
> the compiler could preempt some mistakes: "If you already know you're
> dealing with a Square, then rather use Square's setDimension(int length)
> instead of the inherited setDimension(int,int)".  Obviously the compiler
> couldn't catch cases like ((Rectangle)square).setDimensions(1,2), so not
> all runtime errors can be prevented at compile time, but at least some.
>
In this case why wouldn't you override Rectangle.setDimensions() with a 
variant that throws an exception if the two dimensions differ as well as 
adding the trivial method:

  public void setDimensions(int size)
  {
    super.setDimensions(size, size);
  }

for convenience?


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36883

On 7/13/2017 7:35 AM, Martin Gregorie wrote:
> On Thu, 13 Jul 2017 10:08:52 +0000, Andreas Leitgeb wrote:
>> Ideally, a subclass should be allowed to "remove" methods in a way that
>> the compiler could preempt some mistakes: "If you already know you're
>> dealing with a Square, then rather use Square's setDimension(int length)
>> instead of the inherited setDimension(int,int)".  Obviously the compiler
>> couldn't catch cases like ((Rectangle)square).setDimensions(1,2), so not
>> all runtime errors can be prevented at compile time, but at least some.
>>
> In this case why wouldn't you override Rectangle.setDimensions() with a
> variant that throws an exception if the two dimensions differ as well as
> adding the trivial method:
> 
>    public void setDimensions(int size)
>    {
>      super.setDimensions(size, size);
>    }
> 
> for convenience?

I don't think inheritance is good in cases like this.

It violates "is a", LSP etc..

I believe inheritance should be used conservatively - if any doubt then 
don't.

Arne

[toc] | [prev] | [next] | [standalone]

#36894

On Thu, 13 Jul 2017 08:14:32 -0400, Arne Vajhøj wrote:

> On 7/13/2017 7:35 AM, Martin Gregorie wrote:
>> On Thu, 13 Jul 2017 10:08:52 +0000, Andreas Leitgeb wrote:
>>> Ideally, a subclass should be allowed to "remove" methods in a way
>>> that the compiler could preempt some mistakes: "If you already know
>>> you're dealing with a Square, then rather use Square's
>>> setDimension(int length)
>>> instead of the inherited setDimension(int,int)".  Obviously the
>>> compiler couldn't catch cases like
>>> ((Rectangle)square).setDimensions(1,2), so not all runtime errors can
>>> be prevented at compile time, but at least some.
>>>
>> In this case why wouldn't you override Rectangle.setDimensions() with a
>> variant that throws an exception if the two dimensions differ as well
>> as adding the trivial method:
>> 
>>    public void setDimensions(int size)
>>    {
>>      super.setDimensions(size, size);
>>    }
>> 
>> for convenience?
> 
> I don't think inheritance is good in cases like this.
> 
> It violates "is a", LSP etc..
> 
> I believe inheritance should be used conservatively - if any doubt then
> don't.
>
Are you objecting to my suggested override, the additional single 
parameter method or both? 

I can see why you might object to the new method on the stated grounds, 
not why the (rather clunky) override would be a bad idea.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#36903

On 7/13/2017 10:29 AM, Martin Gregorie wrote:
> On Thu, 13 Jul 2017 08:14:32 -0400, Arne Vajhøj wrote:
>> On 7/13/2017 7:35 AM, Martin Gregorie wrote:
>>> On Thu, 13 Jul 2017 10:08:52 +0000, Andreas Leitgeb wrote:
>>>> Ideally, a subclass should be allowed to "remove" methods in a way
>>>> that the compiler could preempt some mistakes: "If you already know
>>>> you're dealing with a Square, then rather use Square's
>>>> setDimension(int length)
>>>> instead of the inherited setDimension(int,int)".  Obviously the
>>>> compiler couldn't catch cases like
>>>> ((Rectangle)square).setDimensions(1,2), so not all runtime errors can
>>>> be prevented at compile time, but at least some.
>>>>
>>> In this case why wouldn't you override Rectangle.setDimensions() with a
>>> variant that throws an exception if the two dimensions differ as well
>>> as adding the trivial method:
>>>
>>>     public void setDimensions(int size)
>>>     {
>>>       super.setDimensions(size, size);
>>>     }
>>>
>>> for convenience?
>>
>> I don't think inheritance is good in cases like this.
>>
>> It violates "is a", LSP etc..
>>
>> I believe inheritance should be used conservatively - if any doubt then
>> don't.
>
> Are you objecting to my suggested override, the additional single
> parameter method or both?
> 
> I can see why you might object to the new method on the stated grounds,
> not why the (rather clunky) override would be a bad idea.

I am objecting two these two:

 >>>> Ideally, a subclass should be allowed to "remove" methods

 >>> In this case why wouldn't you override Rectangle.setDimensions() with a
 >>> variant that throws an exception if the two dimensions differ

Sub classes should not remove functionality.

Because of "is a" and LSP.

Arne

[toc] | [prev] | [next] | [standalone]

#36907

Arne Vajhøj <arne@vajhoej.dk> wrote:
> I am objecting two these two:
> >>>> Ideally, a subclass should be allowed to "remove" methods
> >>> In this case why wouldn't you override Rectangle.setDimensions() with a
> >>> variant that throws an exception if the two dimensions differ
> Sub classes should not remove functionality.

Maybe there's still some confusion about what "removing" means here.

An IntelligentPerson doesn't smoke(), so its class might
"remove" the smoke() method.

But if an IntelligentPerson is required to do undercover
investigations, it might eventually disguise itself as a 
SimplePerson and in that situation it might even smoke()
to mimic the target milieu.  (It might have a special
dummy implementation of smoke(), though, for that matter.)

[toc] | [prev] | [next] | [standalone]

#36911

On 7/13/2017 2:09 PM, Andreas Leitgeb wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> I am objecting two these two:
>>>>>> Ideally, a subclass should be allowed to "remove" methods
>>>>> In this case why wouldn't you override Rectangle.setDimensions() with a
>>>>> variant that throws an exception if the two dimensions differ
>> Sub classes should not remove functionality.
> 
> Maybe there's still some confusion about what "removing" means here.

I consider overriding a method and unconditionally throw an
exception toe be removing.

> An IntelligentPerson doesn't smoke(), so its class might
> "remove" the smoke() method.

Maybe Person should not have had a smoke methods in the first place
since all persons do not smoke.

Arne

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web