Hi,

>Consider this:
>
>class Foo {
>    bool Bar = true;
>    public void func(Foo f, bool bar = Bar)
>    {
>         f.func( f );  // what is supposed to be used here:
>         // this.bar or f.bar ?
>    }
>}

Hm... this.bar and f.bar don't exist. Do you mean this.Bar and f.Bar? If yes, then I don't see what the problem is. If called without specifying the second parameter, then within the function body, bar is set to whatever it's containing instance's Bar is. AFAIK this is fairly unambigous.

I'm confused by your example. Why are you looking at it from the view of the caller and not the callee's? It's much simpler to me if you look at it from the callee's perspective: small bar is set to whatever big Bar is in the scope immediately above - in this case, the instance of the class.

If I didn't get your point, could you post a clearer example? Sorry for being dense.

Cheers,
--AJG.

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opst1f3ikp23k2f5@nrage.netwin.co.nz...
> On Sat, 16 Jul 2005 20:08:14 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> "Regan Heath" <regan@netwin.co.nz> wrote in message news:opst1c65bk23k2f5@nrage.netwin.co.nz...
>>> On Sat, 16 Jul 2005 19:25:14 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>>>> Consider this:
>>>>
>>>> class Foo {
>>>>     bool Bar = true;
>>>>     public void func(Foo f, bool bar = Bar)
>>>>     {
>>>>          f.func( f );  // what is supposed to be used here:
>>>>          // this.bar or f.bar ?
>>>>     }
>>>> }
>>>
>>> So why not:
>>>
>>> public void func(Foo f, bool bar = this.Bar)
>>>
>>
>> Parameters are in separate namespace from function body
>> - no 'this' there.
>
> So? Change it.

What for?

>
>>> or
>>>
>>> public void func(Foo f, bool bar = f.Bar)
>>>
>>
>> Better, but too complicated for compilation and codegeneration.
>
> Who are you to make this assertion?

Author of programming language, its
compiler and VM. :)

>
>> Is not worth doing as it always could be replaced by
>>
>> public void func(Foo f, bool bar);
>> ....
>> func(f, f.Bar);
>
> IYNSHO.
>
> Regan

AJG wrote:
> Hi,
> 
> I'm not sure if this is a bug or not, but it seems like the following behaviour should be allowed:
> 
> # class Foo {
> #     bool Bar = true;
> #     public      this(bool bar = Bar) {} // In constructors?
> #     public void func(bool bar = Bar) {} // In regular funcs?
> # }
> 
> Actually, neither of those works. I'm getting:
> # need 'this' to access member Bar
> 
> If I change it to this.Bar, then I get:
> # 'this' is only allowed in non-static member functions
> 
> As a matter of fact, neither the constructor nor the func is static. What's the deal? Is this a bug or per-design? I hope the former...
> 
> Thanks,
> --AJG.
> 
> 
I had this problem here: http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D.bugs/4539

The solution, from David Medlock, unfortunately does not work here. It would be to set bar = null by default, and then to place in the function body a check "if (bar is null) bar = Bar;". It worked in my case, as I was working with function pointers.

Alas, bits only have two values, true and false, and it would break your code to have something like "this(bool bar = true) { if (bar) bar = Bar; }". You could use some sort of a dummy parameter, perhaps?

On Sat, 16 Jul 2005 21:41:09 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
> "Regan Heath" <regan@netwin.co.nz> wrote in message
> news:opst1f3ikp23k2f5@nrage.netwin.co.nz...
>> On Sat, 16 Jul 2005 20:08:14 -0700, Andrew Fedoniouk
>> <news@terrainformatica.com> wrote:
>>> "Regan Heath" <regan@netwin.co.nz> wrote in message
>>> news:opst1c65bk23k2f5@nrage.netwin.co.nz...
>>>> On Sat, 16 Jul 2005 19:25:14 -0700, Andrew Fedoniouk
>>>> <news@terrainformatica.com> wrote:
>>>>> Consider this:
>>>>>
>>>>> class Foo {
>>>>>     bool Bar = true;
>>>>>     public void func(Foo f, bool bar = Bar)
>>>>>     {
>>>>>          f.func( f );  // what is supposed to be used here:
>>>>>          // this.bar or f.bar ?
>>>>>     }
>>>>> }
>>>>
>>>> So why not:
>>>>
>>>> public void func(Foo f, bool bar = this.Bar)
>>>>
>>>
>>> Parameters are in separate namespace from function body
>>> - no 'this' there.
>>
>> So? Change it.
>
> What for?

So this would work, obviously ;)
Can you see any reasons why it is a bad idea?

>>>> public void func(Foo f, bool bar = f.Bar)
>>>>
>>>
>>> Better, but too complicated for compilation and
>>> codegeneration.
>>
>> Who are you to make this assertion?
>
> Author of programming language, its
> compiler and VM. :)

Cool. However, "too complicated" is a relative statement, too complicated compared to what? If it adds value then you can compare that value to the complexity. In the end it's not your decision, it's Walters.

Regan

> Cool. However, "too complicated" is a relative statement, too complicated compared to what? If it adds value then you can compare that value to the complexity. In the end it's not your decision, it's Walters.

:) Sure. But even Walter cannot increase value of Pi constant.

Regan, here is the book:
Niklaus Wirth, "Compiler Construction"
http://www.cs.inf.ethz.ch/~wirth/books/CompilerConstruction/
It is just 200 pages or so.
Trust me - it is worth reading.

On Sun, 17 Jul 2005 10:25:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>> Cool. However, "too complicated" is a relative statement, too complicated
>> compared to what? If it adds value then you can compare that value to the
>> complexity. In the end it's not your decision, it's Walters.
>
> :) Sure. But even Walter cannot increase value of Pi constant.

Sure, but this is not a mathematical constant, nor can it be compared to one (aka this argument you make holds no water).

> Regan, here is the book:
> Niklaus Wirth, "Compiler Construction"
> http://www.cs.inf.ethz.ch/~wirth/books/CompilerConstruction/
> It is just 200 pages or so.
> Trust me - it is worth reading.

Thanks, I'll take a look.

Regan

"Regan Heath" <regan@netwin.co.nz> wrote in message news:opst2sndap23k2f5@nrage.netwin.co.nz...
> On Sun, 17 Jul 2005 10:25:30 -0700, Andrew Fedoniouk <news@terrainformatica.com> wrote:
>>> Cool. However, "too complicated" is a relative statement, too
>>> complicated
>>> compared to what? If it adds value then you can compare that value to
>>> the
>>> complexity. In the end it's not your decision, it's Walters.
>>
>> :) Sure. But even Walter cannot increase value of Pi constant.
>
> Sure, but this is not a mathematical constant, nor can it be compared to one (aka this argument you make holds no water).

Feel the force, it does "have a water".

You can change Pi as any other fundamental constants.
You just need to move planet to the place where
you can enjoy non-euclidian geometry: e.g. to
neighbourghood of black hole.

>
>> Regan, here is the book:
>> Niklaus Wirth, "Compiler Construction"
>> http://www.cs.inf.ethz.ch/~wirth/books/CompilerConstruction/
>> It is just 200 pages or so.
>> Trust me - it is worth reading.
>
> Thanks, I'll take a look.
>
> Regan