develooper Front page | perl.perl5.porters | Postings from September 2013

[perl #119189] Bleadperl v5.19.2-276-g38be3d0 breaks LEONT/Const-Fast-0.014.tar.gz

Thread Previous | Thread Next
From:
Father Chrysostomos via RT
Date:
September 20, 2013 22:08
Subject:
[perl #119189] Bleadperl v5.19.2-276-g38be3d0 breaks LEONT/Const-Fast-0.014.tar.gz
Message ID:
rt-3.6.HEAD-1873-1379714882-574.119189-15-0@perl.org
On Fri Sep 20 13:02:59 2013, xdg@xdg.me wrote:
> On Wed, Aug 7, 2013 at 3:53 AM, Father Chrysostomos via RT
> <perlbug-followup@perl.org> wrote:
> > Oh no!
> >
> > These two modules are using Internals:: functions, so it is officially
> > ‘their fault’.
> >
> > To work around this, I would have to add *more* Internals:: functions
> > for constant.pm to use.  I hope I don’t have to do that.
> 
> I don't think constant.pm should have any priviledged status with
> respect to Internals.  If it can use Internals, then Internals is not
> really Internal.

constant.pm is already special though, in that it uses (and depends on)
undocumented use of stash manipulation.

> 
> I agree with Aristotle when he said this:
> 
> > … the only hope of ever getting out from under that mess is by offering
> > API based on semantics, not implementation, i.e. these functions should
> > be documented not as “sets the read-only flag” but as “makes the scalar
> > read-only”, and then likewise “makes the hash restricted” etc, and they
> > should do everything it takes to achieve whatever the docs say they do.
> >
> > The point is that each such function should be named and documented
> > after the end it achieves, not the means it uses to provide it, which
> > should be of no concern or business to its user. Only that way will
> > there ever be any hope of reducing the level of intimacy of CPAN with
> > perl’s insides to some appropriate level.
> 
> Frankly, I'd be pretty happen to have a "set_readonly" added to
> Scalar::Util (or mauve).  99% of the time I want a read-only it's a
> scalar, anyway.

I have been thinking about this for a while.  Since making something
read-only is not a common task (like blessed or refaddr), it probably
does not belong in libperl, prior art notwithstanding.  Scalar::Util is
a good place for it.  I would call it make_readonly.

(But I do want to get mauve resolved for 5.20.  I’ve been mentally
drafting a response to
<CANgJU+Vb=36TMZcqU7Ti70GV_=jUL86EhfZFFhcZKAFLy+3onQ@mail.gmail.com>,
but it hasn’t materialised yet.)

> If the semantics don't work well for arrays and
> hashes, then let's not bother.

It’s precisely the array case that is now broken for Const::Fast.

Someone suggested adding Array::Util, like Hash::Util.  That may be the
correct approach.

On the other hand, we could cheat and allow Scalar::Util::make_readonly
to take an array.

I think I prefer the former, but I’m ambivalent.

-- 

Father Chrysostomos


---
via perlbug:  queue: perl5 status: open
https://rt.perl.org:443/rt3/Ticket/Display.html?id=119189

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About