[00:03:50] ** hazmat has joined us [00:22:25] ** hazmat has left IRC (Read error: 60 (Operation timed out)) [04:02:27] [connected at Thu Nov 11 04:02:27 2004] [04:02:28] <> *** Looking up your hostname... [04:02:28] <> *** Checking ident [04:02:28] <> *** Found your hostname [04:03:03] <> *** No identd (auth) response [04:03:03] <> *** Your host is saberhagen.freenode.net[saberhagen.freenode.net/6667], running version dancer-ircd-1.0.35 [04:03:04] [I have joined #peak] [04:03:04] ** saberhagen.freenode.net set the topic to http://dirtsimple.org/2004/11/generic-functions-have-landed.html [04:49:49] ** vlado has joined us [08:40:39] ** gbay has joined us [09:42:39] ** vlado has left IRC (Read error: 110 (Connection timed out)) [09:53:00] ** vlado has joined us [09:58:09] does anyone know, are sticky adapters weak ? [10:03:54] you mean, weakrefs? I've no clue :) [10:05:06] yes [10:22:20] can i change object's parent component on the fly ? [10:22:34] I believe so. [10:22:43] There's certainly a method for setting it. [10:22:57] hm seems like i can't [10:23:05] What happens? [10:23:48] ah [10:24:09] i can, if nobody has read it yet [10:25:03] >>> from peak.api import binding,config [10:25:03] >>> o=C() [10:25:03] >>> o.setParentComponent(config.makeRoot()) [10:25:03] >>> o=C() [10:25:04] >>> o.getParentComponent() [10:25:06] >>> o.setParentComponent(config.makeRoot()) [10:25:08] Traceback (most recent call last): [10:25:10] File "", line 1, in ? [10:25:12] File "/usr/lib/python2.3/site-packages/peak/binding/components.py", line 854, in setParentComponent [10:25:14] raise AlreadyRead( [10:25:19] Given the immutable nature of configuration objects, that makes sense. [10:25:20] peak.util.EigenData.AlreadyRead: Component <__main__.C object at 0xb79fcfac> already has parent None; tried to set [10:25:27] So, you can't change it on the fly. [10:49:57] Blast. I have to reboot to windows to help out a client. [10:50:00] ** rdmurray has left IRC ("User disconnected") [12:08:07] ** vlado has left IRC ("Leaving") [12:34:39] ** hazmat has joined us [12:50:49] ** hazmat has left IRC ("Leaving") [12:52:26] ** hazmat has joined us [13:34:41] ** hazmat has left IRC ("Leaving") [14:05:16] ** Chad has joined us [14:11:11] ** Chad has left IRC () [14:12:03] ** abditus has joined us [14:30:21] ** rdmurray has joined us [15:21:38] ** pje has joined us [15:21:41] Hola. [15:53:02] 'lo [15:53:46] * pje nods, half-asleep [15:54:04] heh. Me too. I just got up from a nap a little bit ago. [15:54:34] Hope I didn't scare you with my peak.schema post. :) [15:55:04] I haven't scanned the mailing list for a bit, so I don't think I've seen it. [15:55:11] Ah. :) [15:55:23] I've been busy coding :) [15:59:11] which post are you refering to? [15:59:19] * rdmurray looking at mailing list archives [15:59:20] "And so it begins..." [15:59:39] The second half mentions a bunch of stuff about peak.schema eventually replacing peak.model. [15:59:47] Ah. [16:00:18] But, as I mentioned before, not soon enough to help with your current project. :) [16:00:51] s'ok, I'm making fine progress with things as they are. [16:01:09] Really? Even with all the stuff you've found confusing? [16:01:43] Yeah. Everything I need is working at this point (I think, at least!) [16:01:51] Great. [16:02:19] So, even after all that, would you say it was still easier than the alternative? [16:02:29] Yes. [16:03:00] That's good. I have definitely been getting good feedback from you on what areas are crufty. [16:03:18] It would have taken me a lot longer to implement my own solution than to understand how to do it in peak. [16:03:25] I had a general idea already, but you confirmed my guesses and pointed out a some better specifics. [16:09:21] Nah, nothing too scary in that post. After all, you say things will keep working as they do now until everything is ready. I didn't read the workspace post, so I don't follow that bit at all. But the final goal statement (backend specific markup) sounds way cool. [16:09:47] The workspace stuff was back in July. I'm working on rather glacial timelines. :) [16:10:11] Glaciers may be slow, but you don't want to get in the way of one.... [16:10:19] Heh. Very true. [16:10:49] DM code: x = AccountsDM[id] [16:11:09] WS code: x = ws.Account.get(acct_id=id) [16:11:32] DM code: accts = AccountQueryDM[keys] [16:11:48] WS code: accts = ws.Account.find(key1=x, key2=y,...) [16:12:37] Where 'ws' is an instance of the specific backend+model class you've chosen to use. [16:13:01] e.g. class AccountsSQLWorkspace(SQLWorkspace): ... [16:13:18] that you then add some kind of declarations to, to use particular schema modules, etc. [16:13:37] so that the workspace instances have custom subclasses [16:13:55] i.e., 'ws.Account' isn't the same as your base 'Account' class, it's a subclass that knows what workspace instance it's attached to. [16:14:36] Thus, this does away with e.g. 'newItem()', because any instance you create of 'ws.Account()' already knows it belongs to 'ws'. So 'newItem()' isn't needed. [16:16:20] That sounds sweet. Much easier to understand, as you say. [16:16:28] And you won't have to create DM classes for each and every type, you'll just declare rules for loading/saving/deleting/adding, using generic function decorator syntax. [16:17:01] Yay :) [16:18:31] Better still, you'll be able to define those rules at a fairly abstract level, using metadata, rather than having to write individual rules for everything. [16:19:06] E.g., define a rule for mapping arbitrary objects to arbitrary tables, as a fallback if there's no more specific rule for a specific case. [16:19:47] Even the 'find()' and 'get()' will work that way... so you can insert a hand-tuned query if the parameters to a specific find/get match some circumstance that needs it. [16:20:02] * pje waxes rhapsodic [16:20:22] Worth waxing about :) [16:20:30] It's the ultimate balance between labor-saving automation and total control over every little detail. [16:20:59] Yeah. Take control of only the details you need to take control of. Quite a concept. [16:21:12] The grail I've been seeking for so many years now, that TransWarp was originally in search of. [16:22:01] In a sense, predicate-dispatch generic functions are the ultimate "tool that lets you focus on the job". [16:22:37] Although Python stays out of your way well enough as a language, if you're doing really complex things, you need slightly more power. [16:22:47] Yeah, I suspect that I'll find them even more of a "something I don't want to live without" in my future programming than I did Adapters. [16:22:58] * pje nods. [16:23:10] Business rules are the killer app. [16:23:14] :) [16:23:29] But then, so are compilers... adventure games... [16:23:34] Heh. [16:23:44] Heck, what is programming, really, but doing the right thing at the right time? [16:23:54] With rules, you can determine "the right time". [16:24:05] Good point. [16:24:18] I'm beginning to understand, actually, why the Lisp people are so stuck-up. ;) [16:24:28] lol [16:24:56] I always liked lisp, but it is hard to use as a "practical" language. [16:25:15] s/practical/everyday/ [16:25:31] Yeah, if you compare the dispatch API to equivalent syntax in CLOS, it's much more readable in Python. [16:25:39] More compact, too, in most cases. [16:26:34] I can hardly wait to start using 'em in PEAK, although in most of the core at the present time, I'll be limiting myself to single-dispatch functions. [16:27:29] Non-core stuff like security, web, schema and storage will go hog-wild with the fancy stuff, though. :) [16:27:43] that'll be a sight to see, I suspect. [16:28:16] Not really... the funny thing is how much *less* code the things use to accomplish a task. At least single-dispatch ones do, when compared to the equivalent code using adapters. [16:29:56] Well, what I meant was, it'll provide some good examples of using the complex stuff. [16:30:07] Oh, right. [16:30:17] Well, the simple examples will be more informative, I think. :) [16:30:38] Probably true :) [16:31:01] There are certainly parts of peak that I have stared at for quite some time before the light bulb went off. [16:31:18] And as you know in many places the light bulb hasn't gone off yet :) [16:33:18] Me, I don't even really remember how peak.security works inside. ;) [16:33:28] heh [16:33:43] Well, that's an exaggeration, but I'm certainly seeing some surprises as I review the source... "Oh, I didn't know it does *that*" :) [16:39:11] The thing that amazes me about peak already is how much it does in how little code. By the time you finish with the generic functions it will *really* seem like magic. [16:39:50] Not really; the main place where they'll have effect is in new stuff, so the existing code isn't going to shrink. [16:40:38] So what you'll be eliminating is just some Interfaces, basically? [16:40:57] (I'm thinking about the first part of that post) [16:41:06] For existing code, yes, and replacing the adapters with g.f. methods. [16:41:29] And not for all of the ones I posted, either. Some are higher priority than others. [16:41:43] * rdmurray nods. [16:42:00] For example, binding.getParentComponent() is important, because it means that PEAK will be able to deal with "foreign" components better. [16:42:23] For example, you could define a 'getParentComponent()' for wxWidget objects that gets their parent window... [16:42:39] without having to create an adapter class. [16:42:56] And without modifying the wx class, either. [16:43:34] cool. [16:46:44] Well, I've got the local Python Meetup in a couple hours; I'd better wrap up a few things around the house. [16:47:19] And I should go find or make myself supper. [16:47:26] * pje waves. Have a good one. [16:47:28] ** pje has left IRC ("Client exiting") [17:04:32] ** gbay has left IRC ("It's not like I'm leaving or anything...") [19:16:10] ** hazmat has joined us [19:16:28] * rdmurray waves. [20:53:29] ** hazmat has left IRC (Read error: 110 (Connection timed out)) [21:00:27] ** hazmat has joined us [21:09:37] ** rdmurray has left IRC ("User disconnected") [21:11:17] ** bitdancer has joined us [21:11:20] ** abditus has left IRC (Read error: 110 (Connection timed out)) [21:11:32] ** bitdancer has left us [21:17:32] ** rdmurray has joined us [21:19:33] ** hazmat has left IRC (Read error: 110 (Connection timed out)) [22:04:52] ** hazmat has joined us [23:26:29] ** hazmat has left IRC (Read error: 110 (Connection timed out)) [23:51:21] ** hazmat has joined us