On Friday, 10 October 2014 at 22:34:45 UTC, ketmar via
Digitalmars-d wrote:
On Fri, 10 Oct 2014 21:45:32 +0000
Shouldn't properties not mutate the data?
it depends. ;-) i think that doing such "lazy initialization" in
property is acceptable. maybe not the best style, but
acceptable. yet i
may be wrong, of course.
Ah, I see. Lazy initialization is a nice approach to some things.
But I'm not entirely sure it belongs in the structure or object
itself.. however, if I were too I might put it in a 'length' or
'rezise' member function.. but that'd be better for a resizable
object..
better methods to doing it safely, for sure. But to do the
same with only a single pointer?
why do you insisting on having single pointer? sure you can use
all
sort of tricks to pack alot of data in single pointer, but i
can't see
any practical sense in it. today when smartphones have
gigabytes of
RAM, i'll trade some more pointers for ease of using and safety.
Actually, I think memory efficiency and speed are pretty key
today, especially with embedded systems, server farms, and mobile
devices. And it doesn't just have to do with available memory,
but cache lines, register usage, etc. But that's another debate
for another time.
As far as the safety tradeoff though.. I prevent copying and
default construction, so at least two problems should
theoretically be solved. The possibility of using ranges or
pointers outside of the function or scope is the only thing that
would need to be controlled for. And there I suppose the GC or
reference counting mechanisms would be the only other options.
But hopefully if I document it right, and suggest the correct
alternatives to use, I can prevent careless programmers from
making those mistakes. (I think std.container.array.Array is a
nice fallback)
ah, yes, it's "Voldemort type". ;-)
Ah, I had wondered why/where/what context I heard that under!
Makes more sense now. =)
Also, thanks for the other pointers (I didnt quote everything
here)
