Re: [Boston.pm] interpolate methods in a string
On Tue, 25 May 2010, Uri Guttman wrote: so that is 6 ways to do it without eval and tied. :) Thanks, I did in fact consider, and in a couple cases implement, all of those possible solutions, but was not happy with any of them. Basically, either the template is too cluttered: [%title%]... or I am using regexp replacement. I suppose I trust perl's parser and variable interpolation more than my own, which is why I like eval. I won't know the names of the methods until run-time since I am building a general purpose utility that can be used with any object. If we don't like eval I might be able to use String::Interpolate instead, though honestly I have read their documentation 3 times now and still don't precisely understand it. Broadly, what I want to do is almost what is described here: http://dev.perl.org/perl6/rfc/222.html except that I have one object on which all the methods will be called, so no need to repeat the object many times. Possibly that means I can "use v6" and get what I want, although I have not read up on what else that would change backwards-incompatibly. So it sounds like the best practice would be to go back to my own regexp substitution. Hm. Is there perhaps a packaged regexp somewhere that finds and replaces exactly the same strings of the form $abcd that the perl parser would? - Alex Aminoff BaseSpace.net ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
On Tue, 25 May 2010, Kenneth Graves wrote:
In the simple case (known methods/no side effects), then one of Uri's solutions
will work.
For the case of unknown methods, a two pass solution might work: collect the
method names from the template, then call them with $object->$method() syntax,
then interpolate the results.
Unfortunately, unless the perl compiler can magically delay execution in
some way, you then end up calling every single method to get its
value, even if you only need a couple of them. These objects have over 100
methods. Also, some of the methods might have side effects, like ->delete.
For something yet complicated, Template::Toolkit can handle objects in
templates. See
http://search.cpan.org/~abw/Template-Toolkit-2.22/lib/Template/Manual/Variables.pod
for the details. If you can't change the template language, then
preprocessing what you have to make it TT-compatible is another option.
It looks like TT has a perl-like interpolation mode so you can use $var
instead of [%var%]. It looks like it would work if I iterate over my
namespace as I did before to construct the variables hash for TT, with a
bunch of
$symbol => sub { $object->$symbol() }
that does get away from the eval and the tied scalar, thanks.
TT is big, so make sure this isn't a case of using a bazooka to swat a fly.
Fair point. If it works it will be worth it.
--kag
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
--
- Alex Aminoff
BaseSpace.net
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
> "AA" == Alex Aminoff writes: AA> On Tue, 25 May 2010, Uri Guttman wrote: >> so that is 6 ways to do it without eval and tied. :) AA> Thanks, I did in fact consider, and in a couple cases implement, all AA> of those possible solutions, but was not happy with any of them. AA> Basically, either the template is too cluttered: AA> [%title%]... AA> or I am using regexp replacement. I suppose I trust perl's parser and AA> variable interpolation more than my own, which is why I like eval. you should NOT like eval. it is very dangerous and overkill for this. eval should be a last resort when no other reasonable solution can be found. it is not a basic tool but only meant for advanced things because of its danger. AA> I won't know the names of the methods until run-time since I am AA> building a general purpose utility that can be used with any object. so? you need to deal with that issue regardless of interpolation as i pointed out before. AA> If we don't like eval I might be able to use String::Interpolate AA> instead, though honestly I have read their documentation 3 times now AA> and still don't precisely understand it. AA> Broadly, what I want to do is almost what is described here: AA> http://dev.perl.org/perl6/rfc/222.html AA> except that I have one object on which all the methods will be called, AA> so no need to repeat the object many times. repeat the object? show some example code of what you mean. AA> Possibly that means I can "use v6" and get what I want, although I AA> have not read up on what else that would change AA> backwards-incompatibly. it means you are dependent on v6 modules. not a killer if you don't need to worry about older perls. AA> So it sounds like the best practice would be to go back to my own AA> regexp substitution. Hm. Is there perhaps a packaged regexp somewhere AA> that finds and replaces exactly the same strings of the form $abcd AA> that the perl parser would? again, one of my solutions is fine. try the hash one and straight interpolation. you can code up a loop to make many method calls and store the results in the hash. then the string is easy to create and interpolate. or even use a bunch of scalars if there aren't too many. you haven't shown enough user code or requirements to help us make a best practice selection. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
> "AA" == Alex Aminoff writes:
AA> On Tue, 25 May 2010, Kenneth Graves wrote:
>> In the simple case (known methods/no side effects), then one of Uri's
solutions will work.
>>
>> For the case of unknown methods, a two pass solution might work: collect
the method names from the template, then call them with $object->$method()
syntax, then interpolate the results.
AA> Unfortunately, unless the perl compiler can magically delay execution
AA> in some way, you then end up calling every single method to get its
AA> value, even if you only need a couple of them. These objects have over
AA> 100 methods. Also, some of the methods might have side effects, like
-> delete.
that makes no sense. you only call the ones you know you need and store
the results in a hash. again, you are saying things which have
assumptions or knowledge about your needs which aren't clear. back up a
bit and show how you want to use this thing. show method calls and where
you want to interpolate them.
AA> It looks like TT has a perl-like interpolation mode so you can use
AA> $var instead of [%var%]. It looks like it would work if I iterate over
AA> my namespace as I did before to construct the variables hash for TT,
AA> with a bunch of
AA> $symbol => sub { $object->$symbol() }
AA> that does get away from the eval and the tied scalar, thanks.
and slows you down even more as you have an extra sub call for each
method. also in that line you are destroying the method name with the
result of the call.
>> TT is big, so make sure this isn't a case of using a bazooka to swat a fly.
AA> Fair point. If it works it will be worth it.
TT is not needed for this. not at all.
uri
--
Uri Guttman -- u...@stemsystems.com http://www.sysarch.com --
- Perl Code Review , Architecture, Development, Training, Support --
- Gourmet Hot Cocoa Mix http://bestfriendscocoa.com -
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
Other than some abstract fear of tie, what's wrong with Interpolation? As implemented, you could easily Memoize the subroutine you bind as your handler. You can even easily bind two versions, one that memoizes and another that does not. -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 73rd of Discord, in the YOLD 3176: Walls impede my progress ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
> "JP" == Jerrad Pierce writes: JP> Other than some abstract fear of tie, what's wrong with Interpolation? JP> As implemented, you could easily Memoize the subroutine you bind as your JP> handler. You can even easily bind two versions, one that memoizes and JP> another that does not. i am confused by your statement. i have no abstract fear of tied. it is just known to be slow and not needed here. why use a complex solution when simpler ones exist? and where did i say not to use interpolation? i said just use it in the best way. i am against eval for this, not interpolation. IMO the best solution is a hash of the method call results and interpolating the hash entries. but as i said, the OP has not stated the real top level requirements clearly. only some short comments about multiple methods and reusing objects were made. if that is cleared up then a best practice solution could be posited. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
Sure, let me try to explain what I want to do.
We have a bunch of objects of different classes. They all have a lot of
methods, more than I would want to list by hand.
Not knowing until run time which class or which methods I will want, I
would like to be able to interpolate method calls into a template.
# this is the module I wrote to do this, would prefer something else
use InterpolateMethods qw(interpolate_methods);
# this is an example, in practice templates will not
# be statically defined, but loaded in from a file or
# something of that sort
$pubtemplate = q[title: $title, by $authors]; # note single quotes
# @manypubs is an array of NBER::Publication objects
# NBER::Publication supports ->title and ->authors
foreach my $publication(@manypubs) {
print(interpolate_methods($publication,$pubtemplate));
}
#output:
# title: A Plan For Spam, by Paul Graham
# we got this by calling $publication->title
# and $publication->authors
I hope that is clear.
I misunderstood what someone was suggesting, but basically
s/\$(\w+)/$object->$1()/sgex;
will work, except that I did not trust my own regexp. Better:
s/\$(\w+)/ $object->can($1) ? $object->$1() : '$' . $1 /sgex
that will leave the orignal text untouched unless there is a method
available. Is there a better regexp than \$(\w+) to identify anything that
the perl parser would identify as a variable?
Thanks for all the responses, this is very helpful.
- Alex
On Wed, 26 May 2010, Uri Guttman wrote:
"JP" == Jerrad Pierce writes:
JP> Other than some abstract fear of tie, what's wrong with Interpolation?
JP> As implemented, you could easily Memoize the subroutine you bind as your
JP> handler. You can even easily bind two versions, one that memoizes and
JP> another that does not.
i am confused by your statement. i have no abstract fear of tied. it is
just known to be slow and not needed here. why use a complex solution
when simpler ones exist? and where did i say not to use interpolation? i
said just use it in the best way. i am against eval for this, not
interpolation. IMO the best solution is a hash of the method call
results and interpolating the hash entries. but as i said, the OP has
not stated the real top level requirements clearly. only some short
comments about multiple methods and reusing objects were made. if that
is cleared up then a best practice solution could be posited.
uri
--
- Alex Aminoff
BaseSpace.net
___
Boston-pm mailing list
Boston-pm@mail.pm.org
http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
> "AA" == Alex Aminoff writes: AA> I hope that is clear. AA> I misunderstood what someone was suggesting, but basically AA> s/\$(\w+)/$object->$1()/sgex; AA> will work, except that I did not trust my own regexp. Better: that is just a basic templater as i said before. now the question comes down to WHAT markup do you want to designate a method call to be made? there is no reason to use perl's $foo style here since perl never sees it. and $foo is hard to parse if it is next to text as in "$foobar". is that $foo and then bar? or $foobar? perl uses braces to disambiguate that. so why not choose a brace style to begin with? that is what template::simple does already as do others. a pairs bracket is easy to parse, sticks out, is hard to accidentally have in the text, etc. AA> s/\$(\w+)/ $object->can($1) ? $object->$1() : '$' . $1 /sgex why are you concerned with this? are you in charge of the input string? if you are in charge, then why can't you just make sure your $foo tokens are always properly matched to method names? it is your job anyway. how often would text have $foo that isn't a method call? or use fancy paired brackets like i keep saying since that is unlikely to be in text. AA> that will leave the orignal text untouched unless there is a method AA> available. Is there a better regexp than \$(\w+) to identify anything AA> that the perl parser would identify as a variable? yes, don't use $foo for the token. see my reasons above. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
Uri, >i am confused by your statement. i have no abstract fear of tied. I was referring to the OP's earlier statements. Tie may be 'overkill', but arguments have been made that a full templating system is too. >when simpler ones exist? and where did i say not to use interpolation? Not interpolation, Interpolation.pm, Dominus'^W^W^W^W^W^W^W^WJenda's module. http://www.perladvent.org/2005/6/ -- Free map of local environmental resources: http://CambridgeMA.GreenMap.org -- MOTD on Sweetmorn, the 73rd of Discord, in the YOLD 3176: Walls impede my progress ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
> "JP" == Jerrad Pierce writes: JP> Uri, >> i am confused by your statement. i have no abstract fear of tied. JP> I was referring to the OP's earlier statements. JP> Tie may be 'overkill', but arguments have been made that a full templating JP> system is too. >> when simpler ones exist? and where did i say not to use interpolation? JP> Not interpolation, Interpolation.pm, Dominus'^W^W^W^W^W^W^W^WJenda's module. JP> http://www.perladvent.org/2005/6/ that is just another templater by another name. s///eg is a templater. all substitutions are just templaters. the level of templating is the issue. TT is overkill, template::simple may be fine enough. but a properly done s/// is all this needs. uri -- Uri Guttman -- u...@stemsystems.com http://www.sysarch.com -- - Perl Code Review , Architecture, Development, Training, Support -- - Gourmet Hot Cocoa Mix http://bestfriendscocoa.com - ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 5 to Perl 6 evolution
Jason McIntosh wrote: > What I've lately been fond of explaining to friends is that "Perl6" is > the somewhat misleading name attached to Perl's skunkworks lab. It > develops, implements and tests various crazy ideas for new language > features, the best of which Perl adopts... Yes, exactly. > The name could be better... http://www.sdtimes.com/link/34307 The trouble with 6.0 6.0 seems to be a difficult number to reach. Last year, MySQL 6.0 was canceled when the community decided everything scheduled for that version should just be added in the 5.x branches. The same fate has just befallen the PHP community... This is mirrored in Perl's 5.12 release, the first for that language in a number of years. Most of the big minds in Perl have been thinking very hard about how to make 6.0 awesome. Unfortunately, they've been thinking and coding for almost 10 years now, and the remaining issues in Perl's 5.x branch were increasingly ignored. Updates were slow and infrequent, though new project management has pledged to make them more common. And in 5.12, the big fixes are almost all related to Unicode. One more 6.0 release was Windows Vista, right? Maybe there's some sort of 6.0 curse.-- Alex Handy > ...but getting a 10-year-old open-source project to change its > name seems unlikely; it seems easier to spread the meme that it's > Perl's R&D lab. True. James Eshelman wrote: > I think the developers of Perl 6 would do everybody a big favor by > renaming it. Calling it Perl 6 implies something that increasingly > doesn't seem to be true, and inhibits interest in and active development > of Perl 5. Agreed, but how do we make it happen. The people working on it seem to be happy with the name, and they ultimately have the say. We could all vote on it (post to whatever list covers perl 6 dev), but are they likely to listen? -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] interpolate methods in a string
> Is there a better regexp than \$(\w+) to identify anything that > the perl parser would identify as a variable? This seems to be the crux of whether you feel comfortable using s/// rather than something else. Unfortunately, I don't know the answer with complete and absolute certainty. \w is defined as anything that is a perl identifier. But it won't see special variables, like $@, and such. But I don't think you have to worry about that for method names or subroutine names or whatever. I think they'll always be \w+ There's screwy variable names in perl, but I can't think of any screwy subroutine or method names. So, I *think* you'll be safe. Greg ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 5 to Perl 6 evolution
Slackware skipped the 6.0 version entirely, they went straight from 4.0 to 7.0. Took them less than a year too, I guess they were on to something. -Original Message- From: boston-pm-bounces+jmcguire=liaison-intl@mail.pm.org [mailto:boston-pm-bounces+jmcguire=liaison-intl@mail.pm.org] On Behalf Of Tom Metro Sent: Wednesday, May 26, 2010 4:16 PM To: Jason McIntosh Cc: L-boston-pm Subject: Re: [Boston.pm] Perl 5 to Perl 6 evolution Jason McIntosh wrote: > What I've lately been fond of explaining to friends is that "Perl6" is > the somewhat misleading name attached to Perl's skunkworks lab. It > develops, implements and tests various crazy ideas for new language > features, the best of which Perl adopts... Yes, exactly. > The name could be better... http://www.sdtimes.com/link/34307 The trouble with 6.0 6.0 seems to be a difficult number to reach. Last year, MySQL 6.0 was canceled when the community decided everything scheduled for that version should just be added in the 5.x branches. The same fate has just befallen the PHP community... This is mirrored in Perl's 5.12 release, the first for that language in a number of years. Most of the big minds in Perl have been thinking very hard about how to make 6.0 awesome. Unfortunately, they've been thinking and coding for almost 10 years now, and the remaining issues in Perl's 5.x branch were increasingly ignored. Updates were slow and infrequent, though new project management has pledged to make them more common. And in 5.12, the big fixes are almost all related to Unicode. One more 6.0 release was Windows Vista, right? Maybe there's some sort of 6.0 curse.-- Alex Handy > ...but getting a 10-year-old open-source project to change its > name seems unlikely; it seems easier to spread the meme that it's > Perl's R&D lab. True. James Eshelman wrote: > I think the developers of Perl 6 would do everybody a big favor by > renaming it. Calling it Perl 6 implies something that increasingly > doesn't seem to be true, and inhibits interest in and active development > of Perl 5. Agreed, but how do we make it happen. The people working on it seem to be happy with the name, and they ultimately have the say. We could all vote on it (post to whatever list covers perl 6 dev), but are they likely to listen? -Tom -- Tom Metro Venture Logic, Newton, MA, USA "Enterprise solutions through open source." Professional Profile: http://tmetro.venturelogic.com/ ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm ___ Boston-pm mailing list Boston-pm@mail.pm.org http://mail.pm.org/mailman/listinfo/boston-pm
Re: [Boston.pm] Perl 5 to Perl 6 evolution [RETRY]
What I've lately been fond of explaining to friends is that "Perl6" is the somewhat misleading name attached to Perl's skunkworks lab. It develops, implements and tests various crazy ideas for new language features, the best of which Perl adopts... Yes, but no. But revealing. Yes, a few ideas developed for Perl 6 have been added to perl5. And there are some spinoff efforts, notably Moose. Yay. But no, if Kelly had delivered a few parts instead of an airplane, that would have been a total project fail. But the perspective is revealing. "Perl (perl5) is us. Perl6 is them. The only contribution they make to us, is coming up with crazy ideas, some of which we adopt. Therefore we define them as our crazy feature development lab." Even though that's not how the Perl 6 project participants, past or present, have defined the project. Although... the perspective does look something like that of the DoD/LM/etc bureaucrats who try to starve and kill skunkworks, so maybe the analogy works. ;) I suggest the critical characteristic of the Perl 6 development effort has been a dearth of developers. The lack of Perl community support. There are others, like poor project management, the distraction of Parrot, and a failure to retain good people. But mainly, almost no developers. For most of its existence, the Perl 6 effort has looked more like a Factor or even a Slate, than like a pypy or rubinius, let alone a python3 or ruby2. Has looked like yet another "let's make a new interesting language" hobby project, with one or two principals, a small weak team, and no broader support. With a similar "let's make a general VM" project, loosely attached, but hogging resources. And some one person projects on the side. To be fair, the other projects' support started small (except for py3), and grew as the projects started working, as it clearly would have with p6. And p6 specification has received longer and larger participation than has its implementation. And there have been two spikes of community p6 support, one for early Parrot, and then for Pugs. But then rather than fixing administrative and technical roadblocks encountered, people punted. Perhaps not unexpected on an open source project... but no forks (but for Pugs, perhaps Moose, and perhaps 5.12, and... well, lots of small one-personish projects), and little collaborative community effort to address the problems. It would be interesting to see a detailed comparison of p6/parrot/p5 vs py3/pypy/llmv/py2.x vs rb1.9/yarv/rubinius/rb1.8.x efforts. They all developed a VM and JIT, created a new incompatible version while continuing the old branch, and built a new implementation in the language itself. Faced many of the same technical and social issues. Perl being notable for its old complex language, crufty implementation, the size of the language change attempted, and its lack of success so far. Muling over the various efforts, two things seem particularly striking. One, Dan's speculative VM experiment early picked up an imprimatur, amazingly still widely believed, of "this is Perl 6". And absorbed a startling portion of project resources, attention, and consideration. The other efforts deferred such commitment until a candidate was at least partially working. And Two, perl faced a much more complex space of potential development paths. And got lost in them. There was never any shortage of possible development paths to success. There are still many. But there were never the focused developer resources to execute. And still aren't. So the overall project had two parts, a hyperfocus on parrot, and a slew of stymied attempts to find a cheap enough development path to success. "Let's incrementally extend p5 re into p6 rx, and build p6 parsing and compilation on p5... oh, the p5 regexp engine isn't reentrant (until years later), that's too expensive to fix, given that the p5 community is having trouble even finding perlguts maintainers, so punt, this isn't a viable path" was one of the first. It happened again and again. The hairy and buggy state of perlguts was repeatedly a critical problem. And there wasn't the project management focus, or community, to break through. The other efforts had healthy mainline development communities going in (unlike p5), providing the resources to pursue a modest (relative to p5) critical path, and broke off other components as "this is just for fun" (rubinius and pypy) or "it's just a candidate until it's sort of working" (yarv, and pypy on llvm). One other issue, the significance of which I don't know, is that at least some perl folk have not merely given up on obtaining a p6 implementation, but more fundamentally, don't buy the p6 language design. This too manifests as no developers, but isn't so much a failure, as a vote of no confidence. I think the developers of Perl 6 would do everybody a big favor by renaming it. Calling it Perl 6 implies something that increasingly doesn't seem to be tru
