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 an object. 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 presentation. It is NOT TRUE that uninterpolated strings are always for storage. Both can be used either way, and in practice are used both ways. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
