Is this Dusing libraries with same name or actuall common intermediate langauge. D has it's own gc and the advantage of using that plus other high level features without requiring additional runtime. This is what makes it good but sometimes I use C#. D Libraries that mimic .net libraries may make porting to D easier but otherwise I have no interest in this.

 On Tue, 23 Dec 2008 09:54:29 +1300, Walter Bright <newshound1@digitalmars.com> wrote:

> Progress on implementing D on .NET.
>
> http://www.reddit.com/r/programming/comments/7l5ce/hello_net_d_here_calling/
>
> http://the-free-meme.blogspot.com/2008/12/hello-net-d-here-calling.html

Walter Bright Wrote:

> > Inline Asm code?
> 
> Yes (but it will be .net assembly code, not x86 assembly).

AFAIK, it's possible to use inline asm, since unsafe code is compiled directly to native code.

Steven Schveighoffer Wrote:

> If you have to use .net arrays instead of D arrays in order to use D.net, that would be a deal-killer for me.

Of course, .net arrays will be used, it's .net after all.

Lutger wrote:
> I noticed many developers really adore properties, perhaps it's worth some attention to rethink how this is handled in D. It is used everywhere in .NET.

This is exactly where I'm coming from.  I used to use C# properties a lot.  They are super effective.

Chad J Wrote:
> This is exactly where I'm coming from.  I used to use C# properties a lot.  They are super effective.

In C# you can use for example:

class TimePeriod {
    private double seconds;

    public double Hours {
        get { return seconds / 3600; }
        set { seconds = value * 3600; }
    }
}


Or just:

public double TotalPurchases { get; set; }


Some people have proposed:

public int property Myval {
    get;

    set {
        if (value > 10)
            throw new Exception();
        else
            Myval = value;
    }
}


Time ago I have written this for D1, I don't know if it can be useful:

import std.metastrings: Format;

template AttributeGetSet(Type, string name) {
    const AttributeGetSet = Format!("
        private %s %s__;
        public %s %s() { return this.%s__; }
        public void %s(int %s__local) { this.%s__ = %s__local; }
    ", Type.stringof, name, Type.stringof, name, name, name, name, name, name);
}


C# also has indexers:

>Indexers allow instances of a class or struct to be indexed just like arrays. Indexers resemble properties except that their accessors take parameters.<

http://msdn.microsoft.com/en-us/library/6x16t2tx.aspx

Usage example:

class SampleCollection<T> {
    private T[] arr = new T[100];

    public T this[int i] {
        get {
            return arr[i];
        }

        set {
            arr[i] = value;
        }
    }
}

But to me that looks a lot like the opIndex/opIndexAssign/opIndexLvalue of D.

Bye,
bearophile

bearophile wrote:
> Chad J Wrote:
>> This is exactly where I'm coming from.  I used to use C# properties a
>> lot.  They are super effective.
> 
> In C# you can use for example:
> 
> class TimePeriod {
>     private double seconds;
> 
>     public double Hours {
>         get { return seconds / 3600; }
>         set { seconds = value * 3600; }
>     }
> }
> 
You can also write it in native C++ using microsoft extension:

// declspec_property.cpp
struct S {
   int i;
   void putprop(int j) {
      i = j;
   }

   int getprop() {
      return i;
   }

   __declspec(property(get = getprop, put = putprop)) int the_prop;
};

int main() {
   S s;
   s.the_prop = 5;
   return s.the_prop;
}

> 
> Or just:
> 
> public double TotalPurchases { get; set; }
> 
> 
> Some people have proposed:
> 
> public int property Myval {
>     get;
>         set {
>         if (value > 10)
>             throw new Exception();
>         else
>             Myval = value;
>     }
> }
> 
> 
> Time ago I have written this for D1, I don't know if it can be useful:
> 
> import std.metastrings: Format;
> 
> template AttributeGetSet(Type, string name) {
>     const AttributeGetSet = Format!("
>         private %s %s__;
>         public %s %s() { return this.%s__; }
>         public void %s(int %s__local) { this.%s__ = %s__local; }
>     ", Type.stringof, name, Type.stringof, name, name, name, name, name, name);
> }
> 
> 
> C# also has indexers:
> 
>> Indexers allow instances of a class or struct to be indexed just like arrays. Indexers resemble properties except that their accessors take parameters.<
> 
> http://msdn.microsoft.com/en-us/library/6x16t2tx.aspx
> 
> Usage example:
> 
> class SampleCollection<T> {
>     private T[] arr = new T[100];
> 
>     public T this[int i] {
>         get {
>             return arr[i];
>         }
> 
>         set {
>             arr[i] = value;
>         }
>     }
> }
> 
> But to me that looks a lot like the opIndex/opIndexAssign/opIndexLvalue of D.
> 
> Bye,
> bearophile

Finally I don't think very relevant to have a D.Net because people doing .NET want to have Microsoft support, and it will never be used in real production software.
The only advantage I see is to talk more about D that is for now quite discreet.

On 2008-12-23 11:47:56 +0100, Chad J <gamerchad@__spam.is.bad__gmail.com> said:

> Lutger wrote:
>> I noticed many developers really adore properties, perhaps it's worth some attention to rethink how this is handled in D. It is used everywhere in .NET.
> 
> This is exactly where I'm coming from.  I used to use C# properties a
> lot.  They are super effective.

With no intention to flame, but I never quite understood why people are so keen on properties over getter/setter member functions. What advantage does it have over obscuring direct member access and indirect member access?

I think that the D approach is good enough, since it does not add complexity for library designers.

-- Daniel

Daniel de Kok wrote:

> With no intention to flame, but I never quite understood why people are so keen on properties over getter/setter member functions. What advantage does it have over obscuring direct member access and indirect member access?

This 'obscuring' is exactly what makes properties a bit more attractive. There are a lots of extra little niceties, but I forgot them all (after a two day course on .NET :) ).
But, in the end, properties *are* getter/setter pairs.

> I think that the D approach is good enough, since it does not add complexity for library designers.
> 
> -- Daniel

The D approach is a little more pleasant to write imho, but it's not good enough. You can't write 'foo.bar += n' if bar is a property in D and make that work. Imho, if you can't do that, it doesn't behave like a property, it isn't really a property.

Lutger wrote:
> Daniel de Kok wrote:
> 
>> With no intention to flame, but I never quite understood why people are
>> so keen on properties over getter/setter member functions. What
>> advantage does it have over obscuring direct member access and indirect
>> member access?
> 
> This 'obscuring' is exactly what makes properties a bit more attractive. There are a lots of extra little niceties, but I forgot them all (after a two day course on .NET :) ).
> But, in the end, properties *are* getter/setter pairs.
>  
>> I think that the D approach is good enough, since it does not add
>> complexity for library designers.
>>
>> -- Daniel
> 
> The D approach is a little more pleasant to write imho, but it's not good enough. You can't write 'foo.bar += n' if bar is a property in D and make that work. Imho, if you can't do that, it doesn't behave like a property, it isn't really a property.

We're trying to make that work. D is due for an operator overhaul.

Andrei

"Daniel de Kok" <me@nowhere.nospam> wrote in message news:gir3fq$1qjt$1@digitalmars.com...
> On 2008-12-23 11:47:56 +0100, Chad J <gamerchad@__spam.is.bad__gmail.com> said:
>
>> Lutger wrote:
>>> I noticed many developers really adore properties, perhaps it's worth some attention to rethink how this is handled in D. It is used everywhere in .NET.
>>
>> This is exactly where I'm coming from.  I used to use C# properties a lot.  They are super effective.
>
> With no intention to flame, but I never quite understood why people are so keen on properties over getter/setter member functions. What advantage does it have over obscuring direct member access and indirect member access?
>
> I think that the D approach is good enough, since it does not add complexity for library designers.
>

Library designers are exactly the people that properties are great for. They allow you to expose a "property" of a class in a way that can be changed back and forth between a variable and get/set functions without ever breaking a single line of the library user's code.

For instance, suppose you're writing a class for "Paint", and you want the user to be able to choose and query the color. Sounds to me like a job for a variable. Set/get functions would be overkill. So you do that, release PaintLib v1.0 and people use it and everything's good. Then later, you decide to add some sort of logging that occurs whenever the paint color is changed. Or maybe trigger an animation, or something. Now, "Paint.color" needs to be setters/getters. So you change it to set/get functions and break everyone's code. "Gee, thanks".

Developers in older languages like C++ have gotten around this by learning to religiously make everything set/get functions from day one. This is overkill, a pain in the ass, and with properties, completely unnecessary.

And then there's another reason:

foo.x += 7;

Is a hell of a lot nicer than

foo.setX(foo.getX + 7);

There are ways to improve on that second one, but they all led to either hackiness or odd fringe cases or just simply "still not as good".