www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Class variables in optional parameters?

reply AJG <AJG_member pathlink.com> writes:
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.
Jul 16 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Sat, 16 Jul 2005 23:07:21 +0000 (UTC), 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...

This has come up before but I didn't notice a definitive reason why it works like it does. It appears that if you supply a default value to a parameter, that default value must be known, or gettable, at compile time. If you change it to "static bool Bar = true;" it compiles but that may not be what you want either. -- Anonymous Bosch -- The view will be the same no matter which path you take to the mountain top.
Jul 16 2005
parent AJG <AJG_member pathlink.com> writes:
Hi,

This has come up before but I didn't notice a definitive reason why it
works like it does. 

Hm... interesting.
It appears that if you supply a default value to a parameter, that default
value must be known, or gettable, at compile time. 

This is unfortunate. Is this at least considered a technical limitation rather than a feature? I mean, semantically, I don't see why it shouldn't be allowed.
If you change it to "static bool Bar = true;" it compiles but that may not
be what you want either.

Indeed, it would be something different. I'll post an example in my reply to Ben if you are interested. Thanks, --AJG.
Jul 16 2005
prev sibling next sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 # class Foo {
 #     bool Bar = true;
 #     public      this(bool bar = Bar) {} // In constructors?
 #     public void func(bool bar = Bar) {} // In regular funcs?
 # }

Note default values must be known at compile-time. So I assume you meant something like class Foo { bool Bar = true; public this(bool bar = Bar.init) {} // In constructors? public void func(bool bar = Bar.init) {} // In regular funcs? }
Jul 16 2005
parent reply AJG <AJG_member pathlink.com> writes:
Hi,

Note default values must be known at compile-time. So I assume you meant 
something like

 class Foo {
     bool Bar = true;
     public      this(bool bar = Bar.init) {} // In constructors?
     public void func(bool bar = Bar.init) {} // In regular funcs?
 }

Well, yes and no. For the constructor, yes. For the regular function, no. In my class, Bar is a setting. So, I want to specify the _default_ value for this setting in the initilizer. Ideally, I also want to specify this default only once. # bool Bar = true; // This is what it should be without user intervention. Then, in the constructor, I want to offer the possibility of overriding the default. In _this_ case, .init would work, because Bar couldn't have been altered. # public this(bool bar = Bar.init) {} // This is fine. However, I have another function where it makes sense to also allow for this default to be overridden. Now .init wouldn't work, because the user could have set Bar to a non-default via the constructor. So then: # public void func(bool bar = Bar.init) {} // This is wrong. Because it forces the user to either re-specify the setting or be stuck with the default. If this is the case, then it conflicts with this setting in the constructor. Ideally, he can ommit the parameter so it means "use what I already specified." Is there a way to fix this? Thanks, --AJG.
Jul 16 2005
parent "Ben Hinkle" <ben.hinkle gmail.com> writes:
"AJG" <AJG_member pathlink.com> wrote in message 
news:dbc88m$2es1$1 digitaldaemon.com...
 Hi,

Note default values must be known at compile-time. So I assume you meant
something like

 class Foo {
     bool Bar = true;
     public      this(bool bar = Bar.init) {} // In constructors?
     public void func(bool bar = Bar.init) {} // In regular funcs?
 }

Well, yes and no. For the constructor, yes. For the regular function, no. In my class, Bar is a setting. So, I want to specify the _default_ value for this setting in the initilizer. Ideally, I also want to specify this default only once.

Without having more context I'd say you should use overloading class Foo { bool defaultbar = true; public this(bool bar = defaultbar.init) {defaultbar = bar;} public void func() {func(defaultbar);} public void func(bool bar) {...} }
Jul 16 2005
prev sibling next sibling parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
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 ?
    }
}
Jul 16 2005
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
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) or public void func(Foo f, bool bar = f.Bar) ? Regan
Jul 16 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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.
 or

 public void func(Foo f, bool bar = f.Bar)

Better, but too complicated for compilation and codegeneration. Is not worth doing as it always could be replaced by public void func(Foo f, bool bar); .... func(f, f.Bar);
Jul 16 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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.
 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?
 Is not worth doing as it always could be replaced by

 public void func(Foo f, bool bar);
 ....
 func(f, f.Bar);

IYNSHO. Regan
Jul 16 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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

Jul 16 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 17 2005
parent reply "Andrew Fedoniouk" <news terrainformatica.com> writes:
 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.
Jul 17 2005
parent reply "Regan Heath" <regan netwin.co.nz> writes:
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
Jul 17 2005
parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"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

Jul 17 2005
prev sibling parent AJG <AJG_member pathlink.com> writes:
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.
Jul 16 2005
prev sibling parent Deewiant <deewiant.doesnotlike.spam gmail.com> writes:
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.
 
 

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?
Jul 17 2005