• Nicholas Jordan (10/10) Mar 16 2009 I put some fields at the front of my first attempt as a note while
• Jarrett Billingsley (12/21) Mar 16 2009 The problem is that this conflicts with the D1 syntax for class/struct
• Nicholas Jordan (24/47) Mar 16 2009 wrote:
• Jarrett Billingsley (2/49) Mar 16 2009 So I'm guessing you replied to my post by accident, then?
• Jarrett Billingsley (5/58) Mar 16 2009 Or not - you seem to have replied on purpose. But I honestly don't
• Nicholas Jordan (9/9) Mar 16 2009 Oops, I missed the note about enums.
• Jarrett Billingsley (2/8) Mar 16 2009 I have *no* idea what you're talking about.

Nicholas Jordan <asdf some.com> writes:

I put some fields at the front of my first attempt as a note while
prototyping, the compiler did not accept the syntax from the sample
code. I had to do it like this:

invariant {long fail__= -123456;}

with the brackets surrounding, for this question - what I want here is
several values that are never changeable and always represent some
sort of status return from calls - always the same. The above code is
not compliant with the code shown in the discussion of what D is all
about.

Narrowly, is the above code stable for use in other scopes?

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Mar 16, 2009 at 1:50 PM, Nicholas Jordan <asdf some.com> wrote:
 I put some fields at the front of my first attempt as a note while
 prototyping, the compiler did not accept the syntax from the sample
 code. I had to do it like this:

 invariant {long fail__= -123456;}

 with the brackets surrounding, for this question - what I want here is
 several values that are never changeable and always represent some
 sort of status return from calls - always the same. The above code is
 not compliant with the code shown in the discussion of what D is all
 about.

The problem is that this conflicts with the D1 syntax for class/struct
invariants.  This is probably why the immutable keyword has been
introduced, and I have a feeling invariant as a form of constness will
be renamed immutable.

Just use:

immutable
{
    long foo = 4;
    int bar = 12;
}

But you said that these are return statuses?  Why not use enums instead?

Nicholas Jordan <asdf some.com> writes:

== Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
article
 On Mon, Mar 16, 2009 at 1:50 PM, Nicholas Jordan <asdf some.com>

wrote:
 I put some fields at the front of my first attempt as a note while
 prototyping, the compiler did not accept the syntax from the


sample
 code. I had to do it like this:

 invariant {long fail__= -123456;}

 with the brackets surrounding, for this question - what I want


here is
 several values that are never changeable and always represent some
 sort of status return from calls - always the same. The above code


is
 not compliant with the code shown in the discussion of what D is


all
 about.

 The problem is that this conflicts with the D1 syntax for

class/struct
 invariants.  This is probably why the immutable keyword has been
 introduced, and I have a feeling invariant as a form of constness

will
 be renamed immutable.
 Just use:
 immutable
 {
     long foo = 4;
     int bar = 12;
 }
 But you said that these are return statuses?  Why not use enums

instead?

ran htod.exe on jni.h - this looks sane to me. Some concepting issues
but is a step forward in computer science, so what I do is just list
that file on the command line to C:\dmd\bin\dmd.exe along with what it
produces on EZ-Twain dot h along with other things I might write that
would make more sense to me as a file scope code base, the compiler
de-facto takes file scope into account?

In other words, in file foo.d I have a function, on which I want to
feed it a bar from compilation unit recognition - this is sorta
obvious for a compiler writer, seems to me to even throw some cs
301's, but redeclaration in each file scope would lead to the same
issues we are trying to parallelize.

I have a rich skill base in subtle nuances of parallelizing work, this
is the time to fix this. If it gets broken later, one may need your
burger-flippin resume' to be ready to deliver.

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Mar 16, 2009 at 2:40 PM, Nicholas Jordan <asdf some.com> wrote:
 =3D=3D Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
 article
 On Mon, Mar 16, 2009 at 1:50 PM, Nicholas Jordan <asdf some.com>

 wrote:
 I put some fields at the front of my first attempt as a note while
 prototyping, the compiler did not accept the syntax from the


 sample
 code. I had to do it like this:

 invariant {long fail__=3D -123456;}

 with the brackets surrounding, for this question - what I want


 here is
 several values that are never changeable and always represent some
 sort of status return from calls - always the same. The above code


 is
 not compliant with the code shown in the discussion of what D is


 all
 about.

 The problem is that this conflicts with the D1 syntax for

 class/struct
 invariants. =A0This is probably why the immutable keyword has been
 introduced, and I have a feeling invariant as a form of constness

 will
 be renamed immutable.
 Just use:
 immutable
 {
 =A0 =A0 long foo =3D 4;
 =A0 =A0 int bar =3D 12;
 }
 But you said that these are return statuses? =A0Why not use enums

 instead?

 ran htod.exe on jni.h - this looks sane to me. Some concepting issues
 but is a step forward in computer science, so what I do is just list
 that file on the command line to C:\dmd\bin\dmd.exe along with what it
 produces on EZ-Twain dot h along with other things I might write that
 would make more sense to me as a file scope code base, the compiler
 de-facto takes file scope into account?

 In other words, in file foo.d I have a function, on which I want to
 feed it a bar from compilation unit recognition - this is sorta
 obvious for a compiler writer, seems to me to even throw some cs
 301's, but redeclaration in each file scope would lead to the same
 issues we are trying to parallelize.

 I have a rich skill base in subtle nuances of parallelizing work, this
 is the time to fix this. If it gets broken later, one may need your
 burger-flippin resume' to be ready to deliver.

So I'm guessing you replied to my post by accident, then?

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Mar 16, 2009 at 3:09 PM, Jarrett Billingsley
<jarrett.billingsley gmail.com> wrote:
 On Mon, Mar 16, 2009 at 2:40 PM, Nicholas Jordan <asdf some.com> wrote:
 =3D=3D Quote from Jarrett Billingsley (jarrett.billingsley gmail.com)'s
 article
 On Mon, Mar 16, 2009 at 1:50 PM, Nicholas Jordan <asdf some.com>

 wrote:
 I put some fields at the front of my first attempt as a note while
 prototyping, the compiler did not accept the syntax from the


 sample
 code. I had to do it like this:

 invariant {long fail__=3D -123456;}

 with the brackets surrounding, for this question - what I want


 here is
 several values that are never changeable and always represent some
 sort of status return from calls - always the same. The above code


 is
 not compliant with the code shown in the discussion of what D is


 all
 about.

 The problem is that this conflicts with the D1 syntax for

 class/struct
 invariants. =A0This is probably why the immutable keyword has been
 introduced, and I have a feeling invariant as a form of constness

 will
 be renamed immutable.
 Just use:
 immutable
 {
 =A0 =A0 long foo =3D 4;
 =A0 =A0 int bar =3D 12;
 }
 But you said that these are return statuses? =A0Why not use enums

 instead?

 ran htod.exe on jni.h - this looks sane to me. Some concepting issues
 but is a step forward in computer science, so what I do is just list
 that file on the command line to C:\dmd\bin\dmd.exe along with what it
 produces on EZ-Twain dot h along with other things I might write that
 would make more sense to me as a file scope code base, the compiler
 de-facto takes file scope into account?

 In other words, in file foo.d I have a function, on which I want to
 feed it a bar from compilation unit recognition - this is sorta
 obvious for a compiler writer, seems to me to even throw some cs
 301's, but redeclaration in each file scope would lead to the same
 issues we are trying to parallelize.

 I have a rich skill base in subtle nuances of parallelizing work, this
 is the time to fix this. If it gets broken later, one may need your
 burger-flippin resume' to be ready to deliver.

 So I'm guessing you replied to my post by accident, then?

Or not - you seem to have replied on purpose.  But I honestly don't
know what you're talking about.  I just answered your question about
declaring multiple invariants <_<

Nicholas Jordan <asdf some.com> writes:

Oops, I missed the note about enums.

enums in other languages sound to me to be a great idea, but when I first
started coding I noted that the machine was
placing them at the beginning of the file and I eventually figured out that
they were being used to switch the behavior of
the operating system.

Due to the nature of my work, such an approach though needful routinely is not
where I am going to begin coding. I may code
some in later after greater skill strength.

The matter is discussed on the topic "Hijacking" in the discussion of the goals
and why's of "D"

See also a discussion by the author of H2 on how enums could ( though not by
following the specs ) be used to obtain
operations from the JVM that it was intending to prevent.

Jarrett Billingsley <jarrett.billingsley gmail.com> writes:

On Mon, Mar 16, 2009 at 2:53 PM, Nicholas Jordan <asdf some.com> wrote:
 Oops, I missed the note about enums.

 enums in other languages sound to me to be a great idea, but when I first
started coding I noted that the machine was
 placing them at the beginning of the file and I eventually figured out that
they were being used to switch the behavior of
 the operating system.

 Due to the nature of my work, such an approach though needful routinely is not
where I am going to begin coding. I may code
 some in later after greater skill strength.

I have *no* idea what you're talking about.