Extending Mojo::Promise

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;







up vote
7
down vote

favorite












First time poster, be gentle.



I wanted something similar to Mojo::Promise->all, except with an option to discard certain rejected (or, I guess, resolved) promises dependent on rejection value, as determined by caller.



Only using this internally, so nevermind my polluting the Mojo::Promise:: namespace.



package Mojo::Promise::Filter;
use Moose;

extends 'Mojo::Promise';

has 'promises' => (
isa => 'ArrayRef[Mojo::Promise]',
is => 'ro',
required => 1,
);

has 'resolve_filter' => ( # truthy return means *DO* filter out
isa => 'CodeRef',
is => 'ro',
required => 1,
lazy => 1,
default => sub return sub ; ,
);

has 'reject_filter' => ( # truthy return means *DO* filter out
isa => 'CodeRef',
is => 'ro',
required => 1,
lazy => 1,
default => sub return sub ; ,
);

has '_promises_state_tracker' => (
# numbered hashref whose primary keys correspond to passed promise-array's indices
# secondary keys are flags for whether each original promise filtered
# and whether promise resolved/rejected,
# plus the original promise itself, e.g. :
# 0 => 1), ror => (undef
isa => 'HashRef[HashRef]',
is => 'ro',
lazy => 1,
builder => '_build_promises_state_tracker',
);


sub _build_promises_state_tracker
my $self = shift;
my $i = 0;
return map $i++ => original_promise => $_ @$self->promises ;


sub _resolve_or_reject_self_if_last_child
my $self = shift;

my @ror = grep $_->ror values %$self->_promises_state_tracker;
# gather the thus-far resolved-or-rejected promises
return unless scalar keys %$self->_promises_state_tracker == scalar @ror;
# return unless we have as many ror promises as were passed in

my @unfiltered = map $_->original_promise grep !$_->filtered values %$self->_promises_state_tracker;
return Mojo::Promise->all(@unfiltered)->then(sub
$self->resolve(@_)
)->catch(sub
$self->reject(@_)
);


sub filter
my $self = shift;

for my $i (0 .. $#$self->promises)
$self->promises->[$i]->then(sub
$self->_promises_state_tracker->$i->filtered = 1
if $self->resolve_filter->(@_);
)->catch(sub
$self->_promises_state_tracker->$i->filtered = 1
if $self->reject_filter->(@_);
)->finally(sub
$self->_promises_state_tracker->$i->ror = 1;
# ror = Resolved Or Rejected
$self->_resolve_or_reject_self_if_last_child();
);


return $self;


no Moose;

1;


Use as :



my $re_filter = qr/some special text/;
my $reject_filter = sub
my $v = shift;
return 1 if ref $v eq 'SCALAR' && $v =~ $re_filter;
;

my $p = Mojo::Promise::Filter->new(
reject_filter => $reject_filter,
promises => @promises
);

return $p->filter;






share|improve this question



























    up vote
    7
    down vote

    favorite












    First time poster, be gentle.



    I wanted something similar to Mojo::Promise->all, except with an option to discard certain rejected (or, I guess, resolved) promises dependent on rejection value, as determined by caller.



    Only using this internally, so nevermind my polluting the Mojo::Promise:: namespace.



    package Mojo::Promise::Filter;
    use Moose;

    extends 'Mojo::Promise';

    has 'promises' => (
    isa => 'ArrayRef[Mojo::Promise]',
    is => 'ro',
    required => 1,
    );

    has 'resolve_filter' => ( # truthy return means *DO* filter out
    isa => 'CodeRef',
    is => 'ro',
    required => 1,
    lazy => 1,
    default => sub return sub ; ,
    );

    has 'reject_filter' => ( # truthy return means *DO* filter out
    isa => 'CodeRef',
    is => 'ro',
    required => 1,
    lazy => 1,
    default => sub return sub ; ,
    );

    has '_promises_state_tracker' => (
    # numbered hashref whose primary keys correspond to passed promise-array's indices
    # secondary keys are flags for whether each original promise filtered
    # and whether promise resolved/rejected,
    # plus the original promise itself, e.g. :
    # 0 => 1), ror => (undef
    isa => 'HashRef[HashRef]',
    is => 'ro',
    lazy => 1,
    builder => '_build_promises_state_tracker',
    );


    sub _build_promises_state_tracker
    my $self = shift;
    my $i = 0;
    return map $i++ => original_promise => $_ @$self->promises ;


    sub _resolve_or_reject_self_if_last_child
    my $self = shift;

    my @ror = grep $_->ror values %$self->_promises_state_tracker;
    # gather the thus-far resolved-or-rejected promises
    return unless scalar keys %$self->_promises_state_tracker == scalar @ror;
    # return unless we have as many ror promises as were passed in

    my @unfiltered = map $_->original_promise grep !$_->filtered values %$self->_promises_state_tracker;
    return Mojo::Promise->all(@unfiltered)->then(sub
    $self->resolve(@_)
    )->catch(sub
    $self->reject(@_)
    );


    sub filter
    my $self = shift;

    for my $i (0 .. $#$self->promises)
    $self->promises->[$i]->then(sub
    $self->_promises_state_tracker->$i->filtered = 1
    if $self->resolve_filter->(@_);
    )->catch(sub
    $self->_promises_state_tracker->$i->filtered = 1
    if $self->reject_filter->(@_);
    )->finally(sub
    $self->_promises_state_tracker->$i->ror = 1;
    # ror = Resolved Or Rejected
    $self->_resolve_or_reject_self_if_last_child();
    );


    return $self;


    no Moose;

    1;


    Use as :



    my $re_filter = qr/some special text/;
    my $reject_filter = sub
    my $v = shift;
    return 1 if ref $v eq 'SCALAR' && $v =~ $re_filter;
    ;

    my $p = Mojo::Promise::Filter->new(
    reject_filter => $reject_filter,
    promises => @promises
    );

    return $p->filter;






    share|improve this question























      up vote
      7
      down vote

      favorite









      up vote
      7
      down vote

      favorite











      First time poster, be gentle.



      I wanted something similar to Mojo::Promise->all, except with an option to discard certain rejected (or, I guess, resolved) promises dependent on rejection value, as determined by caller.



      Only using this internally, so nevermind my polluting the Mojo::Promise:: namespace.



      package Mojo::Promise::Filter;
      use Moose;

      extends 'Mojo::Promise';

      has 'promises' => (
      isa => 'ArrayRef[Mojo::Promise]',
      is => 'ro',
      required => 1,
      );

      has 'resolve_filter' => ( # truthy return means *DO* filter out
      isa => 'CodeRef',
      is => 'ro',
      required => 1,
      lazy => 1,
      default => sub return sub ; ,
      );

      has 'reject_filter' => ( # truthy return means *DO* filter out
      isa => 'CodeRef',
      is => 'ro',
      required => 1,
      lazy => 1,
      default => sub return sub ; ,
      );

      has '_promises_state_tracker' => (
      # numbered hashref whose primary keys correspond to passed promise-array's indices
      # secondary keys are flags for whether each original promise filtered
      # and whether promise resolved/rejected,
      # plus the original promise itself, e.g. :
      # 0 => 1), ror => (undef
      isa => 'HashRef[HashRef]',
      is => 'ro',
      lazy => 1,
      builder => '_build_promises_state_tracker',
      );


      sub _build_promises_state_tracker
      my $self = shift;
      my $i = 0;
      return map $i++ => original_promise => $_ @$self->promises ;


      sub _resolve_or_reject_self_if_last_child
      my $self = shift;

      my @ror = grep $_->ror values %$self->_promises_state_tracker;
      # gather the thus-far resolved-or-rejected promises
      return unless scalar keys %$self->_promises_state_tracker == scalar @ror;
      # return unless we have as many ror promises as were passed in

      my @unfiltered = map $_->original_promise grep !$_->filtered values %$self->_promises_state_tracker;
      return Mojo::Promise->all(@unfiltered)->then(sub
      $self->resolve(@_)
      )->catch(sub
      $self->reject(@_)
      );


      sub filter
      my $self = shift;

      for my $i (0 .. $#$self->promises)
      $self->promises->[$i]->then(sub
      $self->_promises_state_tracker->$i->filtered = 1
      if $self->resolve_filter->(@_);
      )->catch(sub
      $self->_promises_state_tracker->$i->filtered = 1
      if $self->reject_filter->(@_);
      )->finally(sub
      $self->_promises_state_tracker->$i->ror = 1;
      # ror = Resolved Or Rejected
      $self->_resolve_or_reject_self_if_last_child();
      );


      return $self;


      no Moose;

      1;


      Use as :



      my $re_filter = qr/some special text/;
      my $reject_filter = sub
      my $v = shift;
      return 1 if ref $v eq 'SCALAR' && $v =~ $re_filter;
      ;

      my $p = Mojo::Promise::Filter->new(
      reject_filter => $reject_filter,
      promises => @promises
      );

      return $p->filter;






      share|improve this question













      First time poster, be gentle.



      I wanted something similar to Mojo::Promise->all, except with an option to discard certain rejected (or, I guess, resolved) promises dependent on rejection value, as determined by caller.



      Only using this internally, so nevermind my polluting the Mojo::Promise:: namespace.



      package Mojo::Promise::Filter;
      use Moose;

      extends 'Mojo::Promise';

      has 'promises' => (
      isa => 'ArrayRef[Mojo::Promise]',
      is => 'ro',
      required => 1,
      );

      has 'resolve_filter' => ( # truthy return means *DO* filter out
      isa => 'CodeRef',
      is => 'ro',
      required => 1,
      lazy => 1,
      default => sub return sub ; ,
      );

      has 'reject_filter' => ( # truthy return means *DO* filter out
      isa => 'CodeRef',
      is => 'ro',
      required => 1,
      lazy => 1,
      default => sub return sub ; ,
      );

      has '_promises_state_tracker' => (
      # numbered hashref whose primary keys correspond to passed promise-array's indices
      # secondary keys are flags for whether each original promise filtered
      # and whether promise resolved/rejected,
      # plus the original promise itself, e.g. :
      # 0 => 1), ror => (undef
      isa => 'HashRef[HashRef]',
      is => 'ro',
      lazy => 1,
      builder => '_build_promises_state_tracker',
      );


      sub _build_promises_state_tracker
      my $self = shift;
      my $i = 0;
      return map $i++ => original_promise => $_ @$self->promises ;


      sub _resolve_or_reject_self_if_last_child
      my $self = shift;

      my @ror = grep $_->ror values %$self->_promises_state_tracker;
      # gather the thus-far resolved-or-rejected promises
      return unless scalar keys %$self->_promises_state_tracker == scalar @ror;
      # return unless we have as many ror promises as were passed in

      my @unfiltered = map $_->original_promise grep !$_->filtered values %$self->_promises_state_tracker;
      return Mojo::Promise->all(@unfiltered)->then(sub
      $self->resolve(@_)
      )->catch(sub
      $self->reject(@_)
      );


      sub filter
      my $self = shift;

      for my $i (0 .. $#$self->promises)
      $self->promises->[$i]->then(sub
      $self->_promises_state_tracker->$i->filtered = 1
      if $self->resolve_filter->(@_);
      )->catch(sub
      $self->_promises_state_tracker->$i->filtered = 1
      if $self->reject_filter->(@_);
      )->finally(sub
      $self->_promises_state_tracker->$i->ror = 1;
      # ror = Resolved Or Rejected
      $self->_resolve_or_reject_self_if_last_child();
      );


      return $self;


      no Moose;

      1;


      Use as :



      my $re_filter = qr/some special text/;
      my $reject_filter = sub
      my $v = shift;
      return 1 if ref $v eq 'SCALAR' && $v =~ $re_filter;
      ;

      my $p = Mojo::Promise::Filter->new(
      reject_filter => $reject_filter,
      promises => @promises
      );

      return $p->filter;








      share|improve this question












      share|improve this question




      share|improve this question








      edited Jun 7 at 19:58









      200_success

      123k14143399




      123k14143399









      asked Jun 6 at 14:00









      robut

      384




      384




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          3
          down vote



          accepted










          I'm not entirely sure I understand what this does, but here goes.



          • Mojolicious doesn't use Moose. I would think long and hard whether I'd extend a Mojo::Base class with Moose. Does this work properly?

          • There are several instances of required together with default and lazy in your new attributes. Those do not make sense together. If it's required it needs to be passed in at construction. There is no need to make it lazy then as it will always be there from the start.

          • Your default for both reject_filter as well as resolve_filter are subs that return undef implicitly. That means if you don't pass those in, everything is discarded. Is that the intended behavior?


          • Your class is a subclass of Mojo::Promise, so there is no need to call Mojo::Promise->all. It's got an inherited ->all method that you can call on $self. (Mojo::Promise->all) returns a new object, so this breaks.





          share|improve this answer



















          • 1




            Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
            – robut
            Jun 7 at 16:00










          • I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
            – simbabque
            Jun 7 at 16:02










          • I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
            – robut
            Jun 7 at 16:38










          • @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
            – simbabque
            Jun 8 at 8:25










          Your Answer




          StackExchange.ifUsing("editor", function ()
          return StackExchange.using("mathjaxEditing", function ()
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix)
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
          );
          );
          , "mathjax-editing");

          StackExchange.ifUsing("editor", function ()
          StackExchange.using("externalEditor", function ()
          StackExchange.using("snippets", function ()
          StackExchange.snippets.init();
          );
          );
          , "code-snippets");

          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "196"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          convertImagesToLinks: false,
          noModals: false,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );








           

          draft saved


          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f195959%2fextending-mojopromise%23new-answer', 'question_page');

          );

          Post as a guest






























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes








          up vote
          3
          down vote



          accepted










          I'm not entirely sure I understand what this does, but here goes.



          • Mojolicious doesn't use Moose. I would think long and hard whether I'd extend a Mojo::Base class with Moose. Does this work properly?

          • There are several instances of required together with default and lazy in your new attributes. Those do not make sense together. If it's required it needs to be passed in at construction. There is no need to make it lazy then as it will always be there from the start.

          • Your default for both reject_filter as well as resolve_filter are subs that return undef implicitly. That means if you don't pass those in, everything is discarded. Is that the intended behavior?


          • Your class is a subclass of Mojo::Promise, so there is no need to call Mojo::Promise->all. It's got an inherited ->all method that you can call on $self. (Mojo::Promise->all) returns a new object, so this breaks.





          share|improve this answer



















          • 1




            Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
            – robut
            Jun 7 at 16:00










          • I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
            – simbabque
            Jun 7 at 16:02










          • I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
            – robut
            Jun 7 at 16:38










          • @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
            – simbabque
            Jun 8 at 8:25














          up vote
          3
          down vote



          accepted










          I'm not entirely sure I understand what this does, but here goes.



          • Mojolicious doesn't use Moose. I would think long and hard whether I'd extend a Mojo::Base class with Moose. Does this work properly?

          • There are several instances of required together with default and lazy in your new attributes. Those do not make sense together. If it's required it needs to be passed in at construction. There is no need to make it lazy then as it will always be there from the start.

          • Your default for both reject_filter as well as resolve_filter are subs that return undef implicitly. That means if you don't pass those in, everything is discarded. Is that the intended behavior?


          • Your class is a subclass of Mojo::Promise, so there is no need to call Mojo::Promise->all. It's got an inherited ->all method that you can call on $self. (Mojo::Promise->all) returns a new object, so this breaks.





          share|improve this answer



















          • 1




            Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
            – robut
            Jun 7 at 16:00










          • I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
            – simbabque
            Jun 7 at 16:02










          • I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
            – robut
            Jun 7 at 16:38










          • @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
            – simbabque
            Jun 8 at 8:25












          up vote
          3
          down vote



          accepted







          up vote
          3
          down vote



          accepted






          I'm not entirely sure I understand what this does, but here goes.



          • Mojolicious doesn't use Moose. I would think long and hard whether I'd extend a Mojo::Base class with Moose. Does this work properly?

          • There are several instances of required together with default and lazy in your new attributes. Those do not make sense together. If it's required it needs to be passed in at construction. There is no need to make it lazy then as it will always be there from the start.

          • Your default for both reject_filter as well as resolve_filter are subs that return undef implicitly. That means if you don't pass those in, everything is discarded. Is that the intended behavior?


          • Your class is a subclass of Mojo::Promise, so there is no need to call Mojo::Promise->all. It's got an inherited ->all method that you can call on $self. (Mojo::Promise->all) returns a new object, so this breaks.





          share|improve this answer















          I'm not entirely sure I understand what this does, but here goes.



          • Mojolicious doesn't use Moose. I would think long and hard whether I'd extend a Mojo::Base class with Moose. Does this work properly?

          • There are several instances of required together with default and lazy in your new attributes. Those do not make sense together. If it's required it needs to be passed in at construction. There is no need to make it lazy then as it will always be there from the start.

          • Your default for both reject_filter as well as resolve_filter are subs that return undef implicitly. That means if you don't pass those in, everything is discarded. Is that the intended behavior?


          • Your class is a subclass of Mojo::Promise, so there is no need to call Mojo::Promise->all. It's got an inherited ->all method that you can call on $self. (Mojo::Promise->all) returns a new object, so this breaks.






          share|improve this answer















          share|improve this answer



          share|improve this answer








          edited Jun 8 at 8:25


























          answered Jun 7 at 9:31









          simbabque

          933710




          933710







          • 1




            Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
            – robut
            Jun 7 at 16:00










          • I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
            – simbabque
            Jun 7 at 16:02










          • I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
            – robut
            Jun 7 at 16:38










          • @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
            – simbabque
            Jun 8 at 8:25












          • 1




            Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
            – robut
            Jun 7 at 16:00










          • I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
            – simbabque
            Jun 7 at 16:02










          • I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
            – robut
            Jun 7 at 16:38










          • @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
            – simbabque
            Jun 8 at 8:25







          1




          1




          Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
          – robut
          Jun 7 at 16:00




          Thanks ! I'm already using Moose elsewhere in my Mojo app, so I figured it wouldn't incur a significant overhead to use here. I trust that Moose handles extending a non-Moose class well enough, though I'll admit I don't know the subtle ways in which things might act quirky. I will look into "MooseX::NonMoose", or maybe not using Moose at all. Good catch with required+lazy. Yes, a default of "sub " returning undef means default behviour is for no promises to be filtered out. I think you might be right about being able to call just "$self->all(@unfiltered)", I will test it out. Thanks again !
          – robut
          Jun 7 at 16:00












          I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
          – simbabque
          Jun 7 at 16:02




          I wasn't thinking about the overhead regarding Moose, just that Mojolicious goes out of its way to not have Moose while maintaining a similar interface. I don't know what kind of things might happen there. Just wanted to note that down.
          – simbabque
          Jun 7 at 16:02












          I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
          – robut
          Jun 7 at 16:38




          I tried switching Mojo::Promise->all to $self->all, but it broke. Maybe related to the fact that method "all" "[r]eturns a new Mojo::Promise object [...]", per docs ? Or maybe because in the source for Mojo::Promise->all, it calls $class->new;, but $class is now Mojo::Promise::Filter and I told Moose to require attribute "promises", so "all" method fails internally to construct a new object ? Hm. Does Mojolicious offer a similar type system to Moose's ? I like being able to have Moose enforce, say, "isa => 'HashRef[HashRef]'". Compatibility vouch : stackoverflow.com/a/30809096
          – robut
          Jun 7 at 16:38












          @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
          – simbabque
          Jun 8 at 8:25




          @robut as far as I know it doesn't have any types. It's trying to be simple and on the point. My advice on the all was a guess based on the class hierarchy. Sorry that that didn't work.
          – simbabque
          Jun 8 at 8:25












           

          draft saved


          draft discarded


























           


          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fcodereview.stackexchange.com%2fquestions%2f195959%2fextending-mojopromise%23new-answer', 'question_page');

          );

          Post as a guest













































































          Popular posts from this blog

          Chat program with C++ and SFML

          Function to Return a JSON Like Objects Using VBA Collections and Arrays

          Will my employers contract hold up in court?