On 2013-11-13 20:38, David Mertens wrote:
I second Brian's opinion. I would offer also Types::Core as a
potential name for the module.
As for the ref checking, what if I pass a plain scalar? In that case,
I seem to recall that ref($plain_scalar) will be undef, in which case
comparing it to a string with the eq operator will issue a warning,
right? To avoid that warnings, I uUsually articulate this check like so:
ARRAY $scalar returns undef as one would expect (and no warnings).
So below becomes
if (ARRAY $to_check) { #EVEN if the array is a blessed object
code
}
If $hashref is undef returns undef (no warnings).
# Check against ARRAY
if (ref($to_check) and ref($to_check) eq ref([])) {
��� ... code here ...
}
Same with the special function "EhV"
EhV $hash, bareword === exists $hash->{value} ?
$hash($value) : undef;
(or) EhV($hash, $var)... etc.
I might not find Types::Core to be misleading or "off topic"...it might be
better, would have to think about it...
David
On Wed, Nov 13, 2013 at 10:42 PM, Brian Katzung <bri...@kappacs.com
<mailto:bri...@kappacs.com>> wrote:
If my understanding is correct and these are only for built-in
types, how about Types::BuiltIn or Types::Perl (cf Types::Numbers
and Types::CLike)?
While I'm at it, I think "P" is OK as an export, but I think even
"IO::P" would have been a more descriptive module name and perhaps
more likely to be found.
well the words 'safer printf, print, sprintf & say' are in the subject,
It can 'just'
do formatting (while checking not to throw undef warnings), so it
doesn't have
to do IO..... but 3/4 of it's top level functions involve I/O. Where
it also comes
in handy is in printing "refs"... instead of the 'ref'-value+hex, it
prints the first
level or two of the reference -- mainly a devel/debug aid -- not so much
for
end-users.
Try printing [undef] with any of the standard functions -- won't work, but P
will just print [∄] (a backwards E w/diag, so only 1 space -- math symbol
for "there does not exist". ;-)
� - Brian
On 2013-11-13 18:46, David Mertens wrote:
Linda -
I think that you got feedback that you did not even ask for: a
clear response from the module-authors community to not name your
module Types. Might I suggest Types::LAW. Obviously, LAW are your
initials, but it also lets you brag about laying down the LAW for
type constraints. :-)
David
On Wed, Nov 13, 2013 at 2:29 PM, Aristotle Pagaltzis
<pagalt...@gmx.de <mailto:pagalt...@gmx.de>> wrote:
* Linda A. Walsh <perl-didd...@tlinx.org
<mailto:perl-didd...@tlinx.org>> [2013-11-13 16:20]:
> Unclear as to problem: Tried to register 'Types', but says
can't due
> to unrelated module.
And that didn�t make you stop and wonder, if you thought that
this other
author should not have claimed that namespace, that maybe the
same could
be thought of yourself by someone else?
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
--
�"Debugging is twice as hard as writing the code in the first place.
� Therefore, if you write the code as cleverly as possible, you are,
� by definition, not smart enough to debug it." -- Brian Kernighan
--
Brian Katzung, Kappa Computer Solutions, LLC
Software development and mixed operating system support
for business, education, and science
Phone: 847.412.0713 <tel:847.412.0713> http://www.kappacs.com
--
�"Debugging is twice as hard as writing the code in the first place.
� Therefore, if you write the code as cleverly as possible, you are,
� by definition, not smart enough to debug it." -- Brian Kernighan
