On Tue, 08 Sep 2009 19:24:31 -0400, Rainer Deyke <[email protected]> wrote:

Steven Schveighoffer wrote:
On Tue, 08 Sep 2009 15:50:15 -0400, Rainer Deyke <[email protected]>
wrote:
Yes, in this particular case, passing a default value would work just as
well.  But what if you want to cache the contents of the entire
configuration file?  What if calculating the default value is an
expensive operation that should be avoided if possible?

You're reaching here :)  A default configuration value that is expensive
to calculate?

New example:

struct AlgebraicFunction {
  double getMaximum() {
    if (isNull(this.cachedMaximum)) {
      this.cachedMaximum = this.veryExpensiveCalculation();
    }
    return *this.cachedMaximum;
  }

  private Optional!(Optional!double) cached_maximum;
}

Another bad example.


struct AlgebraicFunction {
   double getMaximum() {
     if (!cache_valid) {
       this.cachedMaximum = this.veryExpensiveCalculation();
       cache_valid = true;
     }
return this.cachedMaximum; // hey, I thought you only use struct pointers like (*x).member?
   }

   private Optional!double cached_maximum;
   private bool cache_valid = false;
}


I understand what you are saying, but often times (as I have learned
from my own crusades on the NG), when it is hard to find good cases for
an argument, it means the argument is superficial or academic.  I could
very well be wrong, but to me, the practicality of the offered use cases
is important when evaluating whether to complicate syntax.

I think it's much more important to have clear consistent semantics than
convenient syntactic shortcuts.  I don't want D to turn into Perl.

It is clear and consistent, it's just not defined how you would like. What you want does not bring anything significant to the table as far as the vast majority of cases.

I thought it was to provide a way to make a value type have an "unset"
value.

The point is to have a type that can represent all possible values of T,
plus an additional singular value, for all possible types of T.

Here we simply disagree.


You can't have that, because 'v' is already the container. The best you
can get is a proxy that sometimes acts like a containee, but really
isn't.  This kind of sloppy thinking has no place in computer
programming.

You mean like struct pointers? Generic type wrappers?  Remote object
proxies? :P

These examples of proxies are also a bad idea.  When I want to access a
member of a struct through a pointer, I use '(*p).x'.

Then you are going against well established programming techniques already in place in D. Not that you aren't allowed to have your opinion, but I don't think it's going to get much agreement from D's developers.

-Steve

Reply via email to