digitalmars.D - Class variables in optional parameters?

AJG (16/16) Jul 16 2005 Hi,

Derek Parnell (12/31) Jul 16 2005 This has come up before but I didn't notice a definitive reason why it

AJG (8/14) Jul 16 2005 This is unfortunate. Is this at least considered a technical limitation ...

Ben Hinkle (7/12) Jul 16 2005 Note default values must be known at compile-time. So I assume you meant...

AJG (21/28) Jul 16 2005 Well, yes and no. For the constructor, yes. For the regular function, no...

Ben Hinkle (9/25) Jul 16 2005 Without having more context I'd say you should use overloading

Andrew Fedoniouk (9/9) Jul 16 2005 Consider this:

Regan Heath (8/17) Jul 16 2005 So why not:

Andrew Fedoniouk (10/26) Jul 16 2005 Parameters are in separate namespace from function body

Regan Heath (6/37) Jul 16 2005 So? Change it.

Andrew Fedoniouk (5/45) Jul 16 2005 What for?

Regan Heath (8/46) Jul 17 2005 So this would work, obviously ;)

Andrew Fedoniouk (6/9) Jul 17 2005 :) Sure. But even Walter cannot increase value of Pi constant.

Regan Heath (6/17) Jul 17 2005 Sure, but this is not a mathematical constant, nor can it be compared to...

Andrew Fedoniouk (7/25) Jul 17 2005 Feel the force, it does "have a water".

AJG (13/22) Jul 16 2005 Hm... this.bar and f.bar don't exist. Do you mean this.Bar and f.Bar? If...

Deewiant (10/34) Jul 17 2005 I had this problem here:

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:







Actually, neither of those works. I'm getting:


If I change it to this.Bar, then I get:


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

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:
 





 
 Actually, neither of those works. I'm getting:

 
 If I change it to this.Bar, then I get:

 
 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

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

"Ben Hinkle" <ben.hinkle gmail.com> writes:







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

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.



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.



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:



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

"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