"Derek" <derek@psych.ward> wrote in message news:19f0tg7229js5.y2wq16gmtkq3.dlg@40tude.net...
> On Mon, 7 Feb 2005 19:47:15 +0000 (UTC), Kris wrote:
>
>> I'm jumping into this at a somewhat arbitrary point, but the general
>> claim
>> Walter (apparently) makes is that
>>
>> 1) D tries to catch dumb mistakes made by a user
>> 2) D tries to steer the programmer in the 'right' direction
>>
>> Let's see here:
>>
>> char[] getLine (char[] s)
>> {
>> uint length = s.length;
>> foreach (uint i, char c; s)
>> {
>> if (c == '\n')
>> length = i;
>> }
>> return s [0..length];
>> }
>>
>> The above is just an arbitrary example of the apparent hypocritical
>> nature of
>> (1) and (2). The function is supposed to return the subset of its
>> argument only
>> as far as a newline.
>>
>> Do you see the insideous bug there? Many of you will not, so I'll spell it out:
>>
>> Walter added a very subtle pseudo-reserved word, that's only used
>> when it comes
>> to arrays. Yes, it's the word "length". When used within
>> square-brackets, it
>> always means "the length of the enclosing array". Of course, this
>> overrides any
>> other variable that happens to be called "length". Naturally, no
>> warning is
>> emitted.
>>
>> This would perhaps not be so bad if the pseudo-reserved word were
>> "implicitArrayLength" or something like that. But NO! Walter uses an
>> undecorated, and exceptionally common variable name instead. Oh; and
>> this was
>> introduced to ease the implementation of certain templates - on
>> technical
>> merits. Oh! And Walter feels this pseudo-reserved name should /not/
>> change from
>> "length" to a 'decorated' version instead.
>
> And this is one of the reason why I use 'decorated' identifier names;
> to
> avoid clashes with language keywords.
>
> char[] getLine (char[] pString)
> {
> uint lLength = pString.length;
> foreach (uint fIdx, char fCurrChar; pString)
> {
> if (fCurrChar == '\n')
> lLength = fIdx;
> }
> return pString [0..lLength];
> }
>
> (The prefixes give hints as to the identifiers' scope)

Very sensible. But very sad that we must do so, given total ugliness of decorations in general, and the almost total uselessness of Hungarian nature.

The last I recall from last year was that the implicit length was going to be $. I'm sure there were reasons against, but they cannot be as compelling as the example Kris gave.

Here's a possible compromise, although I'm not sure I like it:

    char[] getLine (char[] s)
    {
        uint length = s.length;
        foreach (uint i, char c; s)
        {
            if (c == '\n')
            length = i;
        }

        return s [0 .. .length];
    }

The . before length indicates its 'local' to 's'.

Hmmm, on second thoughts, that stinks.

In general - indeed, it's harder to think of a contrary example - verbose code is better than dangerous code. Kris is quite right when he says that D has introduced some of the latter.

"Derek" <derek@psych.ward> wrote in message news:1lxyunvbocmz8$.jojxhcylx4ev.dlg@40tude.net...
> On Mon, 07 Feb 2005 22:21:25 +0100, Anders F Björklund wrote:
>
>> Derek wrote:
>>
>>> And this is one of the reason why I use 'decorated' identifier names;
>>
>> I'm not sure that warts classifies as decorations in all cultures ? :-)
>>
>> http://www.digitalmars.com/d/dstyle.html:
>>> Hungarian Notation
>>> Just say no.
>>
>
> Well its been working for me and my teams for 10 years now, so sue me. ;-)

Type decoration - void fn(long lLimit); -  is bad, because it is non-portable, and introduces strong probabilities that the code itself will be turned into a liar.

Purpose decoration - void fn(char const *name, int bOverwrite); - is good, notwithstanding its uglification. (It's still better to do without, if that does not promote ambiguities.)

(For a better exposition, consult section 17.4 of your copy of Imperfect C++ <g>)

Cheers


-- 
Matthew Wilson

Author: "Imperfect C++", Addison-Wesley, 2004
    (http://www.imperfectcplusplus.com)
Contributing editor, C/C++ Users Journal
    (http://www.synesis.com.au/articles.html#columns)
STLSoft moderator
    (http://www.stlsoft.org)

"I can't sleep nights till I found out who hurled what ball through what apparatus" -- Dr Niles Crane

-------------------------------------------------------------------------------

"Anders F Björklund" <afb@algonet.se> wrote in message news:cu87kd$2soo$1@digitaldaemon.com...
> Dave wrote:
>
>> I agree. I mean let's face it, we've probably all shipped production
>> code with
>> what amounts to non-language formalized PwC in it, hence my earlier
>> suggestion
>> to divorce PwC from any switches, or at least any of the default
>> "meta"
>> switches.
>
> Maybe I missed something, but what's the difference between
> Programming with Contracts (PwC) and Design by Contract (DbC) ?

It's a distinction primarily promoted by Chris Diggins
(www.heron-language.com), which attempts to draw meaningful distinctions
between the practice of contract programming techniques in code, and the
use of contracts as design specifications. Being a decompositionist by
nature, I get where he's coming from, and there's good historical
support for his position
    - people have been using asserts for a long time in blissful
ignorance of the lofty ideals of CP (or DbC, if you want to pay Mssr Dr
Meyer lots of cash), and
    - it's eminently reasonable to use a contract to specify the
behaviour of a function without enforcing it at runtime; we all do it
all the time!

However, since the two things are more and more coming together, I tend to prefer to follow Walter's lead, and just call it Contract Programming.

In article <1lxyunvbocmz8$.jojxhcylx4ev.dlg@40tude.net>, Derek says...
>
>On Mon, 07 Feb 2005 22:21:25 +0100, Anders F Björklund wrote:
>
>> Derek wrote:
>> 
>>> And this is one of the reason why I use 'decorated' identifier names;
>> 
>> I'm not sure that warts classifies as decorations in all cultures ? :-)
>> 
>> http://www.digitalmars.com/d/dstyle.html:
>>> Hungarian Notation
>>> Just say no.
>> 
>
>Well its been working for me and my teams for 10 years now, so sue me. ;-)

I applaud any group that sets their own standards to deal with complexity; and then sticks with it.

The issue here is that D slyly injects its own variable named 'length', which
then (a) forces one to adopt just such a standard, once you've hopefully noticed
the bug, and (b) D does not tell you what it did to f&ck you in the first place
:-(

Given Walter's current position on this particular language 'idiom', one must
resort to (a)

Hence, one has to adopt a somewhat tongue-in-cheek attitude to lofty claims regarding the goals of D to "protect and serve". I understand Walter invoked the "do as I say, not do as I do" as a rebuke within this thread somewhere. My opinion, and suggestion, is that perhaps he might reflect upon that for a while :-)

On Tue, 8 Feb 2005 09:21:12 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>> Regardless, either you're arguing that because this is bad about D,
>> the  missing return behaviour must also be bad, which is clearly
>> illogical.
>
> He's not saying that at all.

Good.

>> Or, this post is simply an attack designed to make Walters position
>> seem  weaker, when in fact it supplies no logical evidence to do so.
>
> Oh come on! It goes to the motivation behind the missing return value.
> Plain as the nose on your face.

I don't see how showing someones past mistake (a matter of opinion, which I happen to share), has any bearing on another action which may/may not be a mistake (another matter of opinion).

Yes, Walters motivation may be as stated, however, clearly he believes he is being true to that motivation WRT to the missing return situation, therefore "at best" Kris has shown that length was/is a bad idea and needs to be changed, but it has little or no bearing on the missing return situation.

>> In other words I can't see how this post has any bearing on the
>> argument  at hand. At best it's a strawman:
>> http://www.datanation.com/fallacies/straw.htm
>
> Yawn! Keep trotting 'em out. They must be important and apposite, if
> there's a link you can reference.

1. You have chosen to  attack the method in which I have presented my argument, instead of the actual argument itself:

http://www.datanation.com/fallacies/style.htm

2. To put it simply, "whether there is a link or not, has no bearing on whether it's important or not", to argue otherwise is clearly illogical.

Regan

>>> Or, this post is simply an attack designed to make Walters position seem  weaker, when in fact it supplies no logical evidence to do so.
>>
>> Oh come on! It goes to the motivation behind the missing return
>> value.
>> Plain as the nose on your face.
>
> I don't see how showing someones past mistake (a matter of opinion, which  I happen to share), has any bearing on another action which may/may not be  a mistake (another matter of opinion).
>
> Yes, Walters motivation may be as stated, however, clearly he believes he  is being true to that motivation WRT to the missing return situation,  therefore "at best" Kris has shown that length was/is a bad idea and needs  to be changed, but it has little or no bearing on the missing return  situation.

Well put. I just don't agree.

>>> In other words I can't see how this post has any bearing on the argument  at hand. At best it's a strawman: http://www.datanation.com/fallacies/straw.htm
>>
>> Yawn! Keep trotting 'em out. They must be important and apposite, if there's a link you can reference.

Marvellous stuff. Keep going. I'm sure you've got one for every occasion, and it's ripping good sport.

> 1. You have chosen to  attack the method in which I have presented my argument, instead of the actual argument itself:

Well, it appears that you're more adept at quoting other's wisdoms, than acquiring your own. Specifically, I _did_ attack the argument, and the proof of that is that you responded to my point. Doh!

Let's see what gnomic little nugget you're going to profer next ...

On Tue, 8 Feb 2005 09:48:10 +1100, Matthew <admin@stlsoft.dot.dot.dot.dot.org> wrote:
>>>> Or, this post is simply an attack designed to make Walters position
>>>> seem  weaker, when in fact it supplies no logical evidence to do so.
>>>
>>> Oh come on! It goes to the motivation behind the missing return
>>> value.
>>> Plain as the nose on your face.
>>
>> I don't see how showing someones past mistake (a matter of opinion,
>> which  I happen to share), has any bearing on another action which
>> may/may not be  a mistake (another matter of opinion).
>>
>> Yes, Walters motivation may be as stated, however, clearly he believes
>> he  is being true to that motivation WRT to the missing return
>> situation,  therefore "at best" Kris has shown that length was/is a
>> bad idea and needs  to be changed, but it has little or no bearing on
>> the missing return  situation.
>
> Well put. I just don't agree.

Sorry, don't agree with what in particular?
 - Walter believes it's true to his motivation.
 - The behaviour is true to Walters motivation.
 - This argument has no bearing on the other.

>>>> In other words I can't see how this post has any bearing on the
>>>> argument  at hand. At best it's a strawman:
>>>> http://www.datanation.com/fallacies/straw.htm
>>>
>>> Yawn! Keep trotting 'em out. They must be important and apposite, if
>>> there's a link you can reference.
>
> Marvellous stuff. Keep going. I'm sure you've got one for every
> occasion, and it's ripping good sport.

By defintion I have one for every instance in which someone appears to _me_ to be illogical.
(I accept the posibility that I could be wrong and welcome a rebuttal)

>> 1. You have chosen to  attack the method in which I have presented my
>> argument, instead of the actual argument itself:
>
> Well, it appears that you're more adept at quoting other's wisdoms, than
> acquiring your own.

Now you're attacking me:
http://www.datanation.com/fallacies/attack.htm

> Specifically, I _did_ attack the argument, and the
> proof of that is that you responded to my point. Doh!

You attacked _both_ the argument _and_ the method in which it was proposed.
The first is fine, the seccond is illogical.

> Let's see what gnomic little nugget you're going to profer next ...

The reason I profer these links is simple. In my experience a skillful writer/speaker can sway an audience to believe/disbelieve just about anything, they can do it without providing any logical or rational reasoning.

These links helped _me_ understand what they were doing and why it was illogical, I hope to enlighten as many people as I can, so that we can all get on with having logical, rational debates with good sound reasoning.

Now, I'm not saying either you or Kris _are_ illogical and/or irrational at all, you both exhibit very good logical and rational reasoning, however in this particular case I think the argument is illogical and I'm trying to explain why to the best of my ability.

My intention is not to attack the person at all (for that would be illogical), however for some reason you seem to have taken it as an attack against the person, and attacked back in that fashion.

I may be wrong about this argument being illogical. If you believe so please make an attempt to refute my argument in the same manner in which it was proferred, with logic.

Regan

On Sun, 6 Feb 2005 19:42:14 -0800, Walter <newshound@digitalmars.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opslsuv5qc23k2f5@ally...
>> AOP is cool, I wish it was possible to use it in D.
>
> I looked at Kris' reference, but AOP is one of those things I don't
> understand at all.

Ok, here is my attempt at a syntax for AOP for D.
In reality I am no expert on AOP.
Or on context free grammar.

//An attempt at a syntax for Aspect Oriented Programming in D.
//Based on the Aug 2004 DDJ article by Christopher Diggins
//-Regan Heath

//the original class, remains unmodified by this process.
class Original {
  this() {
  }
  ~this() {
  }
  void foo() {
  }
  void bar() {
  }
  void baz() {
  }
}

//the aspect: to be added to classes as defined in a pointcut.
aspect Logging {
  //joinpoint: code to be placed before the start of a function
  void in {
  	writefln("Entering(",this.name,")");
  }

  //joinpoint: code to be placed after the end of a function
  void out {
  	writefln("Leaving(",this.name,")");
  }

  //joinpoint: called before all other joinpoints, if it returns false the joinpoint is skipped
  bool query {
  }

  //joinpoint: executed on an exception
  void except {
  }

  //joinpoint: called after execution of the joinpoint even if 'query' returns false
  void finally {
  }

  //more joinpoints could be defined and added, requires more thought.
  //the definitions of the above are not set in stone, requires more thought.
}

//defines the new class, based on an existing class and 1 or more aspects
pointcut newOriginal, Original {
  Logging {
  	this, foo, bar
  }
  //<other aspect name> {
  //	this, bar, baz
  //}
  //..etc..
}

//how to use the new class
void main() {
  newOriginal o = new newOriginal();
}

On Tue, 08 Feb 2005 12:48:45 +1300, Regan Heath <regan@netwin.co.nz> wrote:
> On Sun, 6 Feb 2005 19:42:14 -0800, Walter <newshound@digitalmars.com> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>> news:opslsuv5qc23k2f5@ally...
>>> AOP is cool, I wish it was possible to use it in D.
>>
>> I looked at Kris' reference, but AOP is one of those things I don't
>> understand at all.
>
> Ok, here is my attempt at a syntax for AOP for D.
> In reality I am no expert on AOP.
> Or on context free grammar.
>
> //An attempt at a syntax for Aspect Oriented Programming in D.
> //Based on the Aug 2004 DDJ article by Christopher Diggins
> //-Regan Heath
>
> //the original class, remains unmodified by this process.
> class Original {
>    this() {
>    }
>    ~this() {
>    }
>    void foo() {
>    }
>    void bar() {
>    }
>    void baz() {
>    }
> }
>
> //the aspect: to be added to classes as defined in a pointcut.
> aspect Logging {
>    //joinpoint: code to be placed before the start of a function
>    void in {
>    	writefln("Entering(",this.name,")");
>    }
>
>    //joinpoint: code to be placed after the end of a function
>    void out {
>    	writefln("Leaving(",this.name,")");
>    }
>
>    //joinpoint: called before all other joinpoints, if it returns false the joinpoint is skipped
>    bool query {
>    }
>
>    //joinpoint: executed on an exception
>    void except {
>    }
>
>    //joinpoint: called after execution of the joinpoint even if 'query' returns false
>    void finally {
>    }
>
>    //more joinpoints could be defined and added, requires more thought.
>    //the definitions of the above are not set in stone, requires more thought.
> }
>
> //defines the new class, based on an existing class and 1 or more aspects
> pointcut newOriginal, Original {
>    Logging {
>     //defines the method to apply the aspect to
>    	this, foo, bar
>    }
>    //<other aspect name> {
>    //	this, bar, baz
>    //}
>    //..etc..
> }
>
> //how to use the new class
> void main() {
>    newOriginal o = new newOriginal();
> }

Small addition added above, specifically:

//defines the method to apply the aspect to

Regan

On Tue, 8 Feb 2005 09:24:38 +1100, Matthew wrote:

> "Derek" <derek@psych.ward> wrote in message news:19f0tg7229js5.y2wq16gmtkq3.dlg@40tude.net...
>> On Mon, 7 Feb 2005 19:47:15 +0000 (UTC), Kris wrote:
>>
>>> I'm jumping into this at a somewhat arbitrary point, but the general
>>> claim
>>> Walter (apparently) makes is that
>>>
>>> 1) D tries to catch dumb mistakes made by a user
>>> 2) D tries to steer the programmer in the 'right' direction
>>>
>>> Let's see here:
>>>
>>> char[] getLine (char[] s)
>>> {
>>> uint length = s.length;
>>> foreach (uint i, char c; s)
>>> {
>>> if (c == '\n')
>>> length = i;
>>> }
>>> return s [0..length];
>>> }
>>>
>>> The above is just an arbitrary example of the apparent hypocritical
>>> nature of
>>> (1) and (2). The function is supposed to return the subset of its
>>> argument only
>>> as far as a newline.
>>>
>>> Do you see the insideous bug there? Many of you will not, so I'll spell it out:
>>>
>>> Walter added a very subtle pseudo-reserved word, that's only used
>>> when it comes
>>> to arrays. Yes, it's the word "length". When used within
>>> square-brackets, it
>>> always means "the length of the enclosing array". Of course, this
>>> overrides any
>>> other variable that happens to be called "length". Naturally, no
>>> warning is
>>> emitted.
>>>
>>> This would perhaps not be so bad if the pseudo-reserved word were
>>> "implicitArrayLength" or something like that. But NO! Walter uses an
>>> undecorated, and exceptionally common variable name instead. Oh; and
>>> this was
>>> introduced to ease the implementation of certain templates - on
>>> technical
>>> merits. Oh! And Walter feels this pseudo-reserved name should /not/
>>> change from
>>> "length" to a 'decorated' version instead.
>>
>> And this is one of the reason why I use 'decorated' identifier names;
>> to
>> avoid clashes with language keywords.
>>
>> char[] getLine (char[] pString)
>> {
>> uint lLength = pString.length;
>> foreach (uint fIdx, char fCurrChar; pString)
>> {
>> if (fCurrChar == '\n')
>> lLength = fIdx;
>> }
>> return pString [0..lLength];
>> }
>>
>> (The prefixes give hints as to the identifiers' scope)
> 
> Very sensible. But very sad that we must do so, given total ugliness of decorations in general, and the almost total uselessness of Hungarian nature.

Agreed, if the only purpose of using decorated words for identifiers is work around clashes with keywords. However, another major reason for using the decoration scheme that we do use here, is to make it faster for people to understand the code that they are reading. By having 'scope/purpose' hints in the identifier names, it usually saves people scanning large blocks of code looking for where an identifier was declared.

> The last I recall from last year was that the implicit length was going to be $. I'm sure there were reasons against, but they cannot be as compelling as the example Kris gave.

You are preaching to the converted, brother ;-)

> Here's a possible compromise, although I'm not sure I like it:
> 
>     char[] getLine (char[] s)
>     {
>         uint length = s.length;
>         foreach (uint i, char c; s)
>         {
>             if (c == '\n')
>             length = i;
>         }
> 
>         return s [0 .. .length];
>     }
> 
> The . before length indicates its 'local' to 's'.
> 
> Hmmm, on second thoughts, that stinks.

Yes, it does. But nice try though.

> In general - indeed, it's harder to think of a contrary example - verbose code is better than dangerous code. Kris is quite right when he says that D has introduced some of the latter.

Agreed. I have always supported the use of a symbol rather than an English word to represent the array's length property. I'm keen to promote the readibilty of source code by humans, so an extra 'dot' seems counter productive to that aim.

-- 
Derek
Melbourne, Australia
8/02/2005 11:15:38 AM