"Walter Bright" wrote in message news:m78i71$1c2h$1...@digitalmars.com...
It all depends on how invariant is defined. It's defined as an invariant
on what it owns, not whatever is referenced by the object.
Whether or not it owns the data it references is application specific.
Where are you s
On 12/21/2014 11:18 PM, Daniel Murphy wrote:
"Walter Bright" wrote in message news:m753hk$pt2$1...@digitalmars.com...
Invariants should be checking the state of the object that it owns, not other
objects. I would consider such an invariant invalid.
What? No.
This is a perfectly valid use o
"Walter Bright" wrote in message news:m753hk$pt2$1...@digitalmars.com...
Invariants should be checking the state of the object that it owns, not
other objects. I would consider such an invariant invalid.
What? No.
This is a perfectly valid use of invariants:
class A
{
B b;
invariant(
On 12/21/14 8:49 AM, Steven Schveighoffer wrote:
Sorry for the double post, my mailer had issues...
-Steve
On 12/20/14 10:24 PM, Walter Bright wrote:
On 12/20/2014 7:11 PM, Steven Schveighoffer wrote:
Wouldn't a tree own its nodes?
I've replied to this repeatedly. Think of a symbol table tree, in which
symbols are looked up. References to found symbols are then inserted
into the AST.
But doesn't
On 12/20/14 10:24 PM, Walter Bright wrote:
On 12/20/2014 7:11 PM, Steven Schveighoffer wrote:
Wouldn't a tree own its nodes?
I've replied to this repeatedly. Think of a symbol table tree, in which
symbols are looked up. References to found symbols are then inserted
into the AST.
But doesn't
On 12/20/2014 7:11 PM, Steven Schveighoffer wrote:
Wouldn't a tree own its nodes?
I've replied to this repeatedly. Think of a symbol table tree, in which symbols
are looked up. References to found symbols are then inserted into the AST.
Building a language design that REQUIRES ownership of a
On 12/20/14 7:16 PM, Walter Bright wrote:
On 11/17/2014 11:58 PM, Rainer Schuetze wrote:
I remember having an invariant on a tree structure checking
consistency by
verifying the children and parent references. This crashed when adding a
destructor. With the proposed change it will always crash.
On 11/17/2014 11:58 PM, Rainer Schuetze wrote:
I remember having an invariant on a tree structure checking consistency by
verifying the children and parent references. This crashed when adding a
destructor. With the proposed change it will always crash.
The problem is that the destructors of the
On 2014-11-19 21:08, Steven Schveighoffer wrote:
We really *REALLY* need a mechanism to determine whether destruction is
happening in a GC or not. In synchronous destruction (i.e. destroy or
scoped), you can run the invariant. In GC, you cannot.
Tango for D1 had that. A new method, "dispose",
On 19.11.2014 21:08, Steven Schveighoffer wrote:
On 11/19/14 3:46 AM, Daniel Murphy wrote:
"Rainer Schuetze" wrote in message news:m4eu6v$trq$1...@digitalmars.com...
I remember having an invariant on a tree structure checking
consistency by verifying the children and parent references. This
On 11/19/14 3:46 AM, Daniel Murphy wrote:
"Rainer Schuetze" wrote in message news:m4eu6v$trq$1...@digitalmars.com...
I remember having an invariant on a tree structure checking
consistency by verifying the children and parent references. This
crashed when adding a destructor. With the proposed
"Rainer Schuetze" wrote in message news:m4eu6v$trq$1...@digitalmars.com...
I remember having an invariant on a tree structure checking consistency by
verifying the children and parent references. This crashed when adding a
destructor. With the proposed change it will always crash.
The proble
On 17.11.2014 21:02, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
A remaining question is whether invariants should also be called for
default construction [2].
[1]: https://github.com/D-Progra
On Monday, 17 November 2014 at 20:51:36 UTC, Walter Bright wrote:
Not only that, the runtime check would occur every time an
object is created, yet the .init will always be the same. Doing
this check would, I fear, cause people to disable invariants as
not worth the expense.
If it's init data
On Tuesday, 18 November 2014 at 00:51:03 UTC, deadalnix wrote:
On Monday, 17 November 2014 at 20:02:36 UTC, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are
now called before destruction and for non-default construction.
A remaining question is whether invariant
On Monday, 17 November 2014 at 20:02:36 UTC, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are
now called before destruction and for non-default construction.
A remaining question is whether invariants should also be
called for default construction [2].
[1]: ht
On 11/17/14 4:09 PM, Steven Schveighoffer wrote:
... which Object.invariant for every function call ...
which *calls* Object.invariant for every function call
-Steve
On 11/17/14 3:51 PM, Walter Bright wrote:
On 11/17/2014 12:32 PM, Steven Schveighoffer wrote:
On 11/17/14 3:02 PM, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
This sounds good.
A remaining q
On 11/17/2014 12:32 PM, Steven Schveighoffer wrote:
On 11/17/14 3:02 PM, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
This sounds good.
A remaining question is whether invariants should also b
On 11/17/14 3:02 PM, Martin Nowak wrote:
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
This sounds good.
A remaining question is whether invariants should also be called for
default construction [2].
I'd say no.
Walter is about to fix an old bug [1] so that invariants are now called
before destruction and for non-default construction.
A remaining question is whether invariants should also be called for
default construction [2].
[1]: https://github.com/D-Programming-Language/dmd/pull/4136
[2]: https:/
22 matches
Mail list logo
