<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/styles/rss-style.xsl"?>

<rss version="2.0"
 xmlns:blogChannel="http://backend.userland.com/blogChannelModule"
>

<channel>
<title>troglodyne.net</title>
<link>http://troglodyne.net//posts/6ffdf21a-13de-11ec-84d9-b0cfb5d9ee32?format=xml</link>
<description>troglodyne.net : /posts/6ffdf21a-13de-11ec-84d9-b0cfb5d9ee32</description>
<language>en</language>
<pubDate>2026-04-23T16:37:52</pubDate>
<lastBuildDate>2026-04-23T16:37:52</lastBuildDate>

<image>
<title>troglodyne.net</title>
<url>/favicon.ico</url>
<link>http://troglodyne.net</link>
<width>32</width>
<height>32</height>
<description>troglodyne.net favicon</description>
</image>
<item>
<title>Hand me the MOP!</title>
<link>http://troglodyne.net/posts/6ffdf21a-13de-11ec-84d9-b0cfb5d9ee32</link>
<description><![CDATA[<p>
Reading Mark Gardner's <a href="https://phoenixtrap.com/2021/08/03/whats-next-oo-perl/">latest post</a> on what's "coming soon" regarding OO and perl has made me actually think for once about objects, which I generally try to avoid.  I've posted a few times before that about the only thing I want regarding a new object model is for P5P to make up it's mind already.
I didn't exactly have a concrete pain point to give me cause to say "gimme" now.
Ask, and ye shall receive.
</p><p>
I recently had <a href="https://github.com/teodesian/playwright-perl/issues/38">an issue</a> come down the pipe at <a href="https://metacpan.org/pod/Playwright">playwright-perl</a>.  For those of you not familiar, I designed the module for ease of maintenance.  The way this was accomplished is to parse a spec document, and then build the classes dynamically using <a href="https://metacpan.org/pod/Sub::Install">Sub::Install</a>.  The significant wrinkle here is that I chose to have the playwright server provide this specification.  This means that it was more practical to simply move this class/method creation to runtime rather than in a BEGIN block.  Running subprocesses in BEGIN blocks is not usually something I would consider (recovered memory of ritual abuse at the hands of perlcc).
</p><p>
Anyways, I have a couple of options to fix the reporter's inability to subclass/wrap the Playwright child classes:
<ul>
<li>Run the subprocess in BEGIN to grab the spec from the playwright_server</li>
<li>install all the Moo stuff with Sub::Install as well</li>
<li>Throw in the towel on runtime meta and rely on compile-time code generation</li>
</ul>
I could of course abandon object orientation entirely as well.
The object model is familiar to users of Selenium::Remote::Driver (which is pretty much where all my user base is coming from), so that's probably not a great idea.
</p><p>
On the other hand, if we had a good "default mop" like Mark discusses, this would be a non-issue given we'd already get everything we want out of <em>bless</em> (or the successor equivalent).  It made me realize that we <em>could</em> have our cake and eat it in this regard by just having a third argument to <em>bless</em> (what MOP to use).
</p><p>
perl being what it is though, I am sure there are people who are in "bless is bad and should go away" gang.  In which case all I can ask is that whatever comes along accommodates the sort of crazed runtime shenanigans that make me enjoy using perl.  In the meantime I'm going back to compile-time metaprogramming.
</p>]]></description>
<author>george</author>
<guid isPermaLink="true">http://troglodyne.net/posts/6ffdf21a-13de-11ec-84d9-b0cfb5d9ee32</guid>
<pubDate>2021-08-05T18:55:00</pubDate>
<enclosure type="text/html" url="http://troglodyne.net/posts/6ffdf21a-13de-11ec-84d9-b0cfb5d9ee32" />
</item>
</channel>
</rss>
