Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Andreas Leitgeb Newsgroups: comp.lang.java.programmer Subject: Re: How to assign an object to another in it method? Date: Sat, 15 Jul 2017 14:36:32 -0000 (UTC) Organization: A noiseless patient Spider Lines: 64 Message-ID: References: <46334961-cc18-491f-828c-32e7401c7832@googlegroups.com> Reply-To: avl@logic.at Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Date: Sat, 15 Jul 2017 14:36:32 -0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="a7963ed22582c07699768ad67bf6a961"; logging-data="29610"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/YaE/VMjWtlc3NMTd3zzG0" User-Agent: slrn/1.0.2 (Linux) Cancel-Lock: sha1:06FsRK4ebp7PQkPCne7f/2eiQP4= Xref: csiph.com comp.lang.java.programmer:36949 Arne Vajhøj wrote: > On 7/14/2017 2:40 AM, Andreas Leitgeb wrote: >> Arne Vajhøj wrote: >>> - how do you know that the method is virtual without noticing the >>> default values? >> by letting the override do something observably different, >> as my own example did. > Let me try to explain better what I mean. > A developer is writing some code and has to decide between: > P *o = new C(); > and: > C *o = new C(); This decision should be guided primarily by these thoughts: - will I need to access (class) C-specific methods or attributes? -> then go for "C" for the pointer. - is it likely that o will need to point to a non-C object? (or likely in future by foreseeable further development?) -> then go for "P" for the pointer. This decision shouldn't depend on whether P has non-virtual methods or uses (non-polymorphic) defaults for some method arguments, just because the decision of designing for polymorphism (or not) should depend on how it is meant to be used. If developer finds out they need polymorphic behaviour, they'd better dump the default values, and use a a second (also virtual) method with the simpler signature that will call the other version with a value... struct P { virtual void foo(int i = 42) { ... } } would then (iff needed) just be changed to: struct P { virtual void foo(int i) { ... } virtual void foo() { foo(42); } } and any subclass can decide to overriding the " default " and/or the actual implementation, independently. (Surprise: that's just how you would do it in Java, too, except for the exact syntax.) > The developer wants C behavior for o, which requires polymorphic > behavior for the first option to be viable. If they only needs C behaviour, he'll just pick "C" for pointer's type and be set. If he polymorphically needs C or D behaviour, he had better use classes C and D that are suitably designed for the task. (or just design C and D suitable for the task, themself.) > Non virtual methods are not polymorphic, so the developer need to > check which methods are virtual and which are non virtual. Check... in the documentation (or source) ? I hope you don't mean that they would hack some test program just to see if the method is declared virtual or not, or that they would expect to draw any conclusions based on what value the method ends up seeing. > Is that check possible to do without as a side effect to also > note the default values? You lost me here (or already long before).