First, now, in a function of D, we can make netsted structure, nested function and versioned code block, so much brackets, which are not code block ,in the code sequence.

Second, the use of colon and bracket for private/public, static and version keyword, make the judge of access level and storage type is difficult.

  class aClass
  {
    public:
      .
      .
      ...three pages
      .
      void func( ...)
      {

       }
     .
     .
     static:
      .
      ... four pages
      .
      int gotit(){...}

How do you think about all these ?

I think technically these { things } are called curly braces.
I love them. 100x times better than begin end. IMO, they make function/class bodies standout.

As for the second question, well, for the example you've given, I'd blame the coder who wrote it.

Boris Wang wrote:
> First, now, in a function of D, we can make netsted structure, nested function and versioned code block, so much brackets, which are not code block ,in the code sequence.
> 
> Second, the use of colon and bracket for private/public, static and version keyword, make the judge of access level and storage type is difficult.
> 
>   class aClass
>   {
>     public:
>       .
>       .
>       ...three pages
>       .
>       void func( ...)
>       {
> 
>        }
>      .
>      .
>      static:
>       .
>       ... four pages
>       .
>       int gotit(){...}
> 
> How do you think about all these ?
> 
> 

Hasan Aljudy wrote:
> I think technically these { things } are called curly braces.

The Americans call them "braces", the British prefer "curly brackets". "Curly braces" is common, but it's redundant, since there's only one type of braces.

Hi Hasan,
using  {}      instead of          begin end                   is more a
matter of taste. Since I am comming form Oberon/Modula i prefer (of course)
the last one, but I think using {} in D is more a political
decision.(convincing Cpp and Java nerds) . I think D respective Walter has
borrowed some ideas from the Wirth s languages family, let us name the
module concept , nestested functions just to name some items. So what makes
me wonder that the enclosing concept,  is not part of D.
a simple  example from Modula 2:

Module  Primes;
FROM InOut IMPORT Writeln, ......;

  PROCEDURE abc
  ...
     PROCEDURE xyz
        ....
    END xyz
  ....
  END abc
END  Primes

Have a look at then END declarations: I found them quit usefull and the code
more readable, at least in deep nested functions. But perhaps :
int xyz()
{
}xyz
looks a bit too strange. <g>
Just my 2 cents
Bjoern.

"Hasan Aljudy" <hasan.aljudy@gmail.com> schreef in bericht news:e6rhq4$1ce3$1@digitaldaemon.com...
> I think technically these { things } are called curly braces. I love them. 100x times better than begin end. IMO, they make function/class bodies standout.
> >

BLS wrote:
> a simple  example from Modula 2:
> 
> Module  Primes;
> FROM InOut IMPORT Writeln, ......;
> 
>   PROCEDURE abc
>   ...
>      PROCEDURE xyz
>         ....
>     END xyz
>   ....
>   END abc
> END  Primes
> 
> Have a look at then END declarations: I found them quit usefull and the code more readable, at least in deep nested functions.
> 

I find something like that gets very annoying quickly, when "PROCEDURE xyz" is one or two lines long. Imagine something like (mixed-syntax pseudocode):

PROCEDURE foo(int x)
	PROCEDURE bar
		PROCEDURE baz
			return 6;
		END baz
		x += baz();
	END bar
	if (x) BEGIN
		while (x < 10) BEGIN
			bar();
			foo(x);
		END
	END
	return x;
END foo

At least to me, the extraneous foo/bar/baz in the above make it harder to quickly read and understand.

In my mind, when things start to get unreadable due to them spanning many lines and/or there being a lot of nesting, you can just use a comment at the ending curly bracket:

void foo() {
	...
} // end foo()

Deewiant wrote:
> In my mind, when things start to get unreadable due to them spanning many lines
> and/or there being a lot of nesting, you can just use a comment at the ending
> curly bracket:
> 
> void foo() {
> 	...
> } // end foo()

This is generally what I do, except I don't say "end" because I already know that -- why else would I document a closing brace?  ;)  Instead I generally put a reminder of the type of the 'foo' I'm ending: function, or class, or struct, or whatever.  So in the case above, I'd write `// function foo`.

-- Chris Nicholson-Sauls

"Deewiant" <deewiant.doesnotlike.spam@gmail.com> schreef in bericht news:e6rno9$1ju8$1@digitaldaemon.com...
>> I find something like that gets very annoying quickly, when "PROCEDURE
xyz" is
> one or two lines long. Imagine something like (mixed-syntax pseudocode):

Hi Deewiant,
a two line inner function seems , at least to me, to be a quit seldom used
construction.
But anyway, i guess exept me nobody is interested in such kind of language
extension.
and it will be nearly impossible to keep the D compiler compatible with
ancient versions..
kind regards and thanks for your feedback.
bjoern


> PROCEDURE foo(int x)
> PROCEDURE bar
> PROCEDURE baz
> return 6;
> END baz
> x += baz();
> END bar
> if (x) BEGIN
> while (x < 10) BEGIN
> bar();
> foo(x);
> END
> END
> return x;
> END foo
>
> At least to me, the extraneous foo/bar/baz in the above make it harder to quickly read and understand.
>
> In my mind, when things start to get unreadable due to them spanning many
lines
> and/or there being a lot of nesting, you can just use a comment at the
ending
> curly bracket:
>
> void foo() {
> ...
> } // end foo()

BLS wrote:
> "Deewiant" <deewiant.doesnotlike.spam@gmail.com> schreef in bericht news:e6rno9$1ju8$1@digitaldaemon.com...
>>> I find something like that gets very annoying quickly, when "PROCEDURE
> xyz" is
>> one or two lines long. Imagine something like (mixed-syntax pseudocode):
> 
> Hi Deewiant,
> a two line inner function seems , at least to me, to be a quit seldom used
> construction.

Well, that depends on your coding style, really.

Personally, I prefer to write lots of small, well-defined functions.  If I can't fit a whole function's flow into my head at once, then I know I need to break it up.

One interesting approach to this problem I've seen is in Nemerle: it supports both C-style syntax and, with the flip of a compiler switch, Python-style indenting.

Mmm... cake.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Hi Daniel,
Python style indenting is ...
what I would really like to see in D. but let us keep realistic...
in fact nothing new, i think also the very first dbase interpreter allows
it.
and
Nowadays the most 4GLs are using a pascal like language without {},
respective  begin end,  or even ;
From a compiler designers view it means a lot of additional work.

Thanks to Eric Andersons message I have had today the very first look on
Nemerle. Looks clean, modern and usable.(and the most important point)
readable.
Bjoern


"Daniel Keep" <daniel.keep.lists@gmail.com> schreef in bericht news:e6rufj$1t3d$1@digitaldaemon.com...
>
>
> BLS wrote:
> > "Deewiant" <deewiant.doesnotlike.spam@gmail.com> schreef in bericht news:e6rno9$1ju8$1@digitaldaemon.com...
> >>> I find something like that gets very annoying quickly, when "PROCEDURE
> > xyz" is
> >> one or two lines long. Imagine something like (mixed-syntax
pseudocode):
> >
> > Hi Deewiant,
> > a two line inner function seems , at least to me, to be a quit seldom
used
> > construction.
>
> Well, that depends on your coding style, really.
>
> Personally, I prefer to write lots of small, well-defined functions.  If I can't fit a whole function's flow into my head at once, then I know I need to break it up.
>
> One interesting approach to this problem I've seen is in Nemerle: it supports both C-style syntax and, with the flip of a compiler switch, Python-style indenting.
>
> Mmm... cake.
>
> -- Daniel
>
> -- 
> Unlike Knuth, I have neither proven or tried the above; it may not even make sense.
>
> v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

This looks like a good place for a code scanning tool. It would scan code and at each "}" find what the matching "{" is coming from and if their is already a label verify that it is correct, otherwise insert a label. Might help catch incorrectly matched braces which is what I'm guessing the "END label" construct is trying to do.


Chris Nicholson-Sauls wrote:
> Deewiant wrote:
> 
>> In my mind, when things start to get unreadable due to them spanning many lines
>> and/or there being a lot of nesting, you can just use a comment at the ending
>> curly bracket:
>>
>> void foo() {
>>     ...
>> } // end foo()
> 
> 
> This is generally what I do, except I don't say "end" because I already know that -- why else would I document a closing brace?  ;)  Instead I generally put a reminder of the type of the 'foo' I'm ending: function, or class, or struct, or whatever.  So in the case above, I'd write `// function foo`.
> 
> -- Chris Nicholson-Sauls