Ashley Winters skribis 2005-09-25 12:26 (-0700):
> It's not a Date, it's a UnixEpochTimestamp.
That is precisely the flaw. Are you honestly likely to have that class?
If you really need an unix epoch timestamp, wouldn't you just use a very
simple integer for that? Because that's what it *is*, by definition. Not
And having an epoch timestamp stringify (or interpolate, which as far as
I will accept leads to stringification) as anything other than what it
is, an integer, is pure nonsense.
> > > my Thingy $foo .=from($thing);
> > my Thingy $foo = eval($thing.perl);
> eval() itself feels like the wrong function for doing this. I'm trying
> to parse(), not eval().
Neither names are good. Parsing isn't the only thing you want to do, and
eval is for executable code that is in a string, not for serialized data.
I suggest that we keep data and code separate and use thaw and eval
respectively. Also, this means that .perl shouldn't be used for storing
objects, at most it should be used for demonstration and debugging.
Let's not forget freeze.
Objects are both code and data, and thus hard. We may have to consider
it all code.
> say "The Unix Epoch Timestamp is $time" --> The Unix Epoch Timestamp
> is 1234567890
I thought you wanted it to interpolate as a well formatted,
human-readable date? Don't you mean `~ $time` here? Wow, separating
stringification and interpolation really IS confusing!
It is NOT TRUE that strings with variables interpolated are always for
It is NOT TRUE that uninterpolated strings are always for storage.
Both can be used either way, and in practice are used both ways.