From wallisds at gmail.com Thu Apr 5 09:04:37 2012 From: wallisds at gmail.com (Dawn Wallis) Date: Thu, 5 Apr 2012 12:04:37 -0400 Subject: [baltimorepm] April Meeting, meeting space, and DCBPW Message-ID: Hi Baltimore Perl Group, I'm happy to inform you we have a new meeting space, still provided to us generously by CargoTel (http://www.cargotel.com/). This new place is just down the road from where we used to meet. The new location is in Baltimore on 2809 Boston St - STE 107, 21224. Member, Chris Rohlfs, really pulled through for us this month with getting us the meeting space (again). He's going to get us detailed entrance information a little later on. Also, we should really be thankful to CargoTel, this is the second meeting space they have provided to our group and they are also one of the sponsors for the DC-Baltimore Perl Workshop. Speaking of the DCBPW (on Saturday, April 14, 2012), have you signed up yet? As of today, there are 80 registered people coming from 3 countries and 13 monger groups. Check out the schedule or register to attend at http://dcbpw.org/dcbpw2012/. Because of the DCBPW and preparations for the new meeting space, our April meeting will be canceled. Baltimore.pm regular meetings will reconvene in May, details to follow. Thanks! Dawn Wallis Baltimore.pm -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbelcher at gmail.com Thu Apr 26 07:24:48 2012 From: sbelcher at gmail.com (Stephen Belcher) Date: Thu, 26 Apr 2012 10:24:48 -0400 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls Message-ID: Hi all, I'm wondering if anyone has an answer to this? https://gist.github.com/2499830 Essentially, I want to create a coderef while in the scope of one package, and delay binding of the subroutine calls until the actual execution, which will happen in or relative to another package, meaning that the subroutines that eventually resolve will be the ones located in the second package, not the first. This is different from what normally happens in closures. I can think of a few ways around the problem I'm trying to solve which aren't pretty, but I really like this one, cause I'm going for pretty, and I hope the answer's not just "you can't do that in Perl without XS Dark Magicks and/or a source filter". --Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From awgrover at gmail.com Thu Apr 26 07:34:31 2012 From: awgrover at gmail.com (Alan Grover) Date: Thu, 26 Apr 2012 10:34:31 -0400 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: References: Message-ID: <4F995CF7.5040404@gmail.com> This sounds like "dynamic" context from before the days of "lexical" context (see early lisp). And I haven't tried that sort of Evil in perl yet. It's not a concept that is in favor, though it has some applications. Cf. "goto". Putting the closure in a special package (e.g. "MyDynamicPackage"), and autoload, plus hunting up the stack ("caller()") for the package/context where you want to resolve it, might do it. Also, this is how "hygenic" macros work (again, in scheme/lisp): variables bind to the lexical context of the macro, but "free" variables bind to the execution context. Maybe look for various "macro" mechanisms in cpan? On 04/26/2012 10:24 AM, Stephen Belcher wrote: > Hi all, > > I'm wondering if anyone has an answer to > this? https://gist.github.com/2499830 > > Essentially, I want to create a coderef while in the scope of one > package, and delay binding of the subroutine calls until the actual > execution, which will happen in or relative to another package, meaning > that the subroutines that eventually resolve will be the ones located in > the second package, not the first. This is different from what normally > happens in closures. > > I can think of a few ways around the problem I'm trying to solve which > aren't pretty, but I really like this one, cause I'm going for pretty, > and I hope the answer's not just "you can't do that in Perl without XS > Dark Magicks and/or a source filter". > > --Stephen > > > _______________________________________________ > Baltimore-pm mailing list > Baltimore-pm at pm.org > http://mail.pm.org/mailman/listinfo/baltimore-pm -- Alan Grover awgrover at mail.msen.com +1.734.476.0969 (The "email signature" and/or digital-signature are only for informational and integrity purposes and does not constitute a legal signature) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: From brad.lhotsky at gmail.com Thu Apr 26 08:28:50 2012 From: brad.lhotsky at gmail.com (Brad Lhotsky) Date: Thu, 26 Apr 2012 17:28:50 +0200 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: <4F995CF7.5040404@gmail.com> References: <4F995CF7.5040404@gmail.com> Message-ID: As per our IM conversation, look at using Sub::Exporter in PackageA so you can pull that into PackageB however you'd like. 2012/4/26 Alan Grover : > This sounds like "dynamic" context from before the days of "lexical" > context (see early lisp). > > And I haven't tried that sort of Evil in perl yet. It's not a concept > that is in favor, though it has some applications. Cf. "goto". > > Putting the closure in a special package (e.g. "MyDynamicPackage"), and > autoload, plus hunting up the stack ("caller()") for the package/context > where you want to resolve it, might do it. > > Also, this is how "hygenic" macros ?work (again, in scheme/lisp): > variables bind to the lexical context of the macro, but "free" variables > bind to the execution context. Maybe look for various "macro" mechanisms > in cpan? > > On 04/26/2012 10:24 AM, Stephen Belcher wrote: >> Hi all, >> >> I'm wondering if anyone has an answer to >> this? https://gist.github.com/2499830 >> >> Essentially, I want to create a coderef while in the scope of one >> package, and delay binding of the subroutine calls until the actual >> execution, which will happen in or relative to another package, meaning >> that the subroutines that eventually resolve will be the ones located in >> the second package, not the first. This is different from what normally >> happens in closures. >> >> I can think of a few ways around the problem I'm trying to solve which >> aren't pretty, but I really like this one, cause I'm going for pretty, >> and I hope the answer's not just "you can't do that in Perl without XS >> Dark Magicks and/or a source filter". >> >> --Stephen >> >> >> _______________________________________________ >> Baltimore-pm mailing list >> Baltimore-pm at pm.org >> http://mail.pm.org/mailman/listinfo/baltimore-pm > > -- > Alan Grover > awgrover at mail.msen.com > +1.734.476.0969 > > (The "email signature" and/or digital-signature > are only for informational and integrity purposes > and does not constitute a legal signature) > > > _______________________________________________ > Baltimore-pm mailing list > Baltimore-pm at pm.org > http://mail.pm.org/mailman/listinfo/baltimore-pm -- Brad Lhotsky From Mike.Barry at refworks-cos.com Thu Apr 26 08:49:40 2012 From: Mike.Barry at refworks-cos.com (Barry, Mike) Date: Thu, 26 Apr 2012 11:49:40 -0400 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: References: <4F995CF7.5040404@gmail.com> Message-ID: It also sounds like a good use case for Moose::Role where the role requires the composing class to implement a method. -MikeB. On Apr 26, 2012, at 11:28 AM, Brad Lhotsky wrote: > As per our IM conversation, look at using Sub::Exporter in PackageA so > you can pull that into PackageB however you'd like. > > 2012/4/26 Alan Grover : >> This sounds like "dynamic" context from before the days of "lexical" >> context (see early lisp). >> >> And I haven't tried that sort of Evil in perl yet. It's not a concept >> that is in favor, though it has some applications. Cf. "goto". >> >> Putting the closure in a special package (e.g. "MyDynamicPackage"), and >> autoload, plus hunting up the stack ("caller()") for the package/context >> where you want to resolve it, might do it. >> >> Also, this is how "hygenic" macros work (again, in scheme/lisp): >> variables bind to the lexical context of the macro, but "free" variables >> bind to the execution context. Maybe look for various "macro" mechanisms >> in cpan? >> >> On 04/26/2012 10:24 AM, Stephen Belcher wrote: >>> Hi all, >>> >>> I'm wondering if anyone has an answer to >>> this? https://gist.github.com/2499830 >>> >>> Essentially, I want to create a coderef while in the scope of one >>> package, and delay binding of the subroutine calls until the actual >>> execution, which will happen in or relative to another package, meaning >>> that the subroutines that eventually resolve will be the ones located in >>> the second package, not the first. This is different from what normally >>> happens in closures. >>> >>> I can think of a few ways around the problem I'm trying to solve which >>> aren't pretty, but I really like this one, cause I'm going for pretty, >>> and I hope the answer's not just "you can't do that in Perl without XS >>> Dark Magicks and/or a source filter". >>> >>> --Stephen >>> >>> >>> _______________________________________________ >>> Baltimore-pm mailing list >>> Baltimore-pm at pm.org >>> http://mail.pm.org/mailman/listinfo/baltimore-pm >> >> -- >> Alan Grover >> awgrover at mail.msen.com >> +1.734.476.0969 >> >> (The "email signature" and/or digital-signature >> are only for informational and integrity purposes >> and does not constitute a legal signature) >> >> >> _______________________________________________ >> Baltimore-pm mailing list >> Baltimore-pm at pm.org >> http://mail.pm.org/mailman/listinfo/baltimore-pm > > > > -- > Brad Lhotsky > _______________________________________________ > Baltimore-pm mailing list > Baltimore-pm at pm.org > http://mail.pm.org/mailman/listinfo/baltimore-pm > From bsimon at stsci.edu Thu Apr 26 08:07:19 2012 From: bsimon at stsci.edu (Bernie Simon) Date: Thu, 26 Apr 2012 15:07:19 +0000 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: Message-ID: On 4/26/12 10:24 AM, "Stephen Belcher" wrote: >I'm wondering if anyone has an answer to this? >https://gist.github.com/2499830 Normally the way you do something like this is to call a method on an object reference. The method is looked up at run time, so by varying the object reference, you get a different method. The package the method is defined in can be require'd at run time, making the whole thing as dynamic as you like. I know this doesn't answer the question you asked, but if you tell us the problem you are trying to solve, maybe we can tell you a way of accomplishing it without fighting Perl. From genehack at genehack.org Thu Apr 26 09:44:46 2012 From: genehack at genehack.org (John SJ Anderson) Date: Thu, 26 Apr 2012 12:44:46 -0400 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: References: Message-ID: <350EC4F7ECDD442ABA52D9ACCBA37F89@genehack.org> On Thursday, April 26, 2012 at 10:24 AM, Stephen Belcher wrote: > Hi all, > > I'm wondering if anyone has an answer to this? https://gist.github.com/2499830 > Looking at the gist, and specifically at the last section of it, I'm wondering why you can't just use the fully specified method name. I.e., instead of sub configure { my ($coderef) = sub { hello; }; do sub configure { my ($coderef) = sub { PackageA::hello; }; > > Essentially, I want to create a coderef while in the scope of one package, and delay binding of the subroutine calls until the actual execution, which will happen in or relative to another package, meaning that the subroutines that eventually resolve will be the ones located in the second package, not the first. This is different from what normally happens in closures. > > It sounds like you have some problem you're trying to decide, and you have gotten onto this particular path of solving it, and it's not really the right solution. Perhaps you could explain what you're trying to achieve with this code? (Not the "call a method in packageB but use packageA's context for method resolution", but the problem you were working on solving _before_ you started on this?) chrs, john. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsimon at stsci.edu Thu Apr 26 09:53:48 2012 From: bsimon at stsci.edu (Bernie Simon) Date: Thu, 26 Apr 2012 16:53:48 +0000 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: <350EC4F7ECDD442ABA52D9ACCBA37F89@genehack.org> Message-ID: Here's an example of what I was getting at. Code modified to work with my old version of Perl #!/usr/bin/env perl use strict; my $obj = PackageA->new(); my $code = PackageB::configure($obj); &$code; package PackageA; sub new { my ($class) = @_; # old style objects, avert your eyes! my $self = {}; return bless($self, $class); } sub hello { print "hello, world\n"; } package PackageB; sub configure { my ($obj) = @_; my $coderef = sub { $obj->hello; }; return $coderef; } From genehack at genehack.org Thu Apr 26 10:18:11 2012 From: genehack at genehack.org (John SJ Anderson) Date: Thu, 26 Apr 2012 13:18:11 -0400 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: References: Message-ID: <0D41C79FCDF244A7A7B4F660F8349730@genehack.org> On Thursday, April 26, 2012 at 12:53 PM, Bernie Simon wrote: > Here's an example of what I was getting at. Code modified to work with my > old version of Perl > > Looks like an inside-out backwards way of doing roles. If you have some objections to using Moose, there's also Role::Tiny now -- https://metacpan.org/release/Role-Tiny -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbelcher at gmail.com Thu Apr 26 10:19:44 2012 From: sbelcher at gmail.com (Stephen Belcher) Date: Thu, 26 Apr 2012 13:19:44 -0400 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: <350EC4F7ECDD442ABA52D9ACCBA37F89@genehack.org> References: <350EC4F7ECDD442ABA52D9ACCBA37F89@genehack.org> Message-ID: I'm trying to allow someone to set up a class B as a subclass of class A::Base::Class using an anonymous callback sub which isolates the configuration methods and keeps them out of both A::Base::Class and B in order to keep the namespace clear, but doesn't require the person using class A::Base::Class to know that all the configuration actually happens in A::Base::Class::ConfigurationSubclass (and keep said person from having to type `my ($x) = A::Base::Class::ConfigurationSubclass::config_this(42); A::Base::Class::ConfigurationSubclass::config_that($x + 5);`). Ultimately, if the programmer knew that `A::Base::Class::ConfigurationSubclass` was the direct way to configure their package, and didn't mind all the extra typing and the damage to the : key, he or she could do it, and the world wouldn't stop (this is Perl after all, I think it's in the contract somewhere that we have to provide at least two methods to achieve the same result). However, for his or her own sanity, `__PACKAGE__->configure(sub { my ($x) = config_this(42); config_that($x + 5); });` is also a possibility. Ultimately, the way I've rewritten the file in ( https://gist.github.com/2499830#file_crazier.pl) utilizing some hints from a CPAN Macro module I found per Alan's suggestion (localizing exported method calls to the aforementioned B class), has some known caveats (a sub named A::Base::Class::ConfigurationSubclass::config_this's existence would clobber any value of $B::config_this, @B::config_this, etc. during the call to configure(), for instance). I think they're probably livable though. Solving the one I mentioned isn't impossible but it comes with what I think is an unreasonable speed penalty. There are probably others, but nothing significant I've thought of yet. That being said, I don't think I've seen Perl modules configured this way in the past, and if it's because people have assessed it as a known possibility and discounted it as completely wrong-headed, I'm still relatively fresh in the process of writing the module that'd use it, and I can probably be talked back off the ledge if there are good reasons not to do it. --Stephen On Thu, Apr 26, 2012 at 12:44 PM, John SJ Anderson wrote: > On Thursday, April 26, 2012 at 10:24 AM, Stephen Belcher wrote: > > Hi all, > > I'm wondering if anyone has an answer to this? > https://gist.github.com/2499830 > > Looking at the gist, and specifically at the last section of it, I'm > wondering why you can't just use the fully specified method name. I.e., > instead of > > > sub configure { > > my ($coderef) = sub { > > hello; > > }; > > do > > sub configure { > my ($coderef) = sub { > PackageA::hello; > }; > > > > > Essentially, I want to create a coderef while in the scope of one package, > and delay binding of the subroutine calls until the actual execution, which > will happen in or relative to another package, meaning that the subroutines > that eventually resolve will be the ones located in the second package, not > the first. This is different from what normally happens in closures. > > It sounds like you have some problem you're trying to decide, and you have > gotten onto this particular path of solving it, and it's not really the > right solution. Perhaps you could explain what you're trying to achieve > with this code? (Not the "call a method in packageB but use packageA's > context for method resolution", but the problem you were working on solving > _before_ you started on this?) > > chrs, > john. > > > > _______________________________________________ > Baltimore-pm mailing list > Baltimore-pm at pm.org > http://mail.pm.org/mailman/listinfo/baltimore-pm > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bsimon at stsci.edu Thu Apr 26 11:10:04 2012 From: bsimon at stsci.edu (Bernie Simon) Date: Thu, 26 Apr 2012 18:10:04 +0000 Subject: [baltimorepm] Closures and Late-Binding Subroutine Calls In-Reply-To: Message-ID: On 4/26/12 1:19 PM, "Stephen Belcher" wrote: >I'm trying to allow someone to set up a class B as a subclass of class >A::Base::Class using an anonymous callback sub which isolates the >configuration methods and keeps them out of both A::Base::Class and B in >order to keep the namespace clear I'm not sure I understand completely what you're trying to do. But normally object oriented programming uses both inheritance and composition to accomplish its job. Composition seems the best way to handle this problem. In this case, an object of the base class would include a reference to a configuration object. The configuration object would handle such issues as reading the configuration file. Since the methods that handle the configuration are invoked from the base class, subclasses perform the same configuration through inheritance. But the configuration methods are encapsulated, as they are only invoked from one method in the base class, presumably by the new method. That's the way I handle configuration in my code. From genehack at genehack.org Sat Apr 28 08:39:39 2012 From: genehack at genehack.org (John SJ Anderson) Date: Sat, 28 Apr 2012 11:39:39 -0400 Subject: [baltimorepm] Quack and Hack 2012 Message-ID: <73E1806D-9167-4132-BCA7-4643509294DA@genehack.org> Since it's relatively close (outside Philly), people may be interested in the upcoming Quack and Hack workshop: chrs, john. -- John SJ Anderson // genehack at genehack.org