Was it really not possible to make that a shorthand for the existing structure with blessing variables? Having two object systems may make things too confusing.
This was brought up a few times. There were several issues with that approach.
* `bless` and `class` aren't topologically equivalent: you can't twist and warp one into the other
* We've seen small, incremental steps get beaten to death by bike-shedding every step
* Sometimes it's hard to see the big picture when you're looking at the individual details
It's that first point that's really the killer here. Perl used `bless` and `@ISA` ("we have methods" and "here's where to find them") and that was all.
You want state? Figure it out.
You want encapsulation? Figure it out.
You want to work around MRO bugs? Figure it out.
You want to know if something in the symbol table is a subroutine or a method? Figure it out.
You want composition? Figure it out.
Much of what we wanted just couldn't be easily done building on a broken foundation, but there's so much excellent work out there which already solves these problems for class-based OO, we decided to take advantage of what others have already learned.
Thanks. I admit I haven't often used Moose et al., or any Perl OO system, except in a project that was set up by someone else in which I only occasionally added a method.
The prior "object system" was just a way to stuff things into the symbol table. I'm hand waving here, but the point is it that the scope of that system ended at "calling a method on an instance of a class" and there was nothing beyond it unless you rolled that all yourself:
abstract classes
derived classes / polymorphism
attribute type constraints
delegation
encapsulation
composition (roles)
immutable state
and so on
And many people did roll their own, which resulted in Moose (Moo, et al) on CPAN, which have evolved to be some of the best in class (ha) object system frameworks and features across any language.
Now the plan is to get that into the core, and this is the first step.
No serious Perl developer has been using bless for OO for a least a decade, unless they were constrained by micro optimisations and/or not being allowed to use non-core dependencies.
I consider myself a serious Perl developer, working in a Perl shop for the past 15 years. We still prefer using bless and continue to use it in the present day. It so much lighter weight than the M* systems and I prefer the simplicity and speed of it.
All I need is magic structs with methods and that provides it. Throw in a constant array of properties and an AUTOLOAD, and you have accessors if you need it.
He wanted to try a repl with persistent lexicals but his NetBSD install was getting sufficiently long in the tooth he didn't want to risk running CPAN on it - and fatpacking a script I had handy was a lot quicker and more effective in terms of getting him to try something out than trying to convince him to let me walk him through a local::lib setup.
fatpacking bolts the source code untouched onto the front in a way that leaves you a single readable pure perl file - and is limited to pure perl modules as a deliberate decision to keep things simple and clear even if you've never encountered a fatpacked script before. Well, also because trying to pack XS is a freaking nightmare - that way would lie recreating PAR and Audrey's busy being a minister in Taiwan's government so generally not easy for me to consult these days.
Ok, I do actually have a hilariously awful trick that manages to wrap DynaLoader to read from a Base64 encoded .so that's inlined into the fatpack but that was more a "wondering if I could" thing than something I've ever felt the urge to actually use in anger so I've (so far) resisted the siren song of CPANing it anyway because people have an unfortunate tendency to forget that I, too, release things that are terrible ideas sometimes.
(though being able to use XS modules with a single file you squirt over an ssh connection ala Object::Remote without needing to write anything to disk is kinda fun, especially when you do it with DBD::SQLite ;)
APPerl sounds like it could be awesome, App::staticperl is the closest to it I've looked at so far, though since APPerl definitely wants to write to a non-noexec filesystem I wouldn't be surprised if I there are cases where if I had that and a toolchain available I'd end up using it to run Perl::Build to bootstrap a more normal perl and then go from there.
Either way, thank you very much for pointing out APPerl's existence to me. Even if I don't end up using it myself, having it in my mental index of available crazy things will almost certainly eventually result in my suggesting it to somebody else who'll find it the least insane way of getting the results they need :D
> Audrey's busy being a minister in Taiwan's government so generally not easy for me to consult these days.
That must be quite a timesink lol :)
> Ok, I do actually have a hilariously awful trick that manages to wrap DynaLoader to read from a Base64 encoded .so that's inlined into the fatpack but that was more a "wondering if I could" thing than something I've ever felt the urge to actually use in anger so I've (so far) resisted the siren song of CPANing it anyway because people have an unfortunate tendency to forget that I, too, release things that are terrible ideas sometimes.
Actually, I think that could be a great idea for cosmopolitan binaries!
Right now, you have to recompile perl to add the XS you want, and some don't work yet: it all depends on the build tool for the XS module being supported
So could you please tell me more about your trick? (or just link to it, I kinda get the idea but an actual example might help)
> APPerl sounds like it could be awesome
It already is: the perl.com binary is a polyglot zip file, where you can fatpack perl scripts by appending them to the zip file
If you've got 5 min, run perlplebean.com: just be careful, as by default I expose your filesystem for http requests.
Just comment out that part if you don't like it (it's meant to make people check and tweak the source)
> APPerl definitely wants to write to a non-noexec filesystem
Yes, perl.com has to be executable :)
But on Linux, you may be able to use ld-loader to run it (like how a .sh script on a nonexec fs can be run as `sh -c file.sh`)
> Either way, thank you very much for pointing out APPerl's existence to me. Even if I don't end up using it myself, having it in my mental index of available crazy things will almost certainly eventually result in my suggesting it to somebody else who'll find it the least insane way of getting the results they need :D
Sure, feel free to get in touch at my nick at outlook.com!
It's a bit strange for me to dig into perl now, while it was "current" more like 20 years ago, but I just love it!
I wasn't saying anyone seriously used that for OO. (There are still uses for tying.) But it would have been nice to have one integrated mechanism, with class syntax for high-level use and bless for low-level access. And maybe with some magic in the high-level syntax that you couldn't access with bless, like actually making members unreachable, that'd be fine. I assume it has been looked into and found to be impossible, but I'd like to know why.
Roughly, because (a) performance (b) the intention to makie it still possible to poke into an object's guts but more obvious that's what you're doing (c) if you really want the class syntax atop a classic blessed reference, p3rl.org/Object::Pad will do that if you configure the :repr (that's basically the cpan testbed for a lot of the ideas that have gone into core and written by the same LeoNerd)
sigh no, the plan now is to get something completely different into core that is fundamentally incompatible with many of the things we like about Moo. It puts up firm barriers between parent and child classes which forces all the interaction to go through methods, resulting in a huge extra API burden for authors reminiscent of Java, especially for constructors. The end result is worse performance, too.
Writing bless() yourself has only ever been advisable for low level code or as an optimisation for a couple of decades and most professional perl programmers are well aware of that.
Generally you'd use one of the M* systems - p3rl.org/Moo or p3rl.org/Mojo::Base or p3rl.org/Moose - the last one having a full metaprotocol, the other two being rather lighter weight but still with enough features to keep you relatively sane.
The new system is actually not that dissimilar to those in terms of the conceptual model even where the names and syntax are slightly different, so anybody who's been writing production OO code in the past ten years shouldn't have that much trouble switching across.
