I think the "too much magic" is in automatically creating the appropriate "new" method with that signature. I idea is to get the standard behavior, which is to define a method that's signature is used for the instantiation.

Currently, I believe you have to define at least new and BUILD, not just one or the other. I guess you could redefine new and parse your arguments into the correct named pair arguments the other initialization functions (bless, BUILDALL, BUILD) expect, but that would be before blessing, and seems sort of limiting.

Mark J. Reed wrote:
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
(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++ |
(2009-08-19 11:51:28) dalek: rakudo: Small fix to release announcement.
(2009-08-19 11:51:28) dalek: rakudo: review:
(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
(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
(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
(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
(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
(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


-Kevan Benson
-A-1 Networks

Reply via email to