digitalmars.D.learn - Simulating sub types
- JS (29/29) Aug 02 2013 Nesting classes is strange to me in Dlang because it adds a
- bearophile (7/8) Aug 02 2013 Is tagging the inner class as static helping?
- Meta (5/13) Aug 02 2013 Just to be clear, marking the inner class as static means that B
- JS (10/27) Aug 02 2013 Then that doesn't help. Do you mean A.B is not visible outside
- Dicebot (4/7) Aug 02 2013 Yes, A will act simply as a "namespace". If B is public, it can
- JS (3/10) Aug 02 2013 ok, then that is exactly what I want.
- Meta (3/10) Aug 02 2013 Sorry to hijack the question, but this is relevant to the OP. I
- Jesse Phillips (2/4) Aug 02 2013 Public by default.
Nesting classes is strange to me in Dlang because it adds a parent pointer to the parent class. I don't see the point of this and it seems like an anti-feature. If we wanting that pattern we could implement it ourselves. I suppose in some cases it can be useful but in my case it breaks logical nesting. I have two classes A and B. I want B to look like it is derived or a member of A. So I want to do A.B when accessing B to explicitly signal that B is from A. e.g., class A { class B { ... BUT I do not want class B to be physically connecting to A. I would like to instantiate it outside of A. I can't do this in Dlang. Regardless of why I want to do this, the fact remains that I can't do it in Dlang. So, the question is, how can I still get the logical behavior? I've tried to put B in a module A, but this doesn't seem to work. In fact, I'm programming from interfaces, interface A { interface B { ... class C : A { class D : A.B { ... So I have for D, analogous to A.B, C.D. D will never be used, I think outside of D, except when inheriting from D to create polymorphic behavior... direct injection will be used along with factories and requiring D to be a physical child of D will just be a pain in the ass(requiring all of C to be implemented I think). Basically, D will never access the parent(they are just wrappers around tight objects. So I don't need the parent pointer, yet I'm forced to do so.
Aug 02 2013
JS:the fact remains that I can't do it in Dlang.Is tagging the inner class as static helping? class A { static class B { ... } } Bye, bearophile
Aug 02 2013
On Friday, 2 August 2013 at 11:47:46 UTC, bearophile wrote:JS:Just to be clear, marking the inner class as static means that B will not have a pointer to A. It is the same as defining B outside A, the difference being that B is not visible to anything outside the module.the fact remains that I can't do it in Dlang.Is tagging the inner class as static helping? class A { static class B { ... } } Bye, bearophile
Aug 02 2013
On Friday, 2 August 2013 at 12:29:02 UTC, Meta wrote:On Friday, 2 August 2013 at 11:47:46 UTC, bearophile wrote:Then that doesn't help. Do you mean A.B is not visible outside the module either? Can B be instantiated and inherited when static, if not then it is no use. To be. clear I want B to behave like any ordinary "root" class(just like A), except I want to have to access it through A(logically). This creates a hierarchical way of accessing types that makes it clear how they are related to other types, but doesn't prevent them from being used in a non-hierarchical way if necessary(The way D deals with nested classes prevents this).JS:Just to be clear, marking the inner class as static means that B will not have a pointer to A. It is the same as defining B outside A, the difference being that B is not visible to anything outside the module.the fact remains that I can't do it in Dlang.Is tagging the inner class as static helping? class A { static class B { ... } } Bye, bearophile
Aug 02 2013
On Friday, 2 August 2013 at 13:37:09 UTC, JS wrote:Then that doesn't help. Do you mean A.B is not visible outside the module either? Can B be instantiated and inherited when static, if not then it is no use.Yes, A will act simply as a "namespace". If B is public, it can be accessed and instantiated from other modules. All static does here is removing hidden context pointer.
Aug 02 2013
On Friday, 2 August 2013 at 13:57:08 UTC, Dicebot wrote:On Friday, 2 August 2013 at 13:37:09 UTC, JS wrote:ok, then that is exactly what I want. Thanks.Then that doesn't help. Do you mean A.B is not visible outside the module either? Can B be instantiated and inherited when static, if not then it is no use.Yes, A will act simply as a "namespace". If B is public, it can be accessed and instantiated from other modules. All static does here is removing hidden context pointer.
Aug 02 2013
On Friday, 2 August 2013 at 13:57:08 UTC, Dicebot wrote:On Friday, 2 August 2013 at 13:37:09 UTC, JS wrote:Sorry to hijack the question, but this is relevant to the OP. I can't remember; are class member public or private by default?Then that doesn't help. Do you mean A.B is not visible outside the module either? Can B be instantiated and inherited when static, if not then it is no use.Yes, A will act simply as a "namespace". If B is public, it can be accessed and instantiated from other modules. All static does here is removing hidden context pointer.
Aug 02 2013
On Friday, 2 August 2013 at 17:16:21 UTC, Meta wrote:Sorry to hijack the question, but this is relevant to the OP. I can't remember; are class member public or private by default?Public by default.
Aug 02 2013