On Thu, 29 Sep 2011 20:14:01 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 29/09/11 8:01 PM, Steven Schveighoffer wrote:
Again, I ask, what is a real-world example of something that needs lazy
caching (or where lazy caching significantly helps performance) for
comparison. You
Steven Schveighoffer , dans le message (digitalmars.D:145812), a écrit :
What we are discussing is why opEquals should not be const, not why all
functions should not be const.
Considering the viral behavior of const in D, we are discussing why all
function callable from opEqual should be
On Fri, 30 Sep 2011 09:39:42 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145812), a écrit
:
What we are discussing is why opEquals should not be const, not why all
functions should not be const.
Considering the viral behavior
What I think we need is to make the free function opEquals a template,
which only instantiates for objects, and then the lhs.opEquals(rhs) and
rhs.opEquals(lhs) will take full advantage of any overloaded opEquals.
For example, if you wanted to overload for non-const objects. But I think
On Fri, 30 Sep 2011 10:53:50 -0400, Christophe
trav...@phare.normalesup.org wrote:
What I think we need is to make the free function opEquals a template,
which only instantiates for objects, and then the lhs.opEquals(rhs) and
rhs.opEquals(lhs) will take full advantage of any overloaded
On Thursday, September 29, 2011 01:08:31 Peter Alexander wrote:
On 26/09/11 6:57 PM, Jonathan M Davis wrote:
On Monday, September 26, 2011 10:26 Steven Schveighoffer wrote:
I still don't think this proposal (even one that always lazily
initializes) gives enough benefit to be included. Why
Am 26.09.2011, 18:12 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
For example, storing a reference to a mutex in an object, or a reference
to an owner object. It's the difference between a has a relationship
and a points
On 29/09/11 8:13 AM, Marco Leise wrote:
Am 26.09.2011, 18:12 Uhr, schrieb Jonathan M Davis jmdavisp...@gmx.com:
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
For example, storing a reference to a mutex in an object, or a reference
to an owner object. It's the difference
Immutable is a guarantee, that no mutable reference can be obtained on
the object from any reference (I don't take into account casting it
away, because that's not guaranteed to make the object actually
mutable).
Const is a guarantee that, no mutable reference can be obtained from
this particular
Steven Schveighoffer Wrote:
I think it's worth trying to do. All I was saying is, the language is not
going to help you out on that.
As you can see, language support is not required to implement logical const
anyway.
On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to not have logical const in D provided that the
On Wed, 28 Sep 2011 17:09:59 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, September 28, 2011 13:56 Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis
jmdavisp...@gmx.com
wrote:
On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
On Wed, 28 Sep 2011 20:11:51 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 26/09/11 8:02 PM, Steven Schveighoffer wrote:
I think a better avenue would be to implement some sort of strong-pure
memoization system. Then all you have to do is make an immutable pure
member, and
On 09/29/2011 01:33 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to
On Thu, 29 Sep 2011 04:12:01 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 29/09/11 8:13 AM, Marco Leise wrote:
Am 26.09.2011, 18:12 Uhr, schrieb Jonathan M Davis
jmdavisp...@gmx.com:
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
For example, storing
Steven Schveighoffer , dans le message (digitalmars.D:145729), a
I was arguing that opEquals (and co.) should *not* be const. IMO it
would be a huge problem if they were.
why? For what purpose do you need to change an object during comparison?
You may not need to change the object, but
On Thu, 29 Sep 2011 09:32:06 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145729), a
I was arguing that opEquals (and co.) should *not* be const. IMO it
would be a huge problem if they were.
why? For what purpose do you need
Steven Schveighoffer , dans le message (digitalmars.D:145738), a
It is always possible for a non-const version of opEqual to forward to
the const version, so people willing to use a const version do not have
to define a non-const version.
Again, you still need to define both, this is not a
On Thu, 29 Sep 2011 11:09:13 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145738), a
It is always possible for a non-const version of opEqual to forward to
the const version, so people willing to use a const version do not have
On 9/29/11 8:38 AM, Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 11:09:13 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145738), a
It is always possible for a non-const version of opEqual to forward to
the const version, so
On Thu, 29 Sep 2011 11:45:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/29/11 8:38 AM, Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 11:09:13 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145738), a
On Thu, 29 Sep 2011 13:20:21 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/29/11 10:15 AM, Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 11:45:18 -0400, Andrei Alexandrescu
seewebsiteforem...@erdani.org wrote:
On 9/29/11 8:38 AM, Steven Schveighoffer wrote:
On
On 29/09/11 12:33 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to
On Thu, 29 Sep 2011 13:50:54 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 29/09/11 12:37 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 20:11:51 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 26/09/11 8:02 PM, Steven Schveighoffer wrote:
I think a
On Thursday, September 29, 2011 04:36 Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 17:09:59 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, September 28, 2011 13:56 Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis
jmdavisp...@gmx.com
On Thursday, September 29, 2011 10:50 Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
The comparison may involve comparing a sub-object that is lazily
created. It could also involve computing a cached perfect hash for
faster comparison, requiring memoization.
On Thursday, September 29, 2011 10:48 Peter Alexander wrote:
On 29/09/11 12:33 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
Andrei says that it will (in a way) be both, so I'm happy with that.
I haven't seen that statement.
I can't find it, but
Am 29.09.2011, 10:12 Uhr, schrieb Peter Alexander
peter.alexander...@gmail.com:
Why would a car be able mutate it's vendor?
A car is a passive object, that's obvious. Of course it doesn't mutate the
vendor and if it did, *mutate* doesn't mean the vendor can be robbed by
the car or
On 29/09/11 6:50 PM, Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 29/09/11 12:33 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 19:21:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 26/09/11
On Thu, 29 Sep 2011 14:45:13 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 29, 2011 10:50 Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
The comparison may involve comparing a sub-object that is lazily
created. It could also
On Thu, 29 Sep 2011 14:59:25 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 29/09/11 6:50 PM, Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 13:48:02 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
On 29/09/11 12:33 PM, Steven Schveighoffer wrote:
On Wed, 28 Sep
On Thu, 29 Sep 2011 14:45:24 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 29, 2011 04:36 Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 17:09:59 -0400, Jonathan M Davis
jmdavisp...@gmx.com
wrote:
On Wednesday, September 28, 2011 13:56 Steven Schveighoffer
On Thursday, September 29, 2011 08:45:18 Andrei Alexandrescu wrote:
If we make this change we're liable to break all code that defines
opEquals for classes.
Two versions should be enough: const/const and mutable/mutable, which by
default forwards to const/const. Old code will run unchanged
On Thursday, September 29, 2011 15:05:56 Steven Schveighoffer wrote:
If all the data the calculated value depends on is immutable, then the two
threads loading the value at the same time will be loading the same
value. If you're writing a 42 to an int from 2 threads, there is no
deadlock or
On Thursday, September 29, 2011 14:55:37 Steven Schveighoffer wrote:
I think the caching/lazy loading *specifically for opEquals* has been
blown way out of proportion. I don't think I've ever written one which
requires caching to be efficient.
Caching is non-issue. It's just less efficient if
On Thursday, September 29, 2011 16:01:05 Steven Schveighoffer wrote:
On Thu, 29 Sep 2011 15:23:18 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 29, 2011 15:05:56 Steven Schveighoffer wrote:
If all the data the calculated value depends on is immutable, then the
On Thu, 29 Sep 2011 15:23:18 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Thursday, September 29, 2011 15:05:56 Steven Schveighoffer wrote:
If all the data the calculated value depends on is immutable, then the
two
threads loading the value at the same time will be loading the
On 29/09/11 8:01 PM, Steven Schveighoffer wrote:
Again, I ask, what is a real-world example of something that needs lazy
caching (or where lazy caching significantly helps performance) for
comparison. You have already stated that you appreciate it's not const,
so you must have *something* that
Steven Schveighoffer , dans le message (digitalmars.D:145415), a
écrit :
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to not have logical const in D provided that the Object
interface (and other similar interfaces) don't require that
Jonathan M Davis , dans le message (digitalmars.D:145479), a écrit :
But since lazy initializion will _never_ work with immutable
Never say never. One could build a clean and thread-safe way to lazily
initialize fields. Like someone said, even without mutex, if the
function to compute the
On Wed, 28 Sep 2011 06:22:14 -0400, Christophe
trav...@phare.normalesup.org wrote:
Steven Schveighoffer , dans le message (digitalmars.D:145415), a
écrit :
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to not have logical const in D
Jonathan M Davis Wrote:
Some programmers have expressed annoyance and/or disappointment that there is
no logical const of any kind in D.
isn't it trivial?
void setConst(T1,T2)(ref T1 dst, in T2 src)
{
*cast()dst=src;
}
const int v;
setConst(v,5);
assert(v==5);
On Wed, 28 Sep 2011 10:52:24 -0400, Kagamin s...@here.lot wrote:
Jonathan M Davis Wrote:
Some programmers have expressed annoyance and/or disappointment that
there is
no logical const of any kind in D.
isn't it trivial?
void setConst(T1,T2)(ref T1 dst, in T2 src)
{
*cast()dst=src;
}
Steven Schveighoffer Wrote:
Trivial, and also undefined behavior ;)
Well, it gets job done. If you don't like it, don't use logical const.
On Wed, 28 Sep 2011 11:55:01 -0400, Kagamin s...@here.lot wrote:
Steven Schveighoffer Wrote:
Trivial, and also undefined behavior ;)
Well, it gets job done. If you don't like it, don't use logical const.
It's not a matter of whether I don't like it or not. Undefined behavior
means
On Wed, 28 Sep 2011 18:00:39 +0200, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 28 Sep 2011 11:55:01 -0400, Kagamin s...@here.lot wrote:
Steven Schveighoffer Wrote:
Trivial, and also undefined behavior ;)
Well, it gets job done. If you don't like it, don't use logical const.
On Wed, 28 Sep 2011 21:58:20 +0200, Martin Nowak d...@dawgfoto.de wrote:
On Wed, 28 Sep 2011 18:00:39 +0200, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Wed, 28 Sep 2011 11:55:01 -0400, Kagamin s...@here.lot wrote:
Steven Schveighoffer Wrote:
Trivial, and also undefined behavior
On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
Jonathan M Davis , dans le message (digitalmars.D:145479), a écrit :
But since lazy initializion will _never_ work with immutable
Never say never. One could build a clean and thread-safe way to lazily
initialize fields. Like
On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
Jonathan M Davis , dans le message (digitalmars.D:145479), a écrit :
But since lazy initializion will _never_ work with immutable
Never say never. One
On Wednesday, September 28, 2011 13:56 Steven Schveighoffer wrote:
On Wed, 28 Sep 2011 16:03:51 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Wednesday, September 28, 2011 11:31:31 Christophe wrote:
Jonathan M Davis , dans le message (digitalmars.D:145479), a écrit :
But since
On 26/09/11 12:52 PM, Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to not have logical const in D provided that the Object
interface (and other similar interfaces) don't require that opEquals
is const or any
On 26/09/11 6:57 PM, Jonathan M Davis wrote:
On Monday, September 26, 2011 10:26 Steven Schveighoffer wrote:
I still don't think this proposal (even one that always lazily
initializes) gives enough benefit to be included. Why would you want a
constant lazily-initialized value in a non-immutable
On 26/09/11 8:02 PM, Steven Schveighoffer wrote:
I think a better avenue would be to implement some sort of strong-pure
memoization system. Then all you have to do is make an immutable pure
member, and the compiler will take care of the rest for you.
How can the compiler possibly figure out
On 09/26/2011 02:46 AM, Walter Bright wrote:
On 9/23/2011 9:11 PM, Jonathan M Davis wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical
reasons why
it can't be done or is unreasonable.
Andrei and I
On Sat, 24 Sep 2011 07:19:33 -0400, Peter Alexander
peter.alexander...@gmail.com wrote:
I'm happy to not have logical const in D provided that the Object
interface (and other similar interfaces) don't require that opEquals is
const or any nonsense like that. const means physical const, and
On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical
reasons why
it can't be done or is unreasonable.
Some programmers
On Mon, 26 Sep 2011 13:01:29 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis
6. If the S being constructed is shared or immutable and __varProp is
not
called in the constructor, then __varProp is called immediately after
the
On Mon, 26 Sep 2011 16:44:29 +0200, Simen Kjaeraas
simen.kja...@gmail.com wrote:
On Mon, 26 Sep 2011 02:19:29 +0200, Jonathan M Davis
jmdavisp...@gmx.com wrote:
Oh, and of course more stuff is need if you try to make this work
across
threads.
The threading issue is exactly why I
On Mon, 26 Sep 2011 02:18:30 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
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
{
On Mon, 26 Sep 2011 02:19:29 +0200, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Oh, and of course more stuff is need if you try to make this work across
threads.
The threading issue is exactly why I suggested that objects which are
constructed as shared automatically have the property
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical
On Monday, September 26, 2011 10:35:29 Steven Schveighoffer wrote:
On Mon, 26 Sep 2011 09:44:31 -0400, Regan Heath re...@netmail.co.nz
wrote:
On Mon, 26 Sep 2011 13:01:29 +0100, Steven Schveighoffer
schvei...@yahoo.com wrote:
On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis
On Mon, 26 Sep 2011 12:12:30 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis
jmdavisp...@gmx.com
wrote:
Okay. I'm not saying that we should necessarily implement
On Monday, September 26, 2011 10:26 Steven Schveighoffer wrote:
On Mon, 26 Sep 2011 12:12:30 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, September 26, 2011 08:01:29 Steven Schveighoffer wrote:
On Sat, 24 Sep 2011 00:11:52 -0400, Jonathan M Davis
jmdavisp...@gmx.com
On Mon, 26 Sep 2011 13:57:04 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, September 26, 2011 10:26 Steven Schveighoffer wrote:
On Mon, 26 Sep 2011 12:12:30 -0400, Jonathan M Davis
jmdavisp...@gmx.com
wrote:
The point is that if aren't using immutable or shared, then you
On Mon, 26 Sep 2011 15:02:24 -0400, Steven Schveighoffer
schvei...@yahoo.com wrote:
I think a better avenue would be to implement some sort of strong-pure
memoization system. Then all you have to do is make an immutable pure
member, and the compiler will take care of the rest for you.
On Monday, September 26, 2011 12:02 Steven Schveighoffer wrote:
On Mon, 26 Sep 2011 13:57:04 -0400, Jonathan M Davis jmdavisp...@gmx.com
wrote:
On Monday, September 26, 2011 10:26 Steven Schveighoffer wrote:
On Mon, 26 Sep 2011 12:12:30 -0400, Jonathan M Davis
jmdavisp...@gmx.com
On 24/09/11 6:53 PM, Timon Gehr wrote:
On 09/24/2011 07:21 PM, Peter Alexander wrote:
On 24/09/11 12:47 PM, Jonathan M Davis wrote:
On Saturday, September 24, 2011 12:19:33 Peter Alexander wrote:
Lazy loading and caching are the same thing.
No. Caching is more general. Lazy loading is
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 =
On Mon, 26 Sep 2011 02:02:06 +0200, Simen Kjaeraas
simen.kja...@gmail.com 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;
On Monday, September 26, 2011 02:03:23 Simen Kjaeraas wrote:
On Mon, 26 Sep 2011 02:02:06 +0200, Simen Kjaeraas
simen.kja...@gmail.com 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.
On 9/23/2011 9:11 PM, Jonathan M Davis wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical reasons why
it can't be done or is unreasonable.
Andrei and I talked about this some time back. Where it ran
On Sunday, September 25, 2011 17:46:00 Walter Bright wrote:
On 9/23/2011 9:11 PM, Jonathan M Davis wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical
reasons why it can't be done or is
On 2011-09-24 06:11, Jonathan M Davis wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical reasons why
it can't be done or is unreasonable.
Some programmers have expressed annoyance and/or
On 24/09/11 5:11 AM, Jonathan M Davis wrote:
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical reasons why
it can't be done or is unreasonable.
Some programmers have expressed annoyance and/or
On Saturday, September 24, 2011 12:19:33 Peter Alexander wrote:
Lazy loading and caching are the same thing.
No. Caching is more general. Lazy loading is explicitly one load and has
different characteristics, whereas is caching can have multiple loads.
struct Foo
{
T m_lazyObj = null;
On 24/09/11 12:47 PM, Jonathan M Davis wrote:
On Saturday, September 24, 2011 12:19:33 Peter Alexander wrote:
Lazy loading and caching are the same thing.
No. Caching is more general. Lazy loading is explicitly one load and has
different characteristics, whereas is caching can have multiple
On 09/24/2011 07:21 PM, Peter Alexander wrote:
On 24/09/11 12:47 PM, Jonathan M Davis wrote:
On Saturday, September 24, 2011 12:19:33 Peter Alexander wrote:
Lazy loading and caching are the same thing.
No. Caching is more general. Lazy loading is explicitly one load and has
different
Okay. I'm not saying that we should necessarily implement this. I'm just
looking to air out an idea here and see if there are any technical reasons why
it can't be done or is unreasonable.
Some programmers have expressed annoyance and/or disappointment that there is
no logical const of any
79 matches
Mail list logo
