I'm confused. The signature of initialize is used by Class.new in Ruby; the signature of __init__ is used by class_name() in Python... How is doing the same thing too much magic? Or am I misunderstanding the suggestion?
On 8/19/09, Kevan Benson <kben...@a-1networks.com> wrote: > > Should there not be a way to define object constructors with custom > signatures that can be usefully invoked like a normal constructor? > > Currently, defining a BUILD method for a class with a specific signature > doesn't seem to allow for the object to be invoked by new with that > signature and be correctly passed to the right BUILD method. It seems a > whole chain of new -> bless -> BUILDALL -> BUILD would need to be > defined with specific signatures just to get a custom constructor. > > Two possible thoughts on how to achieve this were put forth in the > #perl6 discussion. One, auto build the chain on definition of a BUILD > method, which was thought be some to be a bit too magical (me included, > even though it was my suggestion at first). Alternatively, pass the > capture of arguments as supplied by new down the chain of initialization > methods so any that were defined as multi's can be called correctly by > multiple dispatch at the correct point. > > I'm aware there's a default constructor that allows named parameters to > be set, but I think the usefulness of allowing specific constructors > that take defined parameters and initialize the object as needed should > not be overlooked. E.g. > my DateModule $d .= new('2007-03-12'); > > > > Relevant bits of #perl6 discussion copied below: > > (2009-08-19 11:47:49) Kentrak: Q re: object initialization in p6; Should > defining a BUILD with a non standard signature imply an implicit > declaration of new with the same signature? > (2009-08-19 11:48:05) moritz_: KyleHa: no > (2009-08-19 11:48:23) moritz_: erm sorry, meant Kentrak > (2009-08-19 11:48:26) moritz_: tab fail :/ > (2009-08-19 11:48:35) moritz_: Kentrak: it's a nice idea, but it seems > like too much magic to me > (2009-08-19 11:48:50) Kentrak: moritz_: I'm aware it doesn't currently, > but it seems like it really makes sense > (2009-08-19 11:48:59) Kentrak: moritz_: in a DWIMmy sort of way > (2009-08-19 11:49:28) moritz_: Kentrak: right, but I don't see how it > fits in the current system without defining a huge exception > (2009-08-19 11:49:29) r0bby left the room (quit: Read error: 104 > (Connection reset by peer)). > (2009-08-19 11:49:34) r0bby [n=wakaw...@guifications/user/r0bby] entered > the room. > (2009-08-19 11:49:43) __ash__: jnthn: http://gist.github.com/170571 > (2009-08-19 11:49:51) Kentrak: moritz_: it seems I need to define a > new() AND a BUILD() with matching signatures just to get the > initialization syntax I want, soI might as well use new(), but then I > have to cless... > (2009-08-19 11:49:52) moritz_: anyway, I'll think about it > (2009-08-19 11:50:02) Kentrak: err, bless > (2009-08-19 11:50:15) moritz_: Kentrak: no, new() is enough, no need for > another BUILD > mofino molaf moritz_ > mofino molaf moritz_ > (2009-08-19 11:50:52) moritz_: well, maybe we could have a new() with > slurpy positional arguments > (2009-08-19 11:50:55) masak: I override new() when I want magic > parameter handling, and BUILD when I want non-standard object > initialization. > (2009-08-19 11:50:56) japhb: moritz_, What are your rules of thumb for > when to use the various ways (implicit and explicit) to define constructors? > (2009-08-19 11:51:13) masak: #p6s in 10, by the way. > (2009-08-19 11:51:28) dalek: rakudo: 5a85869 | pmichaud++ | > docs/announce/2009-08: > (2009-08-19 11:51:28) dalek: rakudo: Small fix to release announcement. > (2009-08-19 11:51:28) dalek: rakudo: review: > http://github.com/rakudo/rakudo/commit/5a85869ddbc17095cdb884f10a6cd1618804d773 > (2009-08-19 11:51:31) moritz_: and have it try to dispatch to a BUILD > method, and fail if there's no matching one > (2009-08-19 11:51:37) jnthn: __ash__: OK, looks sane. > (2009-08-19 11:51:41) jnthn: __ash__: Two questions > (2009-08-19 11:51:42) Kentrak: moritz_: so if I want to add initializer > methods to support something like my DateModule $d .= new('2007-03-12'); > then I have to define new() submethods and use bless like in p5? > (2009-08-19 11:51:47) jnthn: 1) Does it make what you wanted to work > actually work? > (2009-08-19 11:51:51) moritz_: japhb: sorry, I'm involved in too many > things at a time, maybe I'll blog later about it > (2009-08-19 11:51:55) jnthn: 2) Does it still pass the spectests? :-) > (2009-08-19 11:51:58) japhb: moritz_, nod > (2009-08-19 11:52:11) masak: Kentrak: basically, yes. > (2009-08-19 11:52:12) moritz_: Kentrak: roughly, yes > (2009-08-19 11:52:37) jnthn: Kentrak: You'll generally want new to be > method, not submethod, though. > (2009-08-19 11:52:39) Kentrak: moritz_: actually, I assumed new() calls > BUILD(), does it? If it does, can't we just pass the same sig to BUILD > after blessing? > (2009-08-19 11:52:43) masak: Kentrak: .CREATE and .bless is how you > create objects in Perl 6. > (2009-08-19 11:53:04) masak: Kentrak: I think .bless calls BUILDALL, > which calls BUILD. > (2009-08-19 11:53:10) jnthn: .bless will trigger...yes, what masak said. > (2009-08-19 11:53:17) moritz_: pmichaud: funny, I had the exact same > fixes, byte by byte ;-) > (2009-08-19 11:53:18) Kentrak: masak: Hmm, I'm finding the Object > synopsis to be very lean on what the special methods are and how they > are to be used. > (2009-08-19 11:53:32) japhb: To me, Kentrak's example looks like a > coersion, rather than a normal constructor. > (2009-08-19 11:53:32) masak: Kentrak: I can sympathise with that. > (2009-08-19 11:53:45) masak: Kentrak: I had to figure it out over a > period of weeks! > (2009-08-19 11:53:55) moritz_: Kentrak: the problem is propagating the > signature of BUILD to the signature of new(), which is defined in Object > (2009-08-19 11:54:00) moritz_: but barring that, I like the idea. > (2009-08-19 11:54:09) jnthn: tbh the spec is kinda non-ideal as a > learning resource on this stuff. > (2009-08-19 11:54:19) jnthn: We could do with better docs on it. > (2009-08-19 11:54:23) masak: japhb: it could be either a constructor or > a coercion, by me. depends. > (2009-08-19 11:54:33) __ash__: jnthn: yeah, it does, in the cases i have > test, and i ran the spectest but i kinda forgot to run it before and > after the changes to see if there are any differences in the number of > spec's past, i do know that there are some specs in S12-class/ something... > (2009-08-19 11:54:41) Kentrak: moritz_: Hmm, I thought it would be the > other way around, but then again I haven't seen anything definitive > showing how the special methods all relate > (2009-08-19 11:54:46) __ash__: that do work now, they had a rakudo > specific thing to avoid them > (2009-08-19 11:55:02) r0bby left the room (quit: Connection reset by peer). > (2009-08-19 11:55:02) moritz_: Kentrak: new() calls bless, CREATE and > BUILDALL > (2009-08-19 11:55:06) r0bby [n=wakaw...@guifications/user/r0bby] entered > the room. > (2009-08-19 11:55:16) moritz_: Kentrak: and BUILDALL calls each class'es > BUILD > (2009-08-19 11:55:37) diakopter left the room (quit: Read error: 110 > (Connection timed out)). > (2009-08-19 11:55:48) Kentrak: jnthn: Well, having read through the > first 4 so far, I think they work rather well for someone who's already > versed in the ideas they propagate. Laters ones may be less ideal though. > (2009-08-19 11:55:54) TimToady left the room (quit: Read error: 110 > (Connection timed out)). > (2009-08-19 11:55:56) jnthn: (austrian railways)++ # ich hab mein > vorteils card! :D > (2009-08-19 11:56:28) jnthn: Kentrak: I meant in this specific aspect > (object construction) rather than in general. > (2009-08-19 11:56:47) Kentrak: jnthn: Then yes, I totally agree ;) > (2009-08-19 11:56:47) DakeDesu is now known as KatrinaTheLamia > (2009-08-19 11:56:53) jnthn: __ash__: OK, it sounds good then. > (2009-08-19 11:57:07) __ash__: its, S12-class/inheritance.t > (2009-08-19 11:57:27) moritz_: it seems that dumpiing match objects to > SVG is non-trivial > (2009-08-19 11:57:29) __ash__: there are 2 tests that are skipped, my > changes fix them > (2009-08-19 11:58:08) japhb: Kentrak, it looks like the relevant > implementation is in Rakudo's src/classes/Object.pir , line 272 and > following. > (2009-08-19 11:59:15) Kentrak: moritz_: Is there anything preventing the > passing of the signature from new along to each method that's called in > turn? Or are they called with different params? > (2009-08-19 11:59:49) sjohnson: afternoon > (2009-08-19 11:59:52) justatheory left the room (quit: ). > (2009-08-19 12:00:06) moritz_: Kentrak: signatures usually aren't passed > along, they are static. > (2009-08-19 12:00:07) masak: moritz_: non-trivial in what way? > (2009-08-19 12:00:32) moritz_: Kentrak: the problem is BUILD needs to > pass the information to new(), but they are called in reverse order > (2009-08-19 12:00:37) r0bby left the room (quit: Read error: 104 > (Connection reset by peer)). > (2009-08-19 12:00:41) r0bby [n=wakaw...@guifications/user/r0bby] entered > the room. > (2009-08-19 12:01:03) moritz_: masak: getting a good layout seems > non-trivial > (2009-08-19 12:01:21) masak: I can believe that. > (2009-08-19 12:01:36) Kentrak: moritz_: Does it? If new just calls > BUILDALL with the right capture (that's the sig, right?), and BUILDALL > just calls BUILD with the right capture, then the correct BUILD will > eventually be invoked due to multiple dispatch, right? > (2009-08-19 12:01:37) moritz_: maybe my approach is silly > (2009-08-19 12:01:58) moritz_: Kentrak: yes. But what signature does > new() have? > (2009-08-19 12:02:28) moritz_: Kentrak: maybe there's a simple solution > that I just don't see right now, I'm doing way too many things at once > (2009-08-19 12:02:39) moritz_: Kentrak: so please don't feel discouraged > (2009-08-19 12:02:51) moritz_: Kentrak: actually I'd recommend bringing > it up on perl6-language > (2009-08-19 12:03:20) molaf left the room (quit: Remote closed the > connection). > (2009-08-19 12:03:48) jnthn: __ash__: OK, submit the patch! :-) > (2009-08-19 12:03:51) jnthn: __ash__++ > (2009-08-19 12:03:55) tak11 [n=...@cpe-66-25-148-175.austin.res.rr.com] > entered the room. > (2009-08-19 12:04:03) Kentrak: moritz_: a generic slurpy one? I guess > I'm assuming the parameters could be used and matched to a signature. > That seemed one of the puproses of clusures when reading the low specs > (2009-08-19 12:04:13) Kentrak: moritz_: thanks, I think I will > (2009-08-19 12:04:15) __ash__: where would i submit it to? > (2009-08-19 12:04:46) moritz_: __ash__: rakudo...@perl.org > (2009-08-19 12:04:51) moritz_: (with a [PATCH] subject) > (2009-08-19 12:04:57) moritz_: Kentrak: yes, a slurpy might work > (2009-08-19 12:05:21) jnthn: Kentrak: The signature for new takes named > args and proto-objects. > (2009-08-19 12:05:29) jnthn: It passes the relevant bits to each BUILD. > (2009-08-19 12:05:42) moritz_: jnthn: right now, yes. We were discussing > possible enhancements > (2009-08-19 12:06:09) __ash__: do i need anything else in the subject > other than [PATCH]? and is it an attachment or the contents in the email? > (2009-08-19 12:06:11) r0bby left the room (quit: Read error: 104 > (Connection reset by peer)). > (2009-08-19 12:06:16) r0bby [n=wakaw...@guifications/user/r0bby] entered > the room. > (2009-08-19 12:06:30) masak: Kentrak: only the other day, I found out > that you can easily create a new() multimethod which does delegation > using callsame(|$args) or nextsame(|$args). that might be what you want. > (2009-08-19 12:06:36) Kentrak: jnthn: yes, aware of that, looking for a > way to not have to redefine multiple pieces to accomplish what I think > should be a simple feat, defining an initializer with custom params > > -- > > -Kevan Benson > -A-1 Networks > -- Sent from my mobile device Mark J. Reed <markjr...@gmail.com>