Re: S5: substitutions
Larry Wall wrote: On Sat, Oct 07, 2006 at 07:49:48PM -0700, Jonathan Lang wrote: : Another possibility: make it work. Add a "delayed" parameter trait : that causes evaluation of that trait to be postponed until the first : time that the parameter actually gets used in the routine. If it : never gets used, then it never gets evaluated. I could see uses for : this outside of the narrow scope of implementing substitutions. Tell me how you plan to do MMD on a value you don't have yet. MMD is based on types, not values; and you don't neccessarily have to evaluate something in order to know its type. Also, you don't neccessarily need every argument in order to do MMD: if there's a semi-colon in any of the candidates' signatures prior to the argument in question, MMD stands a decent chance of selecting a candidate before the question of its type comes up. Worst case scenario (a Code object without a return type being compared to a non-Code parameter), you can treat the argument's type as "Any", and let the method redispatch once the type is known, if it's appropriate to do so. That said, the real problem here is figuring out what to do if some candidates ask for a given parameter to be lazily evaluated and others don't. It would probably be best to restrict the "lazy evaluation" option to the prototype's parameters, so that it always applies across the board. -- Consider this as another option: instead of a parameter trait, apply a trait to the method prototype. With this trait in play, all parameter evaluations are postponed as long as possible. If the first candidate needs only the first two parameters to test its viability, only evaluate the first two parameters before testing it. If the dispatch succeeds, the other parameters remain unevaluated until they actually get used in the body. If all of the two-parameter candidates fail, evaluate the next batch of parameters and go from there. This approach doesn't guarantee that a given parameter won't be evaluated before its first appearance within the routine; but it does remove the guarantee that it will be. -- In the case of subst, there's an additional wrinkle: you can't always evaluate the expression without making reference to the pattern's Match object, which won't be known until the pattern is applied to the invocant. In particular, closures that refer to $0, $1, etc. will only work properly if called by the method itself, and only after $0, $1, etc. have been set. All things considered, the best solution for subst might be to treat the timing of quote evaluation in a manner analogous to regex evaluation. -- Jonathan "Dataweaver" Lang
Synposis 26 - Documentation [alpha draft]
Before Christmas, as promised!
I have a 95% complete Perl 5 implementation of a parser for this, but it is
too large to fit in the margin. I may release the beta of that next week, once
I'm home from my travels.
Damian
-cut--cut--cut--cut--cut-
=for comment
This file is deliberately specified in Perl 6 Pod format
Clearly a Perl 6 -> Perl 5 documentation translator is a high priority ;-)
=head1 TITLE
[DRAFT] Synopsis 26 - Documentation
=head1 AUTHORS
Damian Conway <[EMAIL PROTECTED]>
Ingy dEt Net <[EMAIL PROTECTED]>
=head1 VERSION
=for table
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 9 Apr 2005
Last Modified: 7 Oct 2006
=head1 Perldoc
Perldoc is an easy-to-use markup language with a simple, consistent
underlying document object model. Perldoc can be used for writing the
documentation for Perl 5 and Perl 6, and for Perl programs and modules,
as well as for other types of document composition.
Perldoc allows for multiple syntactic I, all of which map onto
the same set of standard document objects. The standard dialect is named
L<"Pod"|#The Pod Dialect>.
=head1 The Pod Dialect
I is an evolution of Perl 5's Plain Ol' Documentation (POD) markup.
Compared to Perl 5 POD, Perldoc's Pod dialect is much more uniform,
somewhat more compact, and considerably more expressive.
=head2 General syntactic structure
Pod blocks are specified using I, which always start with an
C<=> in the first column. Every Pod block directive may be written in
any of three equivalent forms: I, I,
or I.
=head3 Delimited blocks
Delimited blocks are bounded by C<=begin> and C<=end> markers, both of
which are followed by a valid identifierN, which is the typename of the block. Typenames
that are entirely lowercase (for example: C<=begin head1>) or entirely
uppercase (for example: C<=begin SYNOPSIS>) are reserved.
After the typename, the rest of the C<=begin> marker line is treated as
configuration information for the block. This information is used in
different ways by different types of blocks, and is specified using
Perl6ish C<:key{value}> or C<< key=>value >> pairs (which must, of
course, be constants since Perldoc is a specification language, not a
programming language).
See Lhttp://dev.perl.org/perl6/doc/design/syn/S02.html#Literals>
for a summary of the Perl 6 pair notation.
The configuration section may be extended over subsequent lines by
starting those lines with an C<=> in the first column followed by a
horizontal whitespace character.
The lines following the opening delimiter and configuration are the data
or contents of the block, which continue until the block's C<=end> marker
line. The general syntax is:
=begin code :allow< R >
=begin R R
= R
R
=end R
=end code
For example:
=begin table :title
Constants 1
Variables 10
Subroutines 33
Everything else 57
=end Table
=begin Name :required
=:width(50)
The applicant's full name
=end Name
=begin Contact :optional
The applicant's contact details
=end Contact
Note that no blank lines are required around the directives, and blank
lines within the contents are always treated as part of the contents.
Note also that in the following specifications, a "blank line" is a line that
is either empty or that contains only whitespace characters. That is, a blank
line matches C. Pod uses blank lines, rather than empty lines, as
delimiters (on the principle of least surprise).
=head3 Paragraph blocks
Paragraph blocks are introduced by a C<=for> marker and terminated by
the next Pod directive or the first blank line (which is I
considered to be part of the block's contents). The C<=for> marker is
followed by the name of the directive and optional
configuration information. The general syntax is:
=begin code :allow< R >
=for R R
=R
R
=end code
For example:
=for table :title
Constants 1
Variables 10
Subroutines 33
Everything else 57
=for Name :required
= :width(50)
The applicant's full name
=for Contact :optional
The applicant's contact details
Once again, blank lines are not required around the directive (this is a
universal feature of Pod).
=head3 Abbreviated blocks
Abbreviated blocks are introduced by an C<'='> sign in the
first column, which is followed immediately by the typename of the
block. The rest of the line is treated as block data, rather than as
configuration. The content terminates at the next Pod directive or the
first blank line (which is not part of the block data). The general
syntax is:
=begin code :allow< R >
=R R
R
=end code
For example:
=table
Constants 1
Variables 10
Subroutines
Re: S5: substitutions
On Sat, Oct 07, 2006 at 07:49:48PM -0700, Jonathan Lang wrote: : Another possibility: make it work. Add a "delayed" parameter trait : that causes evaluation of that trait to be postponed until the first : time that the parameter actually gets used in the routine. If it : never gets used, then it never gets evaluated. I could see uses for : this outside of the narrow scope of implementing substitutions. Tell me how you plan to do MMD on a value you don't have yet. Larry
Re: S5: substitutions
Jonathan Lang wrote: Another possibility: make it work. Add a "delayed" parameter trait... ...although "lazy" might be a better name for it. :) -- Jonathan "Dataweaver" Lang
Re: S5: substitutions
Larry Wall wrote: As a unary lazy prefix, you could even just say s[pattern] doit(); Of course, then people will wonder why .subst(/pattern/, doit()) doesn't work. Another possibility: make it work. Add a "delayed" parameter trait that causes evaluation of that trait to be postponed until the first time that the parameter actually gets used in the routine. If it never gets used, then it never gets evaluated. I could see uses for this outside of the narrow scope of implementing substitutions. -- Jonathan "Dataweaver" Lang
Re: S5: substitutions
Larry Wall wrote:
Jonathan Lang wrote:
: Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
: say:
:
:s(pattern) { doit() }
Well, the () are illegal without intervening whitespace because that
makes s() a function call, but we'll leave that alone.
Thank you; I noticed this after I had sent it.
Perl 5 let certain choose-your-own quotes introduce various kinds of
odd semantics, and that was generally viewed as a mistake. That is why
S02 says:
For these "q" forms the choice of delimiters has no influence on the
semantics. That is, C<''>, C<"">, C<< <> >>, C<«»>, C<``>, C<()>,
C<[]>, and C<{}> have no special significance when used in place of
C as delimiters.
We could make an exception for the second part of s///, but certainly
for this case I think it's easy enough to write:
.subst(/pattern/, { doit })
However, taken as a macro, s/// is a rather odd fish. The right side
isn't just a string, but a deferred string, which implies that there
are always curlies there, much like the right side of && implies
deferred evaluation.
Perhaps quotes should be given the same "defer or evaluate as
appropriate to the context" capability that regexes and closures have?
That is, 'q (text)' is always a Quote object, which may be evaluated
immediately in certain contexts and be passed as an object in others.
As a first cut, consider using the same rule for this that regexes
use: in a value context (void, boolean, string, or numeric) or as an
explicit argument of ~~, a quote is immediately evaluated; otherwise,
it's passed as an object to be evaluated later.
The main downside I see to this is that there's no way to force one
approach or the other; a secondary issue has to do with the usefulness
of an unevaluated string: with regexes and closures, the unevaluated
versions are useful in part because they can be made to do different
things when evaulated, based on the circumstances: $x ~~ $regex will
do something different than $y ~~ $regex, and closures can potentially
be fed arguments that allow one closure to do many things. A quote,
OTOH, isn't neccessarily that flexible.
Or is it? Is there benefit to extending the analogy all the way,
letting someone define a parameterized quote?
But it's possible that some syntactic relief of a dwimmy sort is
in order here. One could view s[pattern] as a kind of metaprefix
on the following expression, sort of a self-contained unary &&.
I wonder how often we'd have to explain why
s/pattern/ "expression"
doesn't do that, though. 'Course, it's already like that in Perl 5.
Probably not too often - although I _would_ recommend that you
emphasize the distinction between standard regex notation used
everywhere else and the "extended" regex notion used by s///.
I _do_ like the idea of reserving this behavior to situations where
the pattern delimiters are a matched set, letting you freely choose
some other delimiter for the expression. In particular, I'm not
terribly fond of the idea of
s'pattern'expression'
applying single-quote semantics to the expression.
Unlike in Perl 5, this approach would rule out things like:
s[pattern] !foo!
which would instead have to be written:
s[pattern] qq!foo!
Fine by me. This would also let you easily apply quote modifiers to
the expression.
As a unary lazy prefix, you could even just say
s[pattern] doit();
Of course, then people will wonder why
.subst(/pattern/, doit())
doesn't work.
Perhaps. But people quickly learn that different approaches in perl
often have their own unique quirks; this would just be one more
example.
Which makes me want to build it into the pattern somewhere
where there's already deferred evaluation that just happens to be triggered
at the right moment:
/pattern {subst doit}/
/pattern {subst "($0)"}/
/pattern {subst q:to'END'}/
a new line
END
We can give the user even more rope to shoot themselves in the dark with:
/pattern {$/ = doit}/
/pattern {$0 = "($0)"}/
/pattern {$() = q:to'END'}/
a new line
END
The possibilities are endless...
These aren't syntaxes that I'd want to use; but then, TIMTOWTDI. The
main problem that I have with this approach is that it could interfere
with being able to use the venerable s/pattern/expression/ notation;
I'm looking to open up new possibilities, not to remove a perfectly
workable existing one.
Well, not quite. One syntax we *can't* allow is /pattern/{ doit }
because that's already used to pull named captures out of the match
object.
...which brings up another potential conflict with the s/// notation:
how _do_ you pull named captures out of the match object in s///?
--
On a related subject: it seems to me that the notion of extending the
pattern notation to include a "replace" clause is at the heart of the
issue here. In addition to the above issues, it seems to be too much
Re: S5: substitutions
On Sat, Oct 07, 2006 at 03:07:49PM -0700, Jonathan Lang wrote:
: S5 says:
: >There is no /e evaluation modifier on substitutions; instead use:
: >
: > s/pattern/{ doit() }/
: >
: >Instead of /ee say:
: >
: > s/pattern/{ eval doit() }/
:
: In my perl5 code, I would occasionally take advantage of the "pairs of
: brackets" quoting mechanism to do something along the lines of:
:
:s(pattern) { doit() }e
:
: Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
: say:
:
:s(pattern) { doit() }
Well, the () are illegal without intervening whitespace because that
makes s() a function call, but we'll leave that alone.
: Instead of
:
:s(pattern) { { doit() } }
Perl 5 let certain choose-your-own quotes introduce various kinds of
odd semantics, and that was generally viewed as a mistake. That is why
S02 says:
For these "q" forms the choice of delimiters has no influence on the
semantics. That is, C<''>, C<"">, C<< <> >>, C<«»>, C<``>, C<()>,
C<[]>, and C<{}> have no special significance when used in place of
C as delimiters.
We could make an exception for the second part of s///, but certainly
for this case I think it's easy enough to write:
.subst(/pattern/, { doit })
However, taken as a macro, s/// is a rather odd fish. The right side
isn't just a string, but a deferred string, which implies that there
are always curlies there, much like the right side of && implies
deferred evaluation.
: In a similar vein, I tend to write other perl5 substitutions using
: parentheses for the pattern so that I can use double-quotes for the
: substitution expression:
:
:s(pattern) "expression"
Because the right side must be deferred, the .subst form of that would be:
.subst(/pattern/, {"expression"})
Otherwise, the double quotes interpolate too early. That's getting a
little more cumbersome.
: This highlights to me the fact that the expression is _not_ a pattern,
: and uses a syntax more akin to interpolated strings than to patterns.
: The above bit about executables got me to thinking: _if_ perl6 is
: smart enough to recognize curly braces and automatically treat the
: second argument as an executable expression, would there be any
: benefit to letting perl6 apply customized quoting semantics to the
: second argument as well, based on the choice of delimiters? e.g.,
: using single quotes would disable variable substitutions and the like
: (useful in cases where the substitution doesn't make use of the
: captures done by the pattern, if any).
Well, again, that's maybe just:
.subst(/pattern/, {'expression'})
or even, since we don't need to delay evaluation:
.subst(/pattern/, 'expression')
But it's possible that some syntactic relief of a dwimmy sort is
in order here. One could view s[pattern] as a kind of metaprefix
on the following expression, sort of a self-contained unary &&.
I wonder how often we'd have to explain why
s/pattern/ "expression"
doesn't do that, though. 'Course, it's already like that in Perl 5.
Unlike in Perl 5, this approach would rule out things like:
s[pattern] !foo!
which would instead have to be written:
s[pattern] qq!foo!
As a unary lazy prefix, you could even just say
s[pattern] doit();
Of course, then people will wonder why
.subst(/pattern/, doit())
doesn't work. Which makes me want to build it into the pattern somewhere
where there's already deferred evaluation that just happens to be triggered
at the right moment:
/pattern {subst doit}/
/pattern {subst "($0)"}/
/pattern {subst q:to'END'}/
a new line
END
We can give the user even more rope to shoot themselves in the dark with:
/pattern {$/ = doit}/
/pattern {$0 = "($0)"}/
/pattern {$() = q:to'END'}/
a new line
END
The possibilities are endless...
Well, not quite. One syntax we *can't* allow is /pattern/{ doit }
because that's already used to pull named captures out of the match
object.
Well, enough random braindump for now.
Larry
Re: S5: substitutions
Jonathan Lang skribis 2006-10-07 15:07 (-0700):
> Translating this to perl 6, I'm hoping that perl6 is smart enough to let me
> say:
>s(pattern) { doit() }
> Instead of
>s(pattern) { { doit() } }
I would personally hope that Perl isn't that clever, but treats all
bracketing delimiters the same there. Partly for future-proofness,
partly for least surprise.
--
korajn salutojn,
juerd waalboer: perl hacker <[EMAIL PROTECTED]>
convolution: ict solutions and consultancy <[EMAIL PROTECTED]>
Ik vertrouw stemcomputers niet.
Zie
Re: S5: perl5 regex flags
Larry Wall wrote: On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote: : It's been indicated that several regex modifiers that are found in : Perl5 are gone. That's all well and good, unless you're using the : Perl5 modifier to port code to perl6. What happens if you're trying : to port in a regex that made use of one of the now-obsolete modifiers? You just put them inside with (?smx). Ah; gotcha. I had been under the impression that there were subtle differences between (?msx) and //msx, such as the former allowing you to turn the flags on or off mid-pattern. Not that it matters if you put this at the front of the pattern... -- Jonathan "Dataweaver" Lang
Re: S5: perl5 regex flags
On Sat, Oct 07, 2006 at 03:28:04PM -0700, Jonathan Lang wrote: : It's been indicated that several regex modifiers that are found in : Perl5 are gone. That's all well and good, unless you're using the : Perl5 modifier to port code to perl6. What happens if you're trying : to port in a regex that made use of one of the now-obsolete modifiers? You just put them inside with (?smx). Larry
S5: perl5 regex flags
It's been indicated that several regex modifiers that are found in Perl5 are gone. That's all well and good, unless you're using the Perl5 modifier to port code to perl6. What happens if you're trying to port in a regex that made use of one of the now-obsolete modifiers? Bear in mind that there are new s and x modifiers that have nothing to do with their perl5 homonyms. Suggestion: let the Perl5 modifier take an optional argument that consists of perl5-compatable, perl6-incompatable modifiers: m, s, and/or x. The other regex-related perl5-compatable modifiers (e, g, and o) have more to do with the match and substitute functions than with the patterns themselves, and so can be updated to perl6 standards without regard to the pattern used. -- Jonathan "Dataweaver" Lang
S5: substitutions
S5 says:
There is no /e evaluation modifier on substitutions; instead use:
s/pattern/{ doit() }/
Instead of /ee say:
s/pattern/{ eval doit() }/
In my perl5 code, I would occasionally take advantage of the "pairs of
brackets" quoting mechanism to do something along the lines of:
s(pattern) { doit() }e
Translating this to perl 6, I'm hoping that perl6 is smart enough to let me say:
s(pattern) { doit() }
Instead of
s(pattern) { { doit() } }
--
In a similar vein, I tend to write other perl5 substitutions using
parentheses for the pattern so that I can use double-quotes for the
substitution expression:
s(pattern) "expression"
This highlights to me the fact that the expression is _not_ a pattern,
and uses a syntax more akin to interpolated strings than to patterns.
The above bit about executables got me to thinking: _if_ perl6 is
smart enough to recognize curly braces and automatically treat the
second argument as an executable expression, would there be any
benefit to letting perl6 apply customized quoting semantics to the
second argument as well, based on the choice of delimiters? e.g.,
using single quotes would disable variable substitutions and the like
(useful in cases where the substitution doesn't make use of the
captures done by the pattern, if any).
--
Jonathan "Dataweaver" Lang
Re: "Don't tell me what I can't do!"
Trey Harris writes: > In a message dated Wed, 4 Oct 2006, chromatic writes: > > > The assumption I remember from the design meetings was always "No > > library designer has the knowledge or the right to tell me how fast > > or strict my program has to run." Whatever B&D you do in the > > privacy of your own modules is fine, but if it leaks out past > > encapsulation boundaries, expect that somewhere you might offend > > community standards. > > Yes, but by the same token, no library designer should force you to be > *less* strict than you wish to. Sure. > I remember not so many years ago when there were a lot of modules > floating around that required you to do "no strict" of various flavors > in order to use them. Really? How? > I still run across modules that need "no warnings". (I won't name > names, because some of their authors post to this list ;) Again, I can't see how. If you use C in your program then it is lexically scoped and only affects your code, not that of other files you load in. C<-w> does affect all files, but that's one of the reasons why C is an improvement over C<-w>, because it lets the author of each bit of code have control over it. Smylers
Re: Re: class interface of roles
TSa wrote: Dispatch depends on a partial ordering of roles. Could someone please give me an example to illustrate what is meant by "partial ordering" here? -- Jonathan "Dataweaver" Lang
Re: Re: class interface of roles
On 10/6/06, TSa <[EMAIL PROTECTED]> wrote:
HaloO,
Stevan Little wrote:
> On 10/2/06, Jonathan Lang <[EMAIL PROTECTED]> wrote:
>> This notion of exclusionary roles is an interesting one, though. I'd
>> like to hear about what kinds of situations would find this notion
>> useful; but for the moment, I'll take your word that such situations
>> exist and go from there.
>
> Well to be honest, I haven't found a real-world usage for it yet (at
> least in my travels so far), but the Fortress example was this:
>
> trait OrganicMolecule extends Molecule
> excludes { InorganicMolecule }
> end
> trait InorganicMolecule extends Molecule end
Wouldn't that be written in Perl6 the other way around?
role OrganicMolecule {...}
role InorganicMolecule {...}
role Molecule does OrganicMolecule ^ InorganicMolecule {...}
Which is a nice usage of the xor role combinator.
Well, it does seem to accomplish a similar goal. However, in your
example there is nothing about the OrganicMolecule which will prevent
me from composing it with the InOrganicMolecule, which was the primary
goal of the Fortress example. In addition in the Fortress example the
Molecule role is not coupled to the Organic and Inorganic molecules,
in your example they are.
But IMHO this is just another example of TIMTOWTDI, because your
example achieves similar goals and would likely be a valid design
approach as well.
> And from that I could see that given a large enough set of roles you
> would surely create roles which conflicted with one another on a
> conceptual level rather then on a methods/attribute (i.e. - more
> concrete) level.
I don't abide to that. If roles are conceptually modelling the same
entity their vocabulary should conflict also. Well unless some
differing coding conventions accidentally produce non-conflicting
roles. The whole point of type systems relies on the fact that
concrete conflicts indicate conceptual ones!
But part of the power of role composability is that the role itself
does not need to dictate what class it is composed into. So conceptual
conflicts cannot be determined until compostion actually occurs, and
conflicts between two conceptually conflicting roles cannot be
detected until composition time either. And of course there is nothing
to say that two conceptually conflicting roles have a concrete
conflict either (either between methods or attributes).
I think that maybe we need to seperate the concept of roles as types
and roles as partial classes, they seem to me to be in conflict with
one another. And even they are not in conflict with one another, I
worry they will bloat the complexity of roles usage.
My experiences thus far with roles in Moose have been that they can be
a really powerful means of reuse. I point you towards Yuval Kogman's
latest work on Class::Workflow, which is basically a loose set of
roles which can be composed into a highly customizable workflow
system. This is where I see the real power of roles coming into play.
- Stevan
Re: Re: class interface of roles
On 10/6/06, TSa <[EMAIL PROTECTED]> wrote: HaloO, Stevan Little wrote: > As for how the example in the OP might work, I would suspect that > "super" would not be what we are looking for here, but instead a > variant of "next METHOD". I'm not familiar with the next METHOD syntax. How does one get the return value from it and how are parameters passed? Would the respective line in the equal method then read: return next METHOD($p) and self.x == $p.x and self.y == $p.y; I think that a super keyword might be nice syntactic sugar for this. I think super is not something we would want in Roles, it implies ordering, which defeats the flattening aspect of Roles. IIRC the syntax to call the next method with new args and a return value is this: return call($p) and self.x == $p.x and self.y == $p.y; However, I am not sure I really like the look of that myself. > However, even with that an ordering of some > kind is implied The only ordering I see is that the class is "up" from the role's perspective. But thats the whole problem, there is no "up" in roles, they are flattened. When more then one role is combined and all require the presence of an equal method I think the roles can be combined in any order and the super refers to the class combined so far. IOW, at any given time in the composition process there is a current version of the class' method. The final outcome is a method WALK or however this is called in composition order. Conceptually this is method combination: seen from outside the class has just one type correct method equal. Theoretical background can be found in http://www.jot.fm/issues/issue_2004_01/column4 I do not think method combination should be the default for role composition, it would defeat the composeability of roles because you would never have conflicts. However, I can see the possibility of method combinations in roles being some kind of special case. How that might look from a syntactic perspective I have no idea. > I suppose this is again where the different concepts of classes are > roles can get very sticky. I have always look at roles, once composed > into the class, as no longer needing to exist. In fact, if it weren't > for the idea of runtime role compostion and runtime role > introspection, I would say that roles themselves could be garbage > collected at the end of the compile time cycle. I see that quite different: roles are the primary carrier of type information! Well yes, they do seem to have taken on this role ;). However, roles as originally envisioned in the Traits paper are not related to the type system, but instead related to class/object system. In fact the Trait paper gave it's examples in Smalltalk, which is not a strongly typed language (unless you count the idea that *everything* is an object and therefore that is their type). I think we need to be careful in how we associate roles with the type system and how we assocaite them with the object system. I worry that they will end up with conflicting needs and responsibilities and roles will end up being too complex to be truely useful. Dispatch depends on a partial ordering of roles. Type based dispatch does (MMD), but class based method dispatch doesn't need it at all. The whole fact that dispatching requires roles to be partially ordered actually tells me that maybe roles should not be so hinged to the type system since roles are meant to be unordered. Possiblely we should be seeing roles as a way of *implementing* the types, and not as a core component of the type system itself? I did some experimentation with this in Moose::Autobox, but that is for Perl 5 so I am not sure how relevant it is here. - Stevan
