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>

Reply via email to