digitalmars.D.learn - abstract base class and class members
- David <d dav1d.de> Mar 04 2012
- Timon Gehr <timon.gehr gmx.ch> Mar 04 2012
- David <d dav1d.de> Mar 04 2012
- David <d dav1d.de> Mar 04 2012
- Timon Gehr <timon.gehr gmx.ch> Mar 04 2012
- "H. S. Teoh" <hsteoh quickfur.ath.cx> Mar 04 2012
- Jonathan M Davis <jmdavisProg gmx.com> Mar 04 2012
- "Jesse Phillips" <jessekphillips+D gmail.com> Mar 05 2012
- "Jonathan M Davis" <jmdavisProg gmx.com> Mar 05 2012
Is this intended behaviour? http://ideone.com/xrvvL shouldn't the 2nd writeln print the same as the first, well at least the same content of i?
Mar 04 2012
On 03/04/2012 06:16 PM, David wrote:Is this intended behaviour? http://ideone.com/xrvvL shouldn't the 2nd writeln print the same as the first, well at least the same content of i?
This is intended behaviour. You have two distinct definitions of i. If you want to set i to 2 in the derived class, do so in the class constructor.
Mar 04 2012
Am 04.03.2012 19:22, schrieb H. S. Teoh:On Sun, Mar 04, 2012 at 06:22:47PM +0100, Timon Gehr wrote:On 03/04/2012 06:16 PM, David wrote:Is this intended behaviour? http://ideone.com/xrvvL shouldn't the 2nd writeln print the same as the first, well at least the same content of i?
This is intended behaviour. You have two distinct definitions of i. If you want to set i to 2 in the derived class, do so in the class constructor.
Yeah, only member functions can be overridden in the derived class (and even then, D requires you to explicitly state that with the 'override' keyword). Makes one wonder, though... from an OO perspective, does it make sense to have overridable non-function members? What semantics would (should) that have? T
Maybe we should also allow override for fields.
Mar 04 2012
Am 04.03.2012 21:24, schrieb Jonathan M Davis:On Sunday, March 04, 2012 19:36:20 David wrote:Am 04.03.2012 19:22, schrieb H. S. Teoh:On Sun, Mar 04, 2012 at 06:22:47PM +0100, Timon Gehr wrote:On 03/04/2012 06:16 PM, David wrote:Is this intended behaviour? http://ideone.com/xrvvL shouldn't the 2nd writeln print the same as the first, well at least the same content of i?
This is intended behaviour. You have two distinct definitions of i. If you want to set i to 2 in the derived class, do so in the class constructor.
Yeah, only member functions can be overridden in the derived class (and even then, D requires you to explicitly state that with the 'override' keyword). Makes one wonder, though... from an OO perspective, does it make sense to have overridable non-function members? What semantics would (should) that have? T
Thanks for your answers. Maybe we should also allow override for fields.
Variables can't be polymorphic, and it wouldn't make sense for them to be. Overidding is done to change behavior. By the way, I wouldn't rely on much that ideone says about D at this point. It's still on version 2.042 of dmd, whereas the latest release is 2.058. - Jonathan M Davis
statically accessable and which you can use to identify the class, I don't like the idea of having an additional functoion ( property) for doing this. I used ideone just to show you, I discovered this on my PC with dmd 2.058
Mar 04 2012
On 03/04/2012 07:22 PM, H. S. Teoh wrote:Makes one wonder, though... from an OO perspective, does it make sense to have overridable non-function members? What semantics would (should) that have?
Yes, it does make sense. const/immutable/(final) fields can be covariant. OTOH, it is not evident that it would be extremely useful.
Mar 04 2012
On Sun, Mar 04, 2012 at 06:22:47PM +0100, Timon Gehr wrote:On 03/04/2012 06:16 PM, David wrote:Is this intended behaviour? http://ideone.com/xrvvL shouldn't the 2nd writeln print the same as the first, well at least the same content of i?
This is intended behaviour. You have two distinct definitions of i. If you want to set i to 2 in the derived class, do so in the class constructor.
Yeah, only member functions can be overridden in the derived class (and even then, D requires you to explicitly state that with the 'override' keyword). Makes one wonder, though... from an OO perspective, does it make sense to have overridable non-function members? What semantics would (should) that have? T -- "Life is all a great joke, but only the brave ever get the point." -- Kenneth Rexroth
Mar 04 2012
On Sunday, March 04, 2012 19:36:20 David wrote:Am 04.03.2012 19:22, schrieb H. S. Teoh:On Sun, Mar 04, 2012 at 06:22:47PM +0100, Timon Gehr wrote:On 03/04/2012 06:16 PM, David wrote:Is this intended behaviour? http://ideone.com/xrvvL shouldn't the 2nd writeln print the same as the first, well at least the same content of i?
This is intended behaviour. You have two distinct definitions of i. If you want to set i to 2 in the derived class, do so in the class constructor.
Yeah, only member functions can be overridden in the derived class (and even then, D requires you to explicitly state that with the 'override' keyword). Makes one wonder, though... from an OO perspective, does it make sense to have overridable non-function members? What semantics would (should) that have? T
Thanks for your answers. Maybe we should also allow override for fields.
Variables can't be polymorphic, and it wouldn't make sense for them to be. Overidding is done to change behavior. By the way, I wouldn't rely on much that ideone says about D at this point. It's still on version 2.042 of dmd, whereas the latest release is 2.058. - Jonathan M Davis
Mar 04 2012
On Sunday, 4 March 2012 at 20:25:40 UTC, Jonathan M Davis wrote:By the way, I wouldn't rely on much that ideone says about D at this point. It's still on version 2.042 of dmd, whereas the latest release is 2.058. - Jonathan M Davis
Then ask for the latest version, and as David pointed out, it is reliable to show behavior when you already have observed it.
Mar 05 2012
On Monday, March 05, 2012 11:32:39 Jesse Phillips wrote:On Sunday, 4 March 2012 at 20:25:40 UTC, Jonathan M Davis wrote:By the way, I wouldn't rely on much that ideone says about D at this point. It's still on version 2.042 of dmd, whereas the latest release is 2.058. - Jonathan M Davis
Then ask for the latest version, and as David pointed out, it is reliable to show behavior when you already have observed it.
I was just pointing out that relying on ideone's behavior is a bad idea, since it's very behind on its version of dmd. I didn't say that what it showed was necessarily wrong. - Jonathan M Davis
Mar 05 2012









David <d dav1d.de> 