digitalmars.D.bugs - [Issue 1835] New: typeof(this) should return the type of object or some other typeof() is needed
- d-bugmail puremagic.com (44/44) Feb 14 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (25/25) Feb 14 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (28/28) Feb 14 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (13/13) Feb 14 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (7/7) Feb 14 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (10/10) Aug 20 2008 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (11/11) Jul 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (26/26) Jul 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1835
- d-bugmail puremagic.com (22/22) Jul 24 2010 http://d.puremagic.com/issues/show_bug.cgi?id=1835
http://d.puremagic.com/issues/show_bug.cgi?id=1835 Summary: typeof(this) should return the type of object or some other typeof() is needed Product: D Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: bugzilla digitalmars.com ReportedBy: onlystupidspamhere yahoo.se Consider the following code: class A { A foo() { return this; } } class B : A { B bar() { return this; } } void main() { auto b = new B; b.foo().bar(); // We would like to chain methods like this } Currently this is not possible without CRTP (fugly) / mixins (not a good idea) / casts (yucky). Also typeof(this) returns A in class A.. Why can't we allow this: class A { typeof(this) foo() { return this; } // here the return type would depend on the actual runtime type of the object } class B : A { B bar() { return this; } } void main() { auto b = new B; b.foo().bar(); // We would like to chain methods like this } Similar problems occur with common graph data structures. E.g. if we have nodes and edges and inherit from both of them. Now going from SubNode to SubNode won't be possible without the tricks mentioned above because of the type system. This is a very useful feature, see Scala language docs for more info. --
Feb 14 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1835 This proposal has a lot of merit. A better example than chaining is the clone function: class Root { abstract typeof(this) clone(); ... } If such a function were defined, then all derived classes would be required to implement it (which is a Good Thing) and would also be forced to return the same static type as themselves (which again is a Good Thing). Unfortunately, this does not port nicely to functions that accept an equivariant parameter, such as opCmp and opEquals: class Root { int opCmp(typeof(this) another); int opEquals(typeof(this) another); ... } The intent is to have the comparison operations accept the same type as the actual static type of the object. But such a signature cannot be checked statically - a runtime check would have to be inserted. Nonetheless, I'll bring it up with Walter. --
Feb 14 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1835 Well, I requested it already before... Unfortunately without much luck: 1. http://www.digitalmars.com/d/archives/digitalmars/D/Covariance_fix_was_Idea_Lazy_upcasting_51296.html 2. http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=51201 It's also mentioned in previous bugzilla reports: 1. http://d.puremagic.com/issues/show_bug.cgi?id=323 2. http://d.puremagic.com/issues/show_bug.cgi?id=1120 The problem solution seems to have even its name: anchored types. ---------------- Additionally in current design you have to overwrite every, even simple setter/getter method in every derived class. e.g. class A { typeof(this) setX(int x) { this.x = x; } int x; } class B { void test() {} } When I don't want to redefine setX() in B, below also should work: B b = new B; b.setX(5).test; --
Feb 14 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1835 ... B derives after A of course: class A { typeof(this) setX(int x) { this.x = x; } int x; } class B : A { void test() {} } --
Feb 14 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1835 I understand. Now the problem is that this is a feature of rather modest utility, while Walter has many much bigger rocks to move right now. I'll bring it un nonetheless. Andrei --
Feb 14 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1835 matti.niemenmaa+dbugzilla iki.fi changed: What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|2295 | nThis| | CC| |fawzi gmx.ch ------- *** Bug 2295 has been marked as a duplicate of this bug. *** --
Aug 20 2008
http://d.puremagic.com/issues/show_bug.cgi?id=1835 Simen Kjaeraas <simen.kjaras gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simen.kjaras gmail.com PDT --- With template this parameters[1], shouldn't this bug be closed? [1]: http://www.digitalmars.com/d/2.0/template.html#TemplateThisParameter -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1835 Christian Kamm <kamm-removethis incasoftware.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kamm-removethis incasoftwar | |e.de Resolution| |FIXED 09:15:23 PDT --- Yes, it looks like template this parameters cover this use case. You can even express the contract of a clone function nicely: class B { T clone(this T)() { return (cast(T)this).cloneImpl(); } B cloneImpl() { return new B; } } class D { override D cloneImpl() { return new D; } } If the user forgets to provide cloneImpl or doesn't make it return the correct type, the compiler will complain. At least as long as clone!(D) gets instantiated somewhere. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 24 2010
http://d.puremagic.com/issues/show_bug.cgi?id=1835 Yes indeed and Christian showed this templates argument allows one workaround to achieve this (a wrapper object is another). {{{ class A { void a(...){ ... } T aChain(this T)() { a(); return cast(T)this; } } class B { void a(...){ ... } } }}} it might even be cleaner to have also a non chainable version, the return this is really a convenience, and not strictly part of the operation itself, even if it implies some duplication. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jul 24 2010