Object design/structure with sub-objects (Moose)

[Cagao]

Hi Monks

I have objects that get data from a db, very simple, a few columns, some of which are datetime's.

Now, in my code, I'd like to use a DateTime object wherever I store a datetime field from the DB, this make it easy to always know that if an object attribute is a date/time, i can immediately use all the DateTime methods on it.

Even better for when these objects appear in templates and I can simply send my front-end team to read about DateTime->strftime without having to do anything bespoke.

Unfortunately this can cause a performance hit if i'm getting 100,000 rows from the DB and instantiating an object for each one, if they each have 2 datetime stamps.

So what may you suggest? I'm currently thinking about a private attribute to store the literal datetime value, then a lazily-built attribute to convert to a DateTime if and when needed.

Alternatively, since I may SOMETIMES want to display the literal value (think a basic admin page somewhere), 2 methods, one for $foo->date_added (literal), and one for $foo->date_added_DATETIME.

I'm aiming to use a similar approach for Emails (using Email::Address) and URLs (using URI).

I'm not sure if Moose allows for this sort of approach, I'm nearly thinking Traits? Do I need to go down the route of my own Type, and can that Type have 2 internal representations?

Any input greatly appreciated...

[moritz]

Moose has lazy attributes that do what you want (if I understood your question correctly), see Moose::Manual::Attributes (search for "lazy").

But if performance is a big concern to you, you should evaluate if Moose doesn't slow you down too much. Hand-coding lazy attributes isn't all that difficult.

use 5.010; # for //=, but can be rewritten without it

sub lazy_foo {
   $_[0]->{lazy_foo} //= $_[0]->construct_foo;
}

[Cagao]

Cheers for the input.

Yeah, the lazy-build approach was my first thought, and it would work easily without making things too complicated.

I don't think Moose's implementation of lazy-build would be an issue, performance-wise, so would use their method rather than rolling my own.