Skip Menu |
 

Preferred bug tracker

Please visit the preferred bug tracker to report your issue.

This queue is for tickets about the Package-Stash CPAN distribution.

Report information
The Basics
Id: 72057
Status: open
Priority: 0/
Queue: Package-Stash

People
Owner: Nobody in particular
Requestors: DAMI [...] cpan.org
ether [...] cpan.org
Cc: ribasushi [...] leporine.io
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: (no value)



Subject: over-strict rules for module names
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 802
Download (untitled) / with headers
text/plain 802b
This is not really a bug, but rather a request for change of design. The new() method only accepts package names with letters, digits and underscores (otherwise it complains "package is not a module name"). I guess that this restriction was inspired by Perl's "package" directive. However, one of the reasons for playing with symbol tables through Package::Stash or other similar modules might be precisely to get more freedom than using compile-time "package" : for example when designing private implementation classes on the fly, it can be useful to use special characters in the class name. Perl has no problem handling stashes containing @#°§:! ; if you play directly with globs and %..:: arrays, you can do it easily. So I suggest to drop that regex constraint in the new() method.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Content-Type: text/plain; charset="UTF-8"
Message-ID: <rt-3.8.HEAD-23914-1355136211-304.72057-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 41
+1 Doy - what is the holdup on this one?
MIME-Version: 1.0
In-Reply-To: <rt-3.8.HEAD-23914-1355136211-304.72057-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-3.8.HEAD-23914-1355136211-304.72057-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-29398-1430763958-141.72057-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 282
Download (untitled) / with headers
text/plain 282b
On 2012-12-10 02:43:31, RIBASUSHI wrote: Show quoted text
> +1 > > Doy - what is the holdup on this one?
I'd be happy to take over curation of this module if tuits are in short supply. I could have a go at the patch as well, although I'll need another set of eyes to tell me when I'm being dumb :)
MIME-Version: 1.0
X-Spam-Status: No, score=-5.8 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FROM_OUR_RT=-4, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
In-Reply-To: <rt-4.0.18-29398-1430763958-426.72057-5-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-72057 [...] rt.cpan.org> <rt-3.8.HEAD-23914-1355136211-304.72057-5-0 [...] rt.cpan.org> <rt-4.0.18-29398-1430763958-426.72057-5-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
content-type: text/plain; charset="utf-8"
Message-ID: <0900F069-F324-4C6A-9628-DC0929588D15 [...] tozt.net>
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.8
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=softfail (invalid, public key: does not support hash algorithm 'sha256') header.i= [...] tozt.net
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 8DA2B2403D9 for <cpan-bug+Package-Stash [...] hipster.bestpractical.com>; Mon, 4 May 2015 15:02:52 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMGaFvlgXBrY for <cpan-bug+Package-Stash [...] hipster.bestpractical.com>; Mon, 4 May 2015 15:02:51 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id AB73F24008D for <bug-Package-Stash [...] rt.cpan.org>; Mon, 4 May 2015 15:02:50 -0400 (EDT)
Received: (qmail 26876 invoked by alias); 4 May 2015 19:02:50 -0000
Received: from tozt.net (HELO mail.tozt.net) (162.216.19.228) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 04 May 2015 12:02:45 -0700
Received: from android-2713f980cc78dbb7 (pool-100-10-21-51.prvdri.fios.verizon.net [100.10.21.51]) by mail.tozt.net (Postfix) with ESMTPSA id 80CBDA1D3 for <bug-Package-Stash [...] rt.cpan.org>; Mon, 4 May 2015 15:02:41 -0400 (EDT)
Delivered-To: cpan-bug+Package-Stash [...] hipster.bestpractical.com
User-Agent: K-9 Mail for Android
Subject: Re: [rt.cpan.org #72057] over-strict rules for module names
Return-Path: <doy [...] tozt.net>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tozt.net; s=mail; t=1430766161; bh=qosahX0uC1nPK+iFVPsAxH4qlERmr/BJe+10QT7gbGM=; h=In-Reply-To:References:Subject:From:Date:To; b=rMVGBZmSXWJULubdm7EUBkt+h5W6jITR6VaW7N/sxZenHcrV+xUtOmAKo5DHAJFur eV0xR/6FKkc3X0pa39qqh6SoYbOEmeoVA4fDzr2wPwKaqzP8pKtukSw/5H2iKk1WrO BBMl0PARj8OmOcIMxrkri5u+kUQwDyDcERbulSb0=
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Package-Stash [...] hipster.bestpractical.com
X-RT-Mail-Extension: package-stash
Date: Mon, 04 May 2015 15:02:40 -0400
X-Spam-Level:
To: bug-Package-Stash [...] rt.cpan.org
Content-Transfer-Encoding: 8bit
From: Jesse Luehrs <doy [...] tozt.net>
RT-Message-ID: <rt-4.0.18-12546-1430766173-292.72057-0-0 [...] rt.cpan.org>
Content-Length: 519
Download (untitled) / with headers
text/plain 519b
I'll look at this next week. -doy On May 4, 2015 2:25:59 PM EDT, Karen Etheridge via RT <bug-Package-Stash@rt.cpan.org> wrote: Show quoted text
> Queue: Package-Stash > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=72057 > > >On 2012-12-10 02:43:31, RIBASUSHI wrote:
>> +1 >> >> Doy - what is the holdup on this one?
> >I'd be happy to take over curation of this module if tuits are in short >supply. I could have a go at the patch as well, although I'll need >another set of eyes to tell me when I'm being dumb :)
CC: ;
MIME-Version: 1.0
X-Spam-Status: No, score=-5.8 tagged_above=-99.9 required=10 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, FROM_OUR_RT=-4, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
In-Reply-To: <rt-4.0.18-12546-1430766173-838.72057-5-0 [...] rt.cpan.org>
Content-Disposition: inline
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-72057 [...] rt.cpan.org> <rt-3.8.HEAD-23914-1355136211-304.72057-5-0 [...] rt.cpan.org> <rt-4.0.18-29398-1430763958-426.72057-5-0 [...] rt.cpan.org> <0900F069-F324-4C6A-9628-DC0929588D15 [...] tozt.net> <rt-4.0.18-12546-1430766173-838.72057-5-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <20150513023917.GE8009 [...] lance>
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.8
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=softfail (invalid, public key: does not support hash algorithm 'sha256') header.i= [...] tozt.net
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id A27762403BC for <cpan-bug+Package-Stash [...] hipster.bestpractical.com>; Tue, 12 May 2015 22:39:59 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTXATOmrvTFh for <cpan-bug+Package-Stash [...] hipster.bestpractical.com>; Tue, 12 May 2015 22:39:58 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id C329F240064 for <bug-Package-Stash [...] rt.cpan.org>; Tue, 12 May 2015 22:39:57 -0400 (EDT)
Received: (qmail 28750 invoked by alias); 13 May 2015 02:39:56 -0000
Received: from tozt.net (HELO mail.tozt.net) (162.216.19.228) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Tue, 12 May 2015 19:39:55 -0700
Received: from localhost (unknown [207.251.103.46]) by mail.tozt.net (Postfix) with ESMTPSA id EAFF7A1D3 for <bug-Package-Stash [...] rt.cpan.org>; Tue, 12 May 2015 22:39:50 -0400 (EDT)
Delivered-To: cpan-bug+Package-Stash [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #72057] over-strict rules for module names
User-Agent: Mutt/1.5.23 (2014-03-12)
Return-Path: <doy [...] tozt.net>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tozt.net; s=mail; t=1431484791; bh=FBVEU4m1Kgm+bmorFJiNBTumIQPAuA9S67fZsMgLsgA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=b4ju/X0sPko5957k2IUYasplL+U/YOgRw5MiBM0JT1v0g/WpPpsgIuWfXUtuIgmsV YFqqJ8Kg9kzN2xgTH/jIfn2hp04L6erGArEQQ1Od9RHE+lTyS7Mpip7PFRGLPqt9k+ woVCwRSWEXPmMvQkONpBpvANoYMUBBMPKaRwxjMg=
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Package-Stash [...] hipster.bestpractical.com
X-RT-Mail-Extension: package-stash
Date: Tue, 12 May 2015 22:39:17 -0400
X-Spam-Level:
To: Jesse Luehrs via RT <bug-Package-Stash [...] rt.cpan.org>
From: Jesse Luehrs <doy [...] tozt.net>
RT-Message-ID: <rt-4.0.18-32591-1431484800-824.72057-0-0 [...] rt.cpan.org>
Content-Length: 999
Download (untitled) / with headers
text/plain 999b
So, one concern I have is, if we are going to allow everything, what about stash entries that contain `::`? Right now, Package::Stash->new("Foo::Bar") creates %::{Foo}{Bar}, but how would you create %::{'Foo::Bar'}? It seems weird to allow everything else except for that. On Mon, May 04, 2015 at 03:02:53PM -0400, Jesse Luehrs via RT wrote: Show quoted text
> Queue: Package-Stash > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=72057 > > > I'll look at this next week. > > -doy > > On May 4, 2015 2:25:59 PM EDT, Karen Etheridge via RT <bug-Package-Stash@rt.cpan.org> wrote:
> > Queue: Package-Stash > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=72057 > > > > >On 2012-12-10 02:43:31, RIBASUSHI wrote:
> >> +1 > >> > >> Doy - what is the holdup on this one?
> > > >I'd be happy to take over curation of this module if tuits are in short > >supply. I could have a go at the patch as well, although I'll need > >another set of eyes to tell me when I'm being dumb :)
> >
MIME-Version: 1.0
X-Spam-Status: No, score=-5.999 tagged_above=-99.9 required=10 tests=[AWL=0.600, BAYES_00=-1.9, FREEMAIL_FROM=0.001, FROM_OUR_RT=-4, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-32591-1431484800-847.72057-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-72057 [...] rt.cpan.org> <rt-3.8.HEAD-23914-1355136211-304.72057-5-0 [...] rt.cpan.org> <rt-4.0.18-29398-1430763958-426.72057-5-0 [...] rt.cpan.org> <0900F069-F324-4C6A-9628-DC0929588D15 [...] tozt.net> <rt-4.0.18-12546-1430766173-838.72057-5-0 [...] rt.cpan.org> <20150513023917.GE8009 [...] lance> <rt-4.0.18-32591-1431484800-847.72057-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <5556FF58.6030003 [...] free.fr>
content-type: text/plain; charset="utf-8"; format="flowed"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -5.999
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 366952403D7 for <cpan-bug+Package-Stash [...] hipster.bestpractical.com>; Sat, 16 May 2015 04:27:15 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TlCIXBU6eTK for <cpan-bug+Package-Stash [...] hipster.bestpractical.com>; Sat, 16 May 2015 04:27:13 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 7A9AE2402F4 for <bug-Package-Stash [...] rt.cpan.org>; Sat, 16 May 2015 04:27:13 -0400 (EDT)
Received: (qmail 27916 invoked by alias); 16 May 2015 08:27:12 -0000
Received: from smtp5-g21.free.fr (HELO smtp5-g21.free.fr) (212.27.42.5) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Sat, 16 May 2015 01:27:09 -0700
Received: from [192.168.0.10] (unknown [81.56.173.79]) by smtp5-g21.free.fr (Postfix) with ESMTP id 73432D48035; Sat, 16 May 2015 10:23:12 +0200 (CEST)
Delivered-To: cpan-bug+Package-Stash [...] hipster.bestpractical.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
Subject: Re: [rt.cpan.org #72057] over-strict rules for module names
Return-Path: <laurent.dami [...] free.fr>
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Package-Stash [...] hipster.bestpractical.com
X-RT-Mail-Extension: package-stash
Date: Sat, 16 May 2015 10:27:04 +0200
X-Spam-Level:
To: bug-Package-Stash [...] rt.cpan.org, DAMI [...] cpan.org, ether [...] cpan.org
Content-Transfer-Encoding: 8bit
From: Laurent Dami <laurent.dami [...] free.fr>
RT-Message-ID: <rt-4.0.18-16822-1431764836-1060.72057-0-0 [...] rt.cpan.org>
Content-Length: 889
Download (untitled) / with headers
text/plain 889b
My original request was to be able to create namespaces such as Package::Stash->new("Foo<=>Bar"). I use such "strange names" for automatic classes generated by DBIx::DataModel, but there are other modules with similar techniques (like for example the strange namespaces used by overload.pm). The special case "Foo::Bar" should remain as it is, for obvious reasons of backwards compatibility and playing nicely with other perl namespace features. Thanks in advance, Laurent Dami Le 13.05.2015 04:40, Jesse Luehrs via RT a écrit : Show quoted text
> <URL: https://rt.cpan.org/Ticket/Display.html?id=72057 > > > So, one concern I have is, if we are going to allow everything, what > about stash entries that contain `::`? Right now, > Package::Stash->new("Foo::Bar") creates %::{Foo}{Bar}, but how would you > create %::{'Foo::Bar'}? It seems weird to allow everything else except > for that. > >
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-32591-1431484800-824.72057-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-72057 [...] rt.cpan.org> <rt-3.8.HEAD-23914-1355136211-304.72057-5-0 [...] rt.cpan.org> <rt-4.0.18-29398-1430763958-426.72057-5-0 [...] rt.cpan.org> <0900F069-F324-4C6A-9628-DC0929588D15 [...] tozt.net> <rt-4.0.18-12546-1430766173-838.72057-5-0 [...] rt.cpan.org> <20150513023917.GE8009 [...] lance> <rt-4.0.18-32591-1431484800-824.72057-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-9053-1432231519-233.72057-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2514
Download (untitled) / with headers
text/plain 2.4k
On Tue May 12 22:40:00 2015, doy@tozt.net wrote: Show quoted text
> So, one concern I have is, if we are going to allow everything, what about > stash entries that contain `::`? Right now, Package::Stash->new("Foo::Bar") > creates %::{Foo}{Bar}, but how would you create %::{'Foo::Bar'}? It seems > weird to allow everything else except for that.
Perl does not allow you to refer to such entries by any “normal” means (i.e. symbolic references etc). The only way to get back to them is by lookup in the stash hash and properly dereferencing the resulting glob value. That’s pretty useless. So for most users this will be a trap and/or a nuisance to work around, not a useful feature. In fact I’m pretty sure that *most* of them will expect to get `%::{Foo}{Bar}` when they give you `Foo::Bar`. If you want to ensure the interface is completely regular in case that should ever be needed, maybe allow passing an arrayref instead of a string, and when the caller does that, use the elements as nested stash names, verbatim. Then the answer to your question would be `Package::Stash->new(["Foo::Bar"]`). (And `Package::Stash->new("Foo::Bar")` or `Package::Stash->new(["Foo","Bar"])` would be the ways to produce `%::{Foo}{Bar}`.) But giving someone `%::{'Foo::Bar'}` when they didn’t ask for that in a very explicit way would be a very shitty default. It is certain to be surprising and inconvenient to almost every user of the module. Not surprising in the sense of “I didn’t know it was going to do that” (obviously the behaviour ought to be documented clearly) but in the sense of “after using Package::Stash for a while in simple cases and never having to think about that issue, I totally forgot I had to watch out for that”. Also, of course: backcompat. (Which is probably the first thing I should have brought up.) There is already code that uses Package::Stash, which very much shouldn’t suddenly change meaning. Making people request fully verbatim package names by way of an arrayref would make it unambiguous what semantics they expect when passing a string, which would otherwise differ between existing code and newly written code. Turns out, though, once you’ve come that far, you can just punt on the matter. YAGNI etc, since if someone does ever need it, you can then implement the pass-arrayref-for-fully-verbatim semantics without any break in backcompat. So there is no need to implement that until the day it’s needed. And that day may never come. Does that alleviate your concern?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.