On Mon, Mar 16, 2009 at 3:09 PM, Jarrett Billingsley
<jarrett.billings...@gmail.com> wrote:
> On Mon, Mar 16, 2009 at 2:40 PM, Nicholas Jordan <a...@some.com> wrote:
>> == Quote from Jarrett Billingsley (jarrett.billings...@gmail.com)'s
>> article
>>> On Mon, Mar 16, 2009 at 1:50 PM, Nicholas Jordan <a...@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.
>>
>
> 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 <_<
