Could be better? Yes, may be. But don't forget that we are talking about a
language whose roots where designed +18 years

And it is not the only that have something to criticize
El 04/09/2014 20:43, "Gene Wirchenko" <[email protected]> escribió:

> At 02:52 2014-09-04, "Fernando D. Bozzo" <[email protected]> wrote:
>
> [snip]
>
>  You should read the docs of the language you program before saying
>> something is "a bug"
>>
>
>      If the spec states that when you type W twice in a row, the system
> will electrocute you, someone who was electrocuted would still have cause
> for complaint.
>
>      The semi-colon behaviour is odd, and it has bitten me, too.  That the
> behaviour is consistent/logical makes it worse.  If OP's statement after
> was a non-block statement, it would not get executed, and there might be no
> indication of this.
>
>      Add to that that line comments cause the rest of the physical line to
> be ignored, and it put the kibosh on me having my search program program
> understand VFP line continuation.  (If I am looking for text, it might be
> before the continuation or after (or even possibly both).)  The line
> comments behaviour is useful for documenting a table structure; here is the
> table definition for one of the tables in my app:
>
>       create table cwko;
>        (;
>        ;
>        wonbr n(6) not null,;       && Work Order Number
>        stncode c(3) not null,;     && Station Code
>        wogrp c(1) not null,;       && Work Order Group
>        ;                           &&  used in grouping similar WOs which
>        ;                           &&  will end up being invoiced together
>        clcode c(3) not null,;      && Client Code
>        wccode c(3) not null,;      && Work Classification Code
>        ;
>        woccode c(3) not null,;     && Work Order Classification Code
>        ;
>        invtype c(1) not null,;     && Invoice Type
>        ;                           &&  D: Detail, C: Contract, F:
> Functional
>        ;                           &&  Details of the distinctions between
>        ;                           &&  the types are documented in
> cbs2.prg.
>        ;
>        isgwo l not null,;          && Whether it is a GWO
>        ;
>        wostatus c(1) not null,;    && Status:
>        ;                           &&  V=Void (effectively deleted)
>        ;                           &&  A=Active (active WO: postable)
>        ;                           &&  R=Review (postable, being reviewed
> for
>        ;                           &&   billing, may have been invoiced)
>        ;                           &&  B=Billed (has been invoiced and
>        ;                           &&   invoice has been printed)
>        ;                           &&  I=Inactive (not postable)
>        billtype c(1) not null,;    && Work Order Billing Type
>        ;                           &&  D=Daily, S=Semi-monthly, M=Monthly,
>        ;                           &&  E=Extended, F=extended Finished
>        trndtlow d not null,;       && Transaction Date Range Low
>        trndthi d not null,;        && Transaction Date Range High
>        ;                           &&  With isgwo, it is enforced that
>        ;                           &&  trndtlow and trndthi are the first
> and
>        ;                           &&  last of one month.
>        ;                           && There used to be a billtype W
> (Weekly).
>        ;                           &&  With billtype W, it was enforced
> that
>        ;                           &&  a week is from Monday to Sunday
> except
>        ;                           &&  as clipped by month boundaries.
>        invdate d not null,;        && Invoice Date
>        ;                           &&  This is a separate date, because JP
>        ;                           &&  sometimes diddles trndthi.
> Currently,
>        ;                           &&  invdate should equal trndthi.  (This
>        ;                           &&  is enforced in cwktform and
> cftiinv::,
>        ;                           &&  but not in browses.)  It is possible
>        ;                           &&  that this constraint could change.
>        ;
>        cliponbr c(35) not null,;   && Client's PO Number
>        ;
>        wotitle c(45) not null,;    && Work Order Title
>        ;                           &&  This is what is usually called a
>        ;                           &&  description elsewhere in the system.
>        wocomm m not null,;         && Work Order Comments
>        invnote m not null,;        && Invoicing Note
>        ;
>        refiged l not null,;        && Refiguring Done Yet?
>        ;
>        setupchg l not null,;       && Whether to generate a setup charge
>        copywonm l not null,;       && Whether to copy WO to next month
>        ;
>        cwktarc l not null,;        && Associated cwkt Rows Archived Yet?
>        ;
>        stnwrote l not null;        && Associated cwkt Rows Written to Slave
>        ;                           && Station?
>        ;                           &&  Used only by cutlsdt.  Value
> undefined
>        ;                           &&  any other time.
>        )
>
> [snip]
>
> Sincerely,
>
> Gene Wirchenko
>
>
[excessive quoting removed by server]

_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message: 
http://leafe.com/archives/byMID/profox/CAGQ_Juk1kPBxk4Jitvj=sqvizw-ou1w+hbwnsx7q9gjh3bg...@mail.gmail.com
** All postings, unless explicitly stated otherwise, are the opinions of the 
author, and do not constitute legal or medical advice. This statement is added 
to the messages for those lawyers who are too stupid to see the obvious.

Reply via email to