On Monday, September 26, 2011 02:02:06 Simen Kjaeraas wrote:
> On Sat, 24 Sep 2011 13:19:33 +0200, Peter Alexander
>
> <peter.alexander...@gmail.com> wrote:
> > Lazy loading and caching are the same thing.
> >
> > struct Foo
> > {
> >
> > T m_lazyObj = null;
> > bool m_isLoaded = false;
> >
> > T getObj()
> > {
> >
> > if (!m_isLoaded)
> > {
> >
> > m_lazyObj = func();
> > m_isLoaded = true;
> >
> > }
> > return m_lazyObj;
> >
> > }
> >
> > }
> >
> > Change m_lazyObj to m_cachedObj and m_isLoaded to m_isCached and you
> > have caching.
>
> This is too simple. If the system also rewrites all members to @properties
> that
> sets m_isLoaded = true, it might work. Example:
>
> struct S {
> int n;
> lazy int otherN = () { return n + 2; } // compile time error here if
> you refer to lazily initialized members.
> }
Why would that be a compile time error? otherN won't be initialized until
after n is. I suppose that it would be a problem if you tried to use otherN in
the constructor, but if that's the case, why lazily load it? We could simply
disallow the use of lazy member variables in constructors - though then you'd
have to worry about whether a lazy member variable were used in any functions
which the constructor called, so you'd probably have to disallow calling other
member functions inside of the constructors of objects with lazy member
variables. So, it does start to get a bit restrictive.
> =>
>
> struct S {
> int __n;
> int __otherN;
> bool __otherNloaded = false;
>
>
> @property
> int n( ) {
> return __n;
> }
>
> @property
> int n(int value) {
> if (__n != value) {
> __n = value;
> __otherNloaded = false;
> }
> return __n;
> }
>
> @property
> int otherN( ) {
> if (!__otherNloaded) {
> __otherN = () { return n + 2; }();
> __otherNloaded = true;
> }
> return __otherN;
> }
> }
>
> Now, the overhead might be troublesome, but this seems to me to work.
That doesn't scale, and the compiler would have to know that it need to do
that to n because the function inilializing otherN used n. I just don't think
that that's tenable. So, it may be that further restrictions would have to be
put on the initializing function for this to work, and if we do that, the idea
could quickly become too limited to be very useful. Obviously, some more
details need to be ironed out.
- Jonathan M Davis
