Timeline for "Imprinting" as a language feature?
Current License: CC BY-SA 3.0
35 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Aug 15, 2022 at 11:31 | comment | added | uliwitness | I don't see how your solution actually improves over multiple inheritance? You say that one issue would be imprinting two classes implementing the same method. Isn't that basically the diamond problem again, just with a compile-time check that some compilers offer for multiple inheritance already? | |
| Jun 28, 2015 at 6:22 | review | Close votes | |||
| Jul 15, 2015 at 3:09 | |||||
| Jun 27, 2015 at 12:01 | history | edited | gnat | CC BY-SA 3.0 |
http://meta.programmers.stackexchange.com/a/7403/31260
|
| Jun 27, 2015 at 11:59 | comment | added | gnat | possible duplicate of How are mixins or traits better than plain multiple inheritance? | |
| Mar 2, 2011 at 16:30 | answer | added | OscarRyz | timeline score: 3 | |
| Mar 2, 2011 at 16:15 | answer | added | phaylon | timeline score: 2 | |
| Mar 2, 2011 at 10:12 | comment | added | Homde | If you implemented the class the ordinary way you would have to implement everything in the interface, then if anything changes your class would break. With this method it will only break if something you directly reference or override changes. | |
| Mar 2, 2011 at 9:03 | comment | added | Matt Ellen |
@MKO: you example would break if List<T>.Count was removed, ok so it's a property not a method, but same difference. I don't get what benefit there would be.
|
|
| Mar 1, 2011 at 22:11 | history | edited | Homde | CC BY-SA 2.5 |
edited body; added 23 characters in body
|
| Mar 1, 2011 at 21:23 | comment | added | Homde | Hi, PeopleList is just an arbitrary alias I assigned to the imprinted class instance to be able to reference it in the class. It's basically the variable name of the imprinted class, ie it can be whatever you want it to be (as long as it doesn't clash with some other field or property). Sorry for the misunderstanding | |
| Mar 1, 2011 at 21:09 | comment | added | David Thornley |
@MKO: You could at least post some code that would have a chance of compiling if there was such a thing as imprinting. You imprint List<People> as PeopleList, say People can now be used as a list, and then arbitrarily toss in a PersonList without attempting to define it. Either you've messed up your example, or imprinting has some magical effect on class names.ing to define it.
|
|
| Mar 1, 2011 at 19:51 | comment | added | Homde | Basically it's composition vs inheritance and avoiding things like the diamond problem (en.wikipedia.org/wiki/Diamond_problem) I'm sorry that I can't describe it clearer for you. | |
| Mar 1, 2011 at 19:47 | comment | added | David Thornley | @Michael: However, the fact that I don't know what the OP is talking about after looking at the question does invalidate it. If you know what he's talking about, please let me know. The fact that it's equivalent to MI, as far as I can tell, doesn't really invalidate the question, but does reduce my tolerance for bad questions. | |
| Mar 1, 2011 at 19:35 | comment | added | Michael K | @David: Equivalence to MI does not invalidate the question. | |
| Mar 1, 2011 at 19:27 | answer | added | kevin cline | timeline score: 9 | |
| Mar 1, 2011 at 19:26 | history | edited | Homde | CC BY-SA 2.5 |
added 41 characters in body
|
| Mar 1, 2011 at 19:15 | comment | added | Homde | But it wouldn't break the class if a method was added, removed or changed signature. It would only break if a method who had a declared override would change. | |
| Mar 1, 2011 at 19:11 | comment | added | Matt Ellen |
Your argument about breaking changes doesn't seem to be countered by your imprinting technique - if IList<T> changed then so would List<T>. A class is just as likely to change as an interface.
|
|
| Mar 1, 2011 at 18:59 | answer | added | blueberryfields | timeline score: 2 | |
| Mar 1, 2011 at 18:58 | comment | added | David Thornley | Having read the sidenote, I still don't know why imprinting is different from multiple inheritance (except that you're prejudiced against MI), what inherent relation People, PeopleList, and PersonList are supposed to have by virtue of their names, why imprinting is supposed to be proof against things changing outside the class, and what benefit complicating the syntax and semantics would have as opposed to simply allowing multiple inheritance. Voting to close as "not a real question". | |
| Mar 1, 2011 at 18:53 | history | edited | Homde | CC BY-SA 2.5 |
added 5 characters in body
|
| Mar 1, 2011 at 18:50 | comment | added | David Thornley | @MKO: Mixins, in the languages I've seen them in, are simply specialized classes that you can inherit (and so work on the basis of multiple inheritance). | |
| Mar 1, 2011 at 18:46 | history | edited | Homde | CC BY-SA 2.5 |
added 24 characters in body
|
| Mar 1, 2011 at 18:43 | comment | added | Homde | Ok, so if I understand Mixins correct the difference here is that you could imprint any class of your choice, not just the ones defined in a module. So in Ruby if you wanted to use some other class's (that might be framework class, thirdparty or your own) method in your class you could do that with imprinting. However a mixin can interact with the class that uses it, while imprinted classes are not even aware of being imprinted. So it's not as flexible but more encapsulated. Also imprints are a way to implement abstract classes and interfaces. | |
| Mar 1, 2011 at 18:35 | history | edited | Homde | CC BY-SA 2.5 |
added 136 characters in body
|
| Mar 1, 2011 at 18:34 | comment | added | mipadi | It sounds a lot like mixins from Ruby (and a few other languages). | |
| Mar 1, 2011 at 18:29 | comment | added | Homde | I'm not really familiar with mixins and traits. I'll check into that | |
| Mar 1, 2011 at 18:26 | history | edited | Homde | CC BY-SA 2.5 |
added 1414 characters in body; added 189 characters in body
|
| Mar 1, 2011 at 18:25 | comment | added | FrustratedWithFormsDesigner | @MKO: To make this more clear, could you give a counter-eaxmple? A situation that could be improved by this potential feature? | |
| Mar 1, 2011 at 18:24 | comment | added | Matt H | What are the benefits of this over mixins/traits? There doesn't seem to be that much of a difference. | |
| Mar 1, 2011 at 18:05 | comment | added | S.Lott | @MKO: For Python users, what's a "virtual call"? This sure sounds like simple multiple inheritance. Please update the question with details as to why this isn't must inheritance. | |
| Mar 1, 2011 at 18:03 | comment | added | Homde | There's no virtual calls with this approach and the imprinter can't call anything on the imprintee, only vice versa. Messing with multiple inheritance is pretty complicated business whereas this is simply encapsulation | |
| Mar 1, 2011 at 17:58 | comment | added | Paul Nathan | How is this different from multiple inheritance? | |
| Mar 1, 2011 at 17:57 | comment | added | David Thornley | Is there any difference between imprinting and inheritance? More specifically, is there any difference besides syntax in what you're proposing and adding real public inheritance to C#? | |
| Mar 1, 2011 at 17:53 | history | asked | Homde | CC BY-SA 2.5 |