April 04, 2005
This is interesting and sort-of on point. :)

http://www.cse.unsw.edu.au/~cs3141/ip.asf
http://www.codegeneration.net/tiki-read_article.php?articleId=61
http://www.edge.org/digerati/simonyi/simonyi_p1.html

Regan

On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
> I've done a bad job of explaining myself. Let me try again:
>
> I believe the rule should be "If a variable in a scope hides a variable in an outer scope it is an error" - no exceptions, none.
>
> What I was trying to do below was give solutions to the obvious problems this rule will create, reasons for those solutions in terms of good programming practice and the reasons why I see it as good programming practice.
>
> In short, all of these would be errors:
>
> int a;
> void foo(int a) {}
>
> int a
> void foo() { int a; }
>
> int a;
> void foo() {
>    if(true) {
>      int a;
>    }
> }
>
> void foo() {
>    int a;
>    if(true) {
>      int a;
>    }
> }
>
> int a;
> for(int a;;){}
>
> int a;
> for(;;){ int a; }
>
> ..etc.. you get the idea.
>
> To solve the above you have to rename one of the variables. I don't see that as a bad thing, in fact I believe it could force better programming practice. For example:
>
> int index;
> void foo() {
>    int index;
> }
>
> here, perhaps the global should be renamed (or even moved). Why is it global? What is "index" an index of? Possble solutions:
>
> #1
> class File {
>    int index;
> }
> void foo() {
>    int index;
> }
>
> #2
> int fileIndex;
> void foo() {
>    int index;
> }
>
> or perhaps the temporary should be renamed:
>
> int index;
> void foo() {
>    int i;
> }
>
> I appologise for missunderstanding your next comment...
>
>>>> int index_a;
>>>> Foo()
>>>> {
>>>>   int index_A;
>>>>   . . .
>>>>
>>>>   index_a = 1; // Did I really mean this or index_A?
>>>> }
>>>>
>>>> Maybe we could have an explicit resolution mechanism to disambiguate such
>>>> name hiding?
>>>
>>> This is a joke, right? If not please explain.
>>
>> No, it was not a joke. Ok, try not to get hung up with the specific
>> characters I just coincidently happen to use in this reply; try
>> generalizing it instead.
>>
>> But what if, the character '@' when prefixing a symbol name, was an
>> instruction for the compile to use the inner most scope to resolve an
>> otherwise ambiguous symbol name. For example ...
>>
>>   void Foo()
>>   {
>>      int Pretend_That_This_Is_A_Decent_Variable_Name;
>>
>>      {
>>         double Pretend_That_This_Is_A_Decent_Variable_Name;
>>         . . .
>>         // Explicitly refer to the innermost scope.
>>         @Pretend_That_This_Is_A_Decent_Variable_Name += 1.2;
>>      }
>>   }
>>
>> See, no joke involved.
>
> I thought you were referring to the typo above not the original topic when you said "Maybe we could have an explicit resolution mechanism to disambiguate ... ". I thought you might be jokingly suggesting that to resolve the problem with the typo was to type the correct character. :)
>
> Using a symbol to refer to the inner/current scope isn't a bad idea. It's like the "." used for outermost?/module?/file? scope. If however my rule was implemented you wouldn't get as far as to actually use it, as:
>
>>   void Foo()
>>   {
>>      int Pretend_That_This_Is_A_Decent_Variable_Name;
>>
>>      {
>>         double Pretend_That_This_Is_A_Decent_Variable_Name;
>
> would error here.
>
> The rest of the post I have snipped as it appears to me to revolve around our missunderstanding.
>
> Regan

April 04, 2005
On Mon, 04 Apr 2005 16:33:21 +1200, Regan Heath wrote:

> On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>> I've done a bad job of explaining myself. Let me try again:
>>
>> I believe the rule should be "If a variable in a scope hides a variable in an outer scope it is an error" - no exceptions, none.
>>
>> What I was trying to do below was give solutions to the obvious problems this rule will create, reasons for those solutions in terms of good programming practice and the reasons why I see it as good programming practice.

I can live with this. It will mean that occasionally I will be forced to do the 'right thing' but, hey, why not try something new ;-)

-- 
Derek
Melbourne, Australia
4/04/2005 3:36:36 PM
April 04, 2005
On Mon, 4 Apr 2005 15:38:31 +1000, Derek Parnell <derek@psych.ward> wrote:
> On Mon, 04 Apr 2005 16:33:21 +1200, Regan Heath wrote:
>
>> On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>>> I've done a bad job of explaining myself. Let me try again:
>>>
>>> I believe the rule should be "If a variable in a scope hides a variable
>>> in an outer scope it is an error" - no exceptions, none.
>>>
>>> What I was trying to do below was give solutions to the obvious problems
>>> this rule will create, reasons for those solutions in terms of good
>>> programming practice and the reasons why I see it as good programming
>>> practice.
>
> I can live with this. It will mean that occasionally I will be forced to do
> the 'right thing' but, hey, why not try something new ;-)

I realise some people are going to disagree about what the "right thing" to do is.

Of course this *is* a divergance from C/C++ where this is "legal" code (at least according to MSVC).

--[hide.c]--
int the_var = 0;

void foo(int the_var) { the_var = 2; }
void bar() { int the_var; the_var = 3; }

int main()
{
  int the_var = 1;
  foo(the_var);
  bar();
  //for(int the_var = 4;;) { break; }
  for(;;) { int the_var = 5; break; }
  {
    int the_var = 6;
    the_var = 7;
    {
      int the_var = 8;
      the_var = 9;		
    }
  }

  return 0;
}

NOTE: The commented line above, C does not allow this for construction.

--[hide.cpp]--
int the_var = 0;

void foo(int the_var) { the_var = 2; }
void bar() { int the_var; the_var = 3; }

int main()
{
  //int the_var = 1;
  foo(the_var);
  bar();
  for(int the_var = 4;;) { break; }
  for(;;) { int the_var = 5; break; }
  {
    int the_var = 6;
    the_var = 7;
    {
      int the_var = 8;
      the_var = 9;		
    }
  }
	
  return 0;
}

NOTE: The commented line above, if added to the code causes an error on the first for loop. But notice the global did not cause the same error.

Regan

p.s. Did you read/watch the link on IP. IIRC it's basically using a database to detatch the identity of a variable from it's name, allowing you to call variables by the most appropriate name in each situation/location. Sort of like D's alias (but not quite) and sort of like what happens when you pass things to a function i.e.

void foo(int index) {}
int i; //temporary var used to calculate something
i = //calculate something
foo(i);

So 'i' a temporary becomes "index" when passed to foo. The name has changed but the variable is the same.
April 04, 2005
On Mon, 04 Apr 2005 18:00:35 +1200, Regan Heath wrote:

[snip]

> I realise some people are going to disagree about what the "right thing" to do is.
> 
> Of course this *is* a divergance from C/C++ where this is "legal" code (at least according to MSVC).

I still want D to be D, rather than an evolved C, so that's not going to
worry me.

> p.s. Did you read/watch the link on IP.
Yes. Very thought provoking.

-- 
Derek Parnell
Melbourne, Australia
http://www.dsource.org/projects/build/ v1.19 released 04/Apr/2005
http://www.prowiki.org/wiki4d/wiki.cgi?FrontPage
4/04/2005 4:18:46 PM
April 04, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Parnell schrieb am Mon, 4 Apr 2005 15:38:31 +1000:
> On Mon, 04 Apr 2005 16:33:21 +1200, Regan Heath wrote:
>
>> On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>>> I've done a bad job of explaining myself. Let me try again:
>>>
>>> I believe the rule should be "If a variable in a scope hides a variable in an outer scope it is an error" - no exceptions, none.

<snip>

> I can live with this. It will mean that occasionally I will be forced to do the 'right thing' but, hey, why not try something new ;-)

That's sensible - with one restriction: modules are the higest scope level, trying to enforce this for package/subpackage scopes would be troublesome.

Please activate that rule for the -w mode first, so that there is enough time to fix existing code.

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCUOkC3w+/yD4P9tIRAuYQAJ9z3z3tL3UrQmQkiptJ1rP+32ZQkQCbBFNQ
ggz8iZBUVeArGH1qNFnrQFw=
=EL8s
-----END PGP SIGNATURE-----
April 04, 2005
On Mon, 4 Apr 2005 09:13:06 +0200, Thomas Kuehne <thomas-dloop@kuehne.thisisspam.cn> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Derek Parnell schrieb am Mon, 4 Apr 2005 15:38:31 +1000:
>> On Mon, 04 Apr 2005 16:33:21 +1200, Regan Heath wrote:
>>
>>> On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>>>> I've done a bad job of explaining myself. Let me try again:
>>>>
>>>> I believe the rule should be "If a variable in a scope hides a variable
>>>> in an outer scope it is an error" - no exceptions, none.
>
> <snip>
>
>> I can live with this. It will mean that occasionally I will be forced to do
>> the 'right thing' but, hey, why not try something new ;-)
>
> That's sensible - with one restriction: modules are the higest scope
> level, trying to enforce this for package/subpackage scopes would be
> troublesome.

Do you mean?

--[pack\mod1.d]--
int i;

--[pack\mod2.d]--
int i;

--[foo.d]--
import pack.mod1;
import pack.mod2;

i = 5;  <- error, which one.

> Please activate that rule for the -w mode first, so that there is enough time to fix existing code.

Good idea. Walter what do you think?

Regan
April 04, 2005
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Regan Heath schrieb am Tue, 05 Apr 2005 09:45:23 +1200:
> On Mon, 4 Apr 2005 09:13:06 +0200, Thomas Kuehne
><thomas-dloop@kuehne.thisisspam.cn> wrote:
>>
>> Derek Parnell schrieb am Mon, 4 Apr 2005 15:38:31 +1000:
>>> On Mon, 04 Apr 2005 16:33:21 +1200, Regan Heath wrote:
>>>
>>>> On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz> wrote:
>>>>> I've done a bad job of explaining myself. Let me try again:
>>>>>
>>>>> I believe the rule should be "If a variable in a scope hides a
>>>>> variable
>>>>> in an outer scope it is an error" - no exceptions, none.
>>
>> <snip>
>>
>>> I can live with this. It will mean that occasionally I will be forced
>>> to do
>>> the 'right thing' but, hey, why not try something new ;-)
>>
>> That's sensible - with one restriction: modules are the higest scope level, trying to enforce this for package/subpackage scopes would be troublesome.
>
> Do you mean?

<snip>

- --[pack\mod1.d]--
int i;

- --[pack\mod2.d]--
int i; <- error, second i in package scope "pack"

Thomas


-----BEGIN PGP SIGNATURE-----

iD8DBQFCUbwr3w+/yD4P9tIRApMYAKC1GLbWe6wkis53ZbZsr2VAFyvAawCgjpQo
GSGXEvV+dbOoi+XTz9PlQWw=
=yIcs
-----END PGP SIGNATURE-----
April 04, 2005
On Tue, 5 Apr 2005 00:14:04 +0200, Thomas Kuehne <thomas-dloop@kuehne.thisisspam.cn> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Regan Heath schrieb am Tue, 05 Apr 2005 09:45:23 +1200:
>> On Mon, 4 Apr 2005 09:13:06 +0200, Thomas Kuehne
>> <thomas-dloop@kuehne.thisisspam.cn> wrote:
>>>
>>> Derek Parnell schrieb am Mon, 4 Apr 2005 15:38:31 +1000:
>>>> On Mon, 04 Apr 2005 16:33:21 +1200, Regan Heath wrote:
>>>>
>>>>> On Mon, 04 Apr 2005 15:11:14 +1200, Regan Heath <regan@netwin.co.nz>
>>>>> wrote:
>>>>>> I've done a bad job of explaining myself. Let me try again:
>>>>>>
>>>>>> I believe the rule should be "If a variable in a scope hides a
>>>>>> variable
>>>>>> in an outer scope it is an error" - no exceptions, none.
>>>
>>> <snip>
>>>
>>>> I can live with this. It will mean that occasionally I will be forced
>>>> to do
>>>> the 'right thing' but, hey, why not try something new ;-)
>>>
>>> That's sensible - with one restriction: modules are the higest scope
>>> level, trying to enforce this for package/subpackage scopes would be
>>> troublesome.
>>
>> Do you mean?
>
> <snip>
>
> - --[pack\mod1.d]--
> int i;
>
> - --[pack\mod2.d]--
> int i; <- error, second i in package scope "pack"

To me, the above is comparable to:

void pack() {
  { //mod1
    int i;
  }
  { //mod2
    int i;
  }
}

as in mod1 and mod2 are beside each other, one is not inside the other. However, if it were possible for "int i" to exist in "pack" itself, then the one in "mod1" or "mod2" would be in hiding a variable in an outer scope "pack".

Regan
Next ›   Last »
1 2