| --- Log opened Fri Oct 16 00:00:51 2009 |
| 00:02 | < Rhamphoryncus> | heh, trying to read up on interfaces and it just occurred to me that, if you were really implementation-agnostic, you wouldn't need to say which implementation to use. You could just say x = MyInterface() and it could pick an implementation at random (and different every time!) and it would Just Work |
| 00:03 | <@McMartin> | Well, you'd generally have a reason to pick one version. |
| 00:03 | <@McMartin> | Or the implementation could be relying on statics under the hood (like most Databases would) |
| 00:03 | < Rhamphoryncus> | Right, because you want more than the interface provides |
| 00:04 | < Rhamphoryncus> | If the interface was strict enough that you didn't need to go beyond it then there wouldn't be multiple implementations. There'd be a canonical implementation |
| 00:05 | <@McMartin> | Anyway |
| 00:05 | < Rhamphoryncus> | Maybe subtle variations from version to version, but still the same basic implementation |
| 00:05 | <@McMartin> | Interfaces do about 70% of what Multiple Inheritance is good for, but they're solidly enough defined that they also mean you get to avoid the horrible spiders that lurk within MI |
| 00:06 | < Rhamphoryncus> | I won't argue with that. Python has multiple inheritance, but IMO it's nearly always used in a simple fashion, more like mixins |
| 00:07 | <@McMartin> | Yeah, and Python doesn't try to do it "completely" either |
| 00:08 | < Rhamphoryncus> | But the reason I'm reading up on it is that some people advocate interfaces in python. There's some sort of benefit they think it gives them, but I can't grasp it |
| 00:08 | <@McMartin> | When you have the case where B and C both inherit from A and D inherits from B and C, there's two ways to handle it and both are "demonstrably wrong" |
| 00:08 | < Rhamphoryncus> | aye |
| 00:08 | <@McMartin> | (Which is to say, there's at least one case where it has disastrous results and so you shouldn't be using that kind of inheritance) |
| 00:08 | <@McMartin> | Hmm |
| 00:08 | <@McMartin> | Speaking for myself, Python can benefit from "protocols" |
| 00:09 | <@McMartin> | But they can be safely left implicit |
| 00:10 | < Rhamphoryncus> | My own pokings at python's super() suggest that it should only allow single inheritance, but apply it in a per-method basis. if B overrides X and C overrides Y, then it's fine for D to inherit from both. If they both override X then this is a problem. Note that there's no requirement for compatibility here, B.X can be totally different than A.X |
| 00:10 | < Rhamphoryncus> | Do you mean type checking? Or just documenting methods like .read()? |
| 00:10 | <@McMartin> | The latter |
| 00:11 | <@McMartin> | "This routine takes an object that understands __add__, __index__, and frungy()." |
| 00:11 | < Rhamphoryncus> | Yeah, informal interfaces are very useful |
| 00:11 | <@McMartin> | Python uses "duck typing" and so can get away with it |
| 00:11 | <@McMartin> | "Protocol" is the Objective-C name for that, where they're a bit more formal and you can check against them |
| 00:11 | < Rhamphoryncus> | It's the formalization and enforcement that's questionable, especially given the tendency to allow NotImplementedError for a method |
| 00:13 | <@McMartin> | Yup |
| 00:13 | <@McMartin> | I find that for Python, like ObjC and its ultimate ancestor Smalltalk, it's better to think of method calls as "sending this message to the object, who reacts" |
| 00:14 | < Rhamphoryncus> | Another point often forgotten is that liskov substitution is about behaviour, not just method signatures |
| 00:14 | <@McMartin> | Yeah. That's the key place where Interfaces fall down |
| 00:14 | <@McMartin> | ... and, in fact, why I prefer view classes to multiple inheritance generally |
| 00:15 | < Rhamphoryncus> | And to the degree you're testing for, two compatible implementations should be indistinguishable.. which leads to my earlier point about canonical implementations |
| 00:16 | < Rhamphoryncus> | By elimination that means all the interesting bits are those not restricted by the interface |
| 00:21 | < Rhamphoryncus> | Given a language with duck typing, all an interface needs to do is allow type checks to work. It could otherwise be completely empty |
| 00:22 | <@McMartin> | Right |
| 00:22 | < Rhamphoryncus> | Even that seems like a crude form of adaptation |
| 00:22 | <@McMartin> | The thing that gets nasty is that there's do guarantee that a.clean() does the same thing that b.clean() does |
| 00:22 | <@McMartin> | Like you said, "signatures aren't semantics" |
| 00:23 | < Rhamphoryncus> | yeah |
| 00:25 | < Rhamphoryncus> | files are a great example. .read(), .write(), .seek(), etc should always exist, but may not be implemented, and usually do different things |
| 00:26 | <@McMartin> | Java kind of goes nuts with single-inheritance wrappers to deal with that. |
| 00:26 | < Rhamphoryncus> | Python 3.0 changed all the implementations too, but it's still the same basic interface |
| 00:27 | < Rhamphoryncus> | 2.6 has ABC's for them, which are a bit nuts IMO |
| 00:28 | < Rhamphoryncus> | the funny thing is that StringIO allows unicode, while normally they take only bytes |
| 00:29 | < Rhamphoryncus> | Effectively a retcon of the interface. You need to split WritableFile (or whatever you call it) into ByteWritableFile and UnicodeWritableFile |
| 00:30 | <@McMartin> | Yeah. Java ran into that face first around 1.3 |
| 00:30 | <@McMartin> | (This is the split between InputStream and Reader) |
| 00:30 | < Rhamphoryncus> | But what's the use case? The only ones I've ever seen involve adaptation |
| 00:30 | | * Rhamphoryncus nods |
| 00:30 | <@McMartin> | Sometimes you want to treat a file as full of bytes |
| 00:30 | <@McMartin> | Sometimes you want to treat it as full of characters |
| 00:31 | < Rhamphoryncus> | informal interfaces work fine for that in python |
| 00:32 | < Rhamphoryncus> | Obviously statically typed languages like java are a little more dependent on having an interface, as an alternative to duck typing |
| 00:41 | <@McMartin> | Yaeh |
| 00:41 | <@McMartin> | Yeah |
| 00:43 | < Rhamphoryncus> | on a related note, I'd like to remove inheritance from python. Type checks, mixins, and delegation seem to do nearly all of it |
| 00:44 | < Rhamphoryncus> | Consider subclassing dict. You want to retain most methods, which is delegation. You also want to override a few and have the underlying dict use them, which'd be a mixin |
| 00:46 | < Rhamphoryncus> | If multiple inheritance is bad and single inheritance is good, couldn't no inheritance be even better? ;) |
| 00:47 | | You're now known as TheWatcher[T-2] |
| 00:47 | <@McMartin> | Composition isn't used nearly enough~ |
| 00:48 | < Rhamphoryncus> | I blame liskov |
| 00:48 | < Rhamphoryncus> | People got the idea that when you inherit implementation, it's supposed to be compatible, not just for mixin/delegation |
| 00:51 | < Rhamphoryncus> | People would freak without inheritance though :) |
| 00:52 | < Rhamphoryncus> | And I don't know if I could make the simple cases simple enough with type checks/mixins/delegation |
| 00:54 | | You're now known as TheWatcher[zZzZ] |
| 00:57 | <@McMartin> | There's a C extension called "D" that uses a mixin-focused MI. |
| 02:14 | | * Rhamphoryncus wonders if you need anything more than class decorators for mixins and delegation |
| 02:15 | < Rhamphoryncus> | typechecks too. Just a call to the ABC to register yourself |
| 02:47 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 03:21 | | Attilla [The.Attilla@FBC920.65CFFF.E56E70.387AF5] has quit [[NS] Quit: ] |
| 03:32 | | Reiv [qwebirc@Nightstar-98ee58f1.hfc.comcastbusiness.net] has joined #Code |
| 03:45 | | SmithKurosaki [Smith@Nightstar-04e98d9c.dsl.teksavvy.com] has left #Code ["Leaving"] |
| 04:02 | | Reiv [qwebirc@Nightstar-98ee58f1.hfc.comcastbusiness.net] has quit [Ping timeout: 121 seconds] |
| 04:12 | | Reiv [qwebirc@Nightstar-98ee58f1.hfc.comcastbusiness.net] has joined #Code |
| 05:02 | | Reiv [qwebirc@Nightstar-98ee58f1.hfc.comcastbusiness.net] has quit [Ping timeout: 121 seconds] |
| 05:05 | | Syloqs-AFH [Syloq@is.an.awesome.Network.Administrator.on.Nightstar.Net] has quit [Connection reset by peer] |
| 06:58 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 06:59 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #Code |
| 06:59 | | mode/#code [+o Vornicus] by Reiver |
| 07:18 | | Derakon is now known as Derakon[AFK] |
| 08:41 | | Vornicus is now known as Vornicus-Latens |
| 08:58 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has quit [Client exited] |
| 10:33 | | You're now known as TheWatcher |
| 11:14 | | Attilla [The.Attilla@FBC920.65CFFF.E56E70.387AF5] has joined #Code |
| 11:14 | | mode/#code [+o Attilla] by Reiver |
| 11:21 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #Code |
| 14:04 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Client closed the connection] |
| 14:21 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #Code |
| 14:21 | | mode/#code [+o ToxicFrog] by Reiver |
| 15:38 | | Kazriko [kaz@teela.arkaic.com] has quit [Connection closed] |
| 15:45 | | Kazriko [kaz@teela.arkaic.com] has joined #Code |
| 15:45 | | mode/#code [+o Kazriko] by Reiver |
| 16:05 | | Syloqs_AFH [Syloq@is.an.awesome.Network.Administrator.on.Nightstar.Net] has joined #Code |
| 16:06 | | Syloqs_AFH is now known as Syloqs-AFH |
| 17:03 | | Rhamphoryncus [rhamph@Nightstar-a62bd960.abhsia.telus.net] has joined #Code |
| 18:12 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Gone] |
| 18:30 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #Code |
| 19:12 | <@ToxicFrog> | fuuuuuuuuuuuck SVN |
| 19:32 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Connection closed] |
| 20:23 | <@MyCatVerbs> | ToxicFrog: I didn't know you thought about |
| 20:23 | <@MyCatVerbs> | Er. I didn't know you thought about it that way. |
| 20:24 | <@MyCatVerbs> | I don't think you're the first person I've met to find version control sexy, though. |
| 21:02 | < Rhamphoryncus> | It's a control thing. After being abused, helplessly, by SVN (or any other) you want to strike back at them |
| 22:01 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has joined #Code |
| 22:21 | | Vornicus-Latens is now known as Vornicus |
| 22:39 | < Derakon[work]> | So my boss wants me to investigate possible OSen for the new computer we're getting. |
| 22:39 | < Derakon[work]> | Assumption is that it has to have a Windows install on it. |
| 22:39 | < Derakon[work]> | The two that were recommended to him by the vendor were, he claimed, "Vista 64-bit Windows 7" and "2.08 Windows Server". |
| 22:40 | < Derakon[work]> | I'm guessing that translates to "64-bit Vista", "64-bit Windows 7", and "Windows Server 2008". Any differing interpretations? |
| 22:56 | <@Vornicus> | Nope. |
| 23:16 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: ] |
| 23:17 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #Code |
| 23:17 | | mode/#code [+o Vornicus] by Reiver |
| 23:17 | | * Derakon[work] submits his OS review to his boss. |
| 23:18 | < Derakon[work]> | It reads, in short, "Yeah, all these OSes could do what we need, but why not stick with XP? We know that works." |
| 23:34 | | Derakon[work] [Derakon@Nightstar-d44d635e.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 23:40 | | You're now known as TheWatcher[T-2] |
| 23:42 | <@McMartin> | Vista is already obsolete and should not be selected; 64-bit XP is flakier than the others; If you have the spare funding one might as well see if you're going to have upgrade troubles later. |
| 23:42 | <@McMartin> | Other than that, yeah. |
| 23:42 | <@Vornicus> | Win7 is coming out, what, next week? |
| 23:43 | <@McMartin> | Yes, and most sales of Vista are actually "Vista + coupon for free Win7 upgrade" sold at Win7 prices~ |
| 23:44 | <@Vornicus> | So it's either xp or 7, really. |
| 23:44 | | You're now known as TheWatcher[zZzZ] |
| --- Log closed Sat Oct 17 00:00:05 2009 |