Perl
beginners it may not be obvious to. -- Darren Duncan
I second Reverend Chip's comment. Too much what its implemented with rather
than what it does among module names. -- Darren Duncan
On 2013.06.09 8:26 PM, Reverend Chip wrote:
Might it be better simply to name the class what it does, and have its
moosey-ness go unnamed? Imagine if we started
If that was just done as part of a test suite though, and not in production, the
performance hit might be worth it. -- Darren Duncan
On 2013.05.20 3:07 PM, Chris Prather wrote:
Using the hashref directly totally circumvents moose. You would need to write
something like MooseX::Globref
Here's a good practice: Leave the attribute constraint strict all the time, and
provide a coersion functionality to examine the raw input and reformat it from
the variety of formats there might be so that it either matches the strict
definition or fails because it can't be converted. -- Darren
of misusing a type constraint is having a constraint that says this datestamp
is within 3 seconds of the current systemtime.
I think it would help clear things up if you provided more details or clarified
what you actually wanted the DBKey[User] example to achieve.
-- Darren Duncan
Darren Duncan wrote:
Type constraints are supposed to be
deterministic and not depend on variables (such as a mutable database)
to determine whether they pass or not. Another example of misusing a
type constraint is having a constraint that says this datestamp is
within 3 seconds
that ... unless one is in
the pipeline that I didn't anticipate.
4. Is Class::MOP going to gain a similar support policy to Moose's new one,
considering how closely they are associated?
-- Darren Duncan
Jesse, thank you for your quick reply.
As it is, I had also discovered
http://blog.moose.perl.org/2010/11/the-future-of-moose.html after sending my
post, although it didn't answer everything.
Jesse Luehrs wrote:
On Sat, Nov 27, 2010 at 09:10:30PM -0800, Darren Duncan wrote:
snip
4
.
Do *not* mention moose@perl.org any more in your documentation for this purpose,
and do *not* post announcements of Frost releases here any more. Those are not
an appropriate use of the Moose forum.
Go do that before you do anything else.
-- Darren Duncan
What you're talking about here sounds a lot like the class implementation method
of inside-out objects. -- Darren Duncan
Ernesto wrote:
*No Memory Leaks by Design*
The mechanism of creating, storing and loading of objects is explained
on
http://dienstleistung-kultur.de/frost/Frost.html
If it is actually warnings that you want to suppress, then Adam Kennedy's
Test::NoWarnings module may help you. It is used somewhere by the DBD::SQLite
test suite, which is how I know about it. -- Darren Duncan
for not being a
MooseX::. For example, the functionality of KiokuDB is best not in a Moose:: or
MooseX:: namespace, and indeed it isn't.
-- Darren Duncan
://github.com/dexterbt1/MooseX-DataMapper
-- Darren Duncan
, so I don't have to
divert most of my time to other work to pay the bills.)
-- Darren Duncan
Stevan Little wrote:
On May 29, 2010, at 11:20 PM, Darren Duncan wrote:
2. Besides the ability to introspect or perform powerful searches on
your objects using SQL/etc, I see another big advantage of using
database storage without serialization as portability. You can have
applications
to it risk affecting multiple applications. But not too much more so
than a shared library in Perl. That is how I see it.
-- Darren Duncan
.
-- Darren Duncan
I understand what you're saying here. No further comments from me at this time.
-- Darren Duncan
Stevan Little wrote:
On May 30, 2010, at 6:07 PM, Darren Duncan wrote:
Stevan Little wrote:
It also does not deal well with polymorphism since the ID (the
object's identity) is essentially
formats.
A relational database can map to an object structure of any language fairly
easily. Add attributes/columns for mutually heterogeneous data, like when you
would add object attributes, and add tuples/rows for mutually homogeneous data,
like when you would use arrays or sets.
-- Darren
are connecting to and what DBMS facilitates that access. -- Darren Duncan
().
-- Darren Duncan
Darren Duncan wrote:
Hello,
So I have some Perl code which has evolved over the years, which already
uses Moose, but I'm looking to make it more savvy or modern/enlightened.
And I've also found what appear to be bugs or deficiencies in Class::MOP.
The original code that I'm
or imperative, I would think that routine works best, and yet it is
specific enough to exclude a block etc. -- Darren Duncan
as an example
because that is what was used before. In practice one should still just have a
Date type and just have appropriate is-in-past conditionals in the main program
where it actually matters.
-- Darren Duncan
dependent subtype DateBefore($upper_date DateTime),
as $lower_date
type, which is the
type whose declaration allowed you to select (or construct) that value in the
first place, and any other types would not be re-introducing the value but just
using it. -- Darren Duncan
support them if Perl itself does.
-- Darren Duncan
.
And http://www.perlfoundation.org/perl5/index.cgi?gsoc_2009_projects would be a
good place to list them.
-- Darren Duncan
Yuval Kogman wrote (in private):
2009/1/19 Darren Duncan dar...@darrenduncan.net:
So, any similar hacks to help with that, prior to Moose roles being smart
enough to deal with this?
with delegation you can just put the role after the attribute declaration:
has foo = ( ..., handles = [qw(bar
the radix point (or transpose
Precision and Scale if I mixed up the meanings of those terms), then yes you
understand me correctly.
-- Darren Duncan
28 matches
Mail list logo
