Bill Ricker

#Perl programmer, #Math major, #Linux user. #CPAN #Ack #Fotoxx ; aka Bill Ricker (npub1fj8…7hmy) and elsewhere. ^Sarcasm thus^

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

Public Key

npub1mw56emd342q3gpe0q4h7sy3php3tms8z6gaddxk490m7hkgj70dstgz4z0

NIP-05 Address

[email protected]

Profile Code

nprofile1qqsdh2dvakc64qg5quhs2mlgzgsmsc4acr3dywkknt2jhaltmyf08kcprpmhxue69uhhyetvv9ujumt0d4hhxarj9ecxjmnt9ucacc

Publishing to

relay.momostr.pink

Author Public Key

npub1mw56emd342q3gpe0q4h7sy3php3tms8z6gaddxk490m7hkgj70dstgz4z0

Show more details

Last Notes

2026-03-25 22:14:29 GMT

- reply

nice.
that ifdef-guarded code was a place bugs could hide, much better off without it.

2026-03-25 02:52:42 GMT

- reply

fair. 11 years old is pretty old base for someone tracking experimental versions of experimental features !

2026-01-06 01:07:19 GMT

- reply

nice!

2025-11-27 18:06:40 GMT

- reply

in which case Ovid's hypotheticalb alternate choice upthread would be less problematic than i initially expected.

2025-11-27 17:38:50 GMT

- reply

ooooh

2025-11-26 14:27:32 GMT

- reply

yes, affordances matter.
An :attribute to decorate a whole class once, to set default pub/privacy for the class might make it easy to do tight encapsulation when needed and loose or heritable access also easy.

2025-11-25 03:42:33 GMT

- reply

True enough.
But as thoroughly as we collectively ^embraced^ (read: rejected) the data encapsulation of Inside-Out Classes that were in vogue (supposedly) around the debut of PBP, i expect we'd want actual enforcement of _private() methods but not reversion to pre-OO-modularity of " what you forget to export isn't visible interface"; default private with :public attribute would at least make it clear at the useful spot but.

2025-11-25 02:38:54 GMT

- reply

I think private by default would be correct in theory
but
in terms of getting it accepted into core feature class,
that would yes likely have been fatal, or removed as a condition for moving forward,
so ... no harm no foul ?

2025-08-05 17:53:15 GMT

- reply

I like the distinction of smart vs interested (i'd say curious; both smart & curious is most useful.)
Among my generation (late Boomer aka Gen Jones) I have peculiarly positive memories of the 1960s New Math, because the foreshadows of Number Theory included in K-3, giving the WHY along with the HOW, spoke to me (and partly because of that, I was lucky enough to get some Number Theory & Modern Algebra as enrichment before college).

2025-04-20 20:11:22 GMT

- reply

Nerdy skew required to get any YES to BSD responses at all.
If you want really old, check correlation between age and whether used BSD before or after Linux, among those who've used both.
(We actually had Bell PWB Unix (sortofa 6.5) on the 11 before BSD-3. There are a few commercial SysVr2+BSD smergers I missed out on before Linux but not many i missed, at one job we hard porting lab, and another was a Legacy Zoo.)

2025-04-20 04:39:11 GMT

- reply

Oooh, portable! That would be a space savings over the monster I got cheap. Family is intolerant.

2025-01-15 12:58:44 GMT

- reply

👍

2025-01-15 02:56:12 GMT

- reply

👍
Is there or will there be a PPC for S:K:M ?
As an enhancement to Core, I like S:K:M as being impossible to confuse with deprecated ~~/given/when, and having a nice Say What You Mean, Don't Repeat Yourself SWIM-DRY in lieu of the excessive DWIMmery.
Is there a P5P thread that not having a working NetNews reader I haven't seen?

2025-01-14 22:51:24 GMT

- reply

OK, that works but i can't see why!
Your S:K:M:Deparse still has TODO and POD TODO for custom operators , and other worrying comments.
I do like the idea of match having %% also!
Now pondering whether maximal syntactic divergence from deprecated given-when is good or bad. I could argue either way ...

2025-01-14 22:34:31 GMT

- reply

ahh, i see
```
plan skip_all => "Syntax::Operator::Equ is not available"
unless eval { require Syntax::Operator::Equ };
```

2025-01-14 17:05:18 GMT

- reply

that would obviously be necessary for it to work.
=== etc not being in 0.15 match's POD nor t/ suggests to me the integration is in a dev version that I'm not seeing?

2025-01-13 21:41:32 GMT

- reply

well there's a reason I didn't see ===, equ, eqr in the POD; in CPAN version 0.15, they're deferred features.
t/
`plan skip_all => "Syntax::Operator::Equ is not available"`
Deparse.pm POD:
`Integrate with custom ops (C<equ>, C<eqr>, etc..)`
(I don't immediately see a dev version on CPAN or GH.)

2025-01-10 02:37:07 GMT

- reply

IDK, i just remeber that there were issues with next and friends with mixing one of the switch replacement modules with both Object::Pad and tall 'use class' Corina, when I tried both last year.
'next INNER;' is best practice to avoid surprises, but when user keywords or source filters create invisible unnamed blocks or anon subs, named block is essential and may need a lexical 'no warning'.
I'd have to check my notes to see which I tried.

2025-01-10 02:27:06 GMT

- reply

I didn't see those in the quick read of doc!

2025-01-09 21:07:27 GMT

- reply

- one can argue that declaring which of eq, ==, =~, isa is intended in the match explicitly is a goodness and case if() provides the flexibility to do stranger things explicitly.
"Making easy things easy and hard things possible ... but obvious"
- I wonder how either will work with next,last, redo.

2025-01-09 21:02:29 GMT

- reply

comparing your S:K:M to Damian's S::Right —
- I have some slight preference for the given-when keywords, but I could live with match-case.
- Your inclusion of isa() is good, for cases where dispatch by inheritance isn't desirable.
- Damian's inclusion of a maximal sane subset of former behavior (so that any sane pre-existing program has a chance of working) is arguably a plus.
- I could probably live with only eq,==,=~,isa on the match since you've got `case if()` in S:K:M.

2024-12-03 22:48:20 GMT

- reply

Such homework is not assigned without context, as it is presented here; rather, it is always in a context of recent assigned reading, in-class lectures & demonstrations, and in-class worksheets (exercises).
I'd guess this is in a context of lessons on simplifying expressions involving product and division of monomials of 2 variables.
(POST-Modern nomenclature may be different!)
This reinforces thinking about powers of x separately from powers of y.

2024-10-05 01:08:11 GMT

- reply

2024-07-08 13:49:51 GMT

- 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 GMT

- reply

thank you!

2024-07-07 22:10:11 GMT

- 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 GMT

- 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 GMT

- reply

👍

2024-07-06 13:24:53 GMT

- 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 GMT

- 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 GMT

- 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 GMT

- 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 GMT

- 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 GMT

@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 GMT

- 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.)