Bill Ricker / is on Nostr

#Perl programmer, #Math major, #Linux user. #CPAN #Ack #Fotoxx ; aka [@n1vux](https://mastodon.radio/@n1vux ) and elsewhere. ^Sarcasm thus^

articles: https://n1vux.github.io/articles/
city: Boston
pronouns: he/him/they

Last Notes

2024-07-08 13:49:51

- reply

as i read the POD, Feature::Compat::Class does the choice of which implementation to use, so if i use it, i don't need to have brittle $^V module choosers of my own. Right?
(So i could dial back required Perl version based on other experimental features desired. )

2024-07-08 13:39:25

- reply

thank you!

2024-07-07 22:10:11

- reply

according to perldoc, v5.40.0 feature class supports the :reader attribute but Feature::Compat::Class v0.808 does not? I don't mind writing my own setters, at least for objects that are mostly write-once, but this is discincentive to fall back to F:C:C currently; I'm not writing all the getters by hand if feature class and Object::Pad can write them for me.

2024-07-06 15:35:10

- reply

(I'm guessing the reason O:P's `:strict(params)` isn't allowed/supported in either F:C:C or feature class is that they are natively strict and they don't support nostrict params, which would be considered harmful. As i said, pivot to $^V choosing F:C:C or feature class will be deferred ONLY until i have completed current PoC pass.)

2024-07-06 13:35:59

- reply

👍

2024-07-06 13:24:53

- reply

yes that's the annoying bug I meant. I'm pleasantly surprised how easy it was to work around, old school tricks kick in like riding a bicycle.

2024-07-06 13:22:11

- reply

Compat would probably have been a better fallback choice, but I already had O:P on the laptop while barely connected,

2024-07-06 03:37:11

- reply

And yes, I am hardly surprised that two different keyword enhancing modules interact oddly.
It would be pleasant if two or more using the *same* extension technique would be layerable, and one might claim not to be so was a bug, but I'd try it before relying on it!
I'd like to use both, have liked a PoC with each despite nits, but that I can't combine two PoCs is %not% considered harmful.

2024-07-06 03:28:58

- reply

Object::Pad.
However it's doing syntactic magic, keyword declare encapsulated magic or naked singularity damianness, syntax errors in methods behave mostly badly in the version I had in v5.30 lib, which likely isn't latest
- and i have to presume feature class will be better integrated. So as soon as I reach another good (git)branch point I'll pivot.
( MEANTIME if Paul also wants O:P feedback as well, I'll update O:P on v5.40 and see if it's better behaved.)

2024-07-06 01:28:08

- reply

I'm expecting I'll like feature class workflow better.
I presume it's the Damian-esque code-rewriting in Object::Class that makes for obscure syntax errors.
(presumably also what makes it incompatible with @npub1ly3…dlv3 's match::simple::sugar , which along with Data::Enum makes a state machine prettier.)
I'm remarkably tolerant of binary search with =pod/=cut to find which line is in error when I've written/improved too much since last trial compilation, but parser context sure is nice.

2024-07-06 01:21:59

@npub1hlp…gkyk - over on the other other site, Ovid mentioned you were lacking feedback. Over the weekend i started converting a project grown too large to Object::Pad. I wanted to go straight to feature 'class', but alas my desktop->laptop clone doesn't copy PerlBrew and I didn't want to try building v5.40 and my cpan standards on a laptop with only DSL connectivity, so 2d draft is O:P, 3d will be 5.40 feature class.
(And if laptop is compatible with desktop executables, I'll get Perlbrew cloning!)

2024-04-13 00:34:27

- reply

the program IEFBR14's name is longer than it's object code.
Possibly the smallest commercial program, and it has/had a bug.
(Alas fixing the bug doubled the size and was backwards incompatible.)