www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Hello .NET, D Here Calling

reply Walter Bright <newshound1 digitalmars.com> writes:
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
Dec 22 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright Wrote:


Progress on implementing D on .NET.<


- This sounds quite incredible :-)
- The more implementations of D there are, the more the language will have a
chance to stick and become used, so I think this is a good thing, regardless
what I say below.
- But is the dotnet able to support all things D supports? For example can you
implement unions? Inline Asm code? How about the interface with compiled C
code? Etc.
- One of the advantages of D, that is it produces true compiled executables, is
lost here.
- I think performance on dotnet can be good enough for most programs, but a
good C++-grade compiler like LLVM (LDC) can sometimes give even more running
speed.
- D is supposed to be a system language, but I don't know if you can write
system languages on dotnet, maybe not.

better lambda, is much more widely used, more built-in reflection, LINQ, a way
to support duck typing, run-time compilation of code, etc etc), so how can D




Bye,
bearophile
Dec 22 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
There's also a risk: D has already unstable standard library (the division

will have to use the libs of the dotnet, so it will use yet another standard
lib. This will split in 3 parts the D community.

Bye,
bearophile
Dec 22 2008
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
bearophile wrote:

 Walter Bright Wrote:
 

 Progress on implementing D on .NET.<


 
 - This sounds quite incredible :-)


Cristi is an awesome and prolific developer. (He wrote the Zerobugs D 
debugger for Linux.)


 - The more implementations of D
 there are, the more the language will have a chance to stick and
 become used, so I think this is a good thing, regardless what I say
 below.


Yes.


 - But is the dotnet able to support all things D supports?


Yes. (!)


 For example can you implement unions?


Yes.


 Inline Asm code?


Yes (but it will be .net assembly code, not x86 assembly).


 How about the interface with compiled C code?


Yes.


 Etc. - One of the advantages of D,
 that is it produces true compiled executables, is lost here.


That's like saying that an advantage of D is that it can run under 
Windows, an advantage that is lost when one runs it under Linux. <g> 
D.Net expands the options, not shrinks them.


 - I think performance on dotnet can be good enough for most programs, but
 a good C++-grade compiler like LLVM (LDC) can sometimes give even
 more running speed.


Native D compilers aren't going away. There's no plan and no way D will 
become a .net-only language. All it is is expanding D's domain.


 - D is supposed to be a system language, but I
 don't know if you can write system languages on dotnet, maybe not.


You're right, but that doesn't matter. Use a D native compiler to do a 
system app. Use D.net to write an application that wants to interact 
with the .net ecosystem.



 arguments, better lambda, is much more widely used, more built-in
 reflection, LINQ, a way to support duck typing, run-time compilation






Advanced generative and metaprogramming capabilities for starters.
Dec 22 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter Bright:


Yes (but it will be .net assembly code, not x86 assembly).<


I see, this is curious :-) And is inlining dotnet IL useful for something? :-)



All it is is expanding D's domain.<


I understand the point, and you are right.



Advanced generative and metaprogramming capabilities for starters.<



even have advanced (and recently easy enough to use too) ways to even generate
code at run time. So I am not convinced yet.

More:

How can the dotnet GC support all the capabilities of D code? :-)




Note that there are ways to translate dotnet IL to VM asm of the JavaVM, so


-----------------------

Steven Schveighoffer:


What is the advantage you see here?<


You don't need a huge VM to run them. I know lot of people don't care of this,
so please ignore me.







So I don't agree much.

Bye,
bearophile
Dec 22 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"bearophile" wrote

 Steven Schveighoffer:


What is the advantage you see here?<


 You don't need a huge VM to run them. I know lot of people don't care of 
 this, so please ignore me.


that is a good point.  But you are also right that I don't care :)  I 
already have to have .net for many other things so the space penalty is a 
wash anyways.






 written. So I don't agree much.




no auto (at least in VS2005) (this is alleviated a lot by the Visual Studio 
IDE though)
virtual functions require a 'virtual' marker.
overriding virtual functions requires an 'override' marker
delegates suck compared to D.


I find myself REALLY missing some of these syntaxes (esp. arrays).  Note 
that it's not that the features are *missing*, it's that *using* the 
features is not as nice.  Let's face it, all .net programs boil down to the 
same code anways, it's the syntax that makes the differences.

-Steve
Dec 22 2008
prev sibling parent "Nick Sabalausky" <a a.a> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:gip4o7$1pqj$1 digitalmars.com...

Advanced generative and metaprogramming capabilities for starters.<



 you even have advanced (and recently easy enough to use too) ways to even 
 generate code at run time. So I am not convinced yet.


T foo(T)(T a, T b, T c)
{
    return (a * b) + c;
}
Dec 22 2008
prev sibling parent Kagamin <spam here.lot> writes:
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.
Dec 23 2008
prev sibling parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"bearophile" wrote

 - But is the dotnet able to support all things D supports? For example can 
 you implement unions? Inline Asm code? How about the interface with 
 compiled C code? Etc.


C++.net works just fine, and supports unions, etc.  Anything that C++ 
supports.  The difference is that you mark code that can be compiled into 
CLR and code that cannot. This provides a somewhat simple bridge between 
.NET and standard C functions.  Most likely, D.net would be the same way.

Asking if .net can support everything that D does is like asking if C can 
support everything that D does.  You can call C functions from D, even write 
D functions that are callable from C, but you don't write D code in C.


 - One of the advantages of D, that is it produces true compiled 
 executables, is lost here.



 - I think performance on dotnet can be good enough for most programs, but 
 a good C++-grade compiler like LLVM (LDC) can sometimes give even more 
 running speed.


What is the advantage you see here?  Visual studio produces .exe files from 

as well as C++ programs as far as I can tell.  As far as I'm concerned, they 
*are* compiled executables.  Who cares if they are morphed into native 
binary code when I run them?



 arguments, better lambda, is much more widely used, more built-in 
 reflection, LINQ, a way to support duck typing, run-time compilation of 



 nothing?



properties).  However, I do see issues with how to make D conform to .net 
without affecting the syntax benefits.  For example, how do you call .net 
functions with D arrays?  .net arrays are classes, whereas D arrays are 
structs.  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.

-Steve
Dec 22 2008
parent Kagamin <spam here.lot> writes:
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.
Dec 23 2008
prev sibling next sibling parent John Reimer <terminal.node gmail.com> writes:
Hello Walter,


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



He mentioned this to me in an email recently when I was asking for help with 
zerobugs.

I think it is a great idea, and he's probably just the one to do it.  A few 
D members have made some attempts at .NET interfacing in the past, but I 
don't think any have attempted what he is doing.

At the least, it will be a good opportunity to put SafeD to good use. :)

If this works out, it might prove the feasability of a Mono project as well.

-JJR
Dec 22 2008
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
This is very exciting! 

.NET is the platform microsoft is pushing applications developers on, it will
be very relevant for D if it can be used there. Loads of C++ developers seem to




learning. It's almost an exact subset of D, with many limitations and a bit
more verbosity.

In addition to much better generic and metaprogramming, there are lots of more

and lack of free functions very annoying. Also nothing as clean as scope
statements.  


awesome. 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.


to D.NET ;)
Dec 22 2008
parent reply Chad J <gamerchad __spam.is.bad__gmail.com> writes:
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.



lot.  They are super effective.
Dec 23 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Chad J Wrote:


 lot.  They are super effective.




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);
}





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
Dec 23 2008
parent Mosfet <mosfet anonymous.org> writes:
bearophile wrote:

 Chad J Wrote:


 lot.  They are super effective.


 

 
 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);
 }
 
 

 

 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.
Dec 23 2008
prev sibling parent reply Daniel de Kok <me nowhere.nospam> writes:
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.


 

 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
Dec 23 2008
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
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.
Dec 23 2008
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Dec 23 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"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.



 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".
Dec 23 2008
parent reply Daniel de Kok <me nowhere.nospam> writes:
On 2008-12-23 20:09:56 +0100, "Nick Sabalausky" <a a.a> said:


 "Daniel de Kok" <me nowhere.nospam> wrote in message
 news:gir3fq$1qjt$1 digitalmars.com...

 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.


So can they do with getters and setters.


 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.


Some would call it overkill, some would call it proper encapsulation. 
Personally, I never allow direct access to member variables (except for 
types that have no 'behavior'). It comes at virtually no extra cost, 
and there is a good chance that simple setters will require some 
validation or locking in the future anyway.


 So you change it to set/get functions and break everyone's code. "Gee, thanks".


That wouldn't happen, since I'd use getters/setters anyway ;). So far, 
the only advantage is the presumption that getters/setters are overkill.


 And then there's another reason:
 
 foo.x += 7;
 
 Is a hell of a lot nicer than
 
 foo.setX(foo.getX + 7);


Maybe, but in the setter case you can explicitly see what is going on. 
Would you expect something that looks like a variable assignment to 
throw an exception or to perform validation?

Not that I religiously want to debate against properties, but I think 

things one could easily do without. But then on the other hand, a lot 
of people are also happy with Java, which misses basic things like 
typedefs ;).

-- Daniel
Dec 23 2008
next sibling parent bearophile <bearophileHUGS lycos.com> writes:
Daniel de Kok:

 It comes at virtually no extra cost, 
 and there is a good chance that simple setters will require some 
 validation or locking in the future anyway.


It comes at no cost in Java, for example on the HotSpot JVM, and probably on
dotnet too. But probably the current D compilers aren't that smart, and you
have to pay a small cost (time) there. I don't know how LDC will do in such
regard, probably about the same. (But it's a little cost that most of the times
you are willing to pay in D too.)

Bye,
bearophile
Dec 23 2008
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel de Kok" <me nowhere.nospam> wrote in message 
news:girh4b$2gss$1 digitalmars.com...

 On 2008-12-23 20:09:56 +0100, "Nick Sabalausky" <a a.a> said:


 "Daniel de Kok" <me nowhere.nospam> wrote in message
 news:gir3fq$1qjt$1 digitalmars.com...

 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.


 So can they do with getters and setters.


 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.


 Some would call it overkill, some would call it proper encapsulation. 
 Personally, I never allow direct access to member variables (except for 
 types that have no 'behavior'). It comes at virtually no extra cost, and 
 there is a good chance that simple setters will require some validation or 
 locking in the future anyway.


 So you change it to set/get functions and break everyone's code. "Gee, 
 thanks".


 That wouldn't happen, since I'd use getters/setters anyway ;). So far, the 
 only advantage is the presumption that getters/setters are overkill.


It's far more than a mere presumption:

class Foo{
  public int x;
}

// vs

class Foo{
  private int _x;
  public int getX() {
      return x;
  }
  public void setX(int x) {
      _x = x;
  }
}

It would take a Java mentality to find the second to be every bit as good as 
the first. Yes, it's functionally equivilent, but it's a horrid mess and 
provides absolutely no benefit in a language that supports properties. Note 
also, that the second form provides absolutely no more encapsulation 
benefits than the first. The only reason that idiom was ever created in the 
first place, and the only reason it's ever used (and the only reason public 
member variables were ever deemed to be bad style in the first place) is to 
provide an "upgrade path" in case more functionality is needed. Properties 
render that all irrelevant, and allow variables to once again be used for 
what they were actually intended for in the first place. (Also, they 
eliminate the need for getter/setter naming conventions.)


 And then there's another reason:

 foo.x += 7;

 Is a hell of a lot nicer than

 foo.setX(foo.getX + 7);


 Maybe, but in the setter case you can explicitly see what is going on. 
 Would you expect something that looks like a variable assignment to throw 
 an exception or to perform validation?


Debatable, there are reasonable arguments on both sides (Personally, I find 
the latter to be a case of "mixing different levels of abstraction" and thus 
poor design for the same reason that not using functions is poor design: 
Implementation details *should* be abstracted away so they don't obscure the 
high-level concept of what you're doing. Take a look at the iterators and 
explicit (un)boxing in older versions of Java to see what a horrendous 
unreadable (and slow-to-develop) mess code becomes when you expect every 
line of code to be transparent.)

But regardless, if you're one of the many people that accept operator 
overloading, then the debate is moot: Operator overloading is every bit as 
capable of making what looks like a trivial operation do non-trivial things.



 has its amount of feature-creep, and I think this is one of the things one 
 could easily do without. But then on the other hand, a lot of people are 
 also happy with Java, which misses basic things like typedefs ;).

 -- Daniel
Dec 23 2008
parent reply Daniel de Kok <me nowhere.nospam> writes:
On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a a.a> said:

 It's far more than a mere presumption:
 
 class Foo{
   public int x;
 }
 
 // vs
 
 class Foo{
   private int _x;
   public int getX() {
       return x;
   }
   public void setX(int x) {
       _x = x;
   }
 }
 
 It would take a Java mentality to find the second to be every bit as good as
 the first. Yes, it's functionally equivilent, but it's a horrid mess


I happen to disagree :^).


 provides absolutely no benefit in a language that supports properties. Note
 also, that the second form provides absolutely no more encapsulation
 benefits than the first.


It *does* provide more encapsulation, since you could modify the getter 
or setter without changes for the called. This was supposed to be one 
of the advantages of encapsulation (and it is).


 But regardless, if you're one of the many people that accept operator
 overloading, then the debate is moot: Operator overloading is every bit as
 capable of making what looks like a trivial operation do non-trivial things.


I agree, and am not to fond of operator overloading. Of course, in C++ 
it is pretty much unavoidable for assignment and comparison. There is a 
place for operator overloading, e.g. in math labraries. But I don't 
like overuse of operator+ for, say, assigning widgets to some 
container, or operator* for string multiplication (as in Python).

But I guess there's also much taste involved, some people don't like 
verbosity ;).

-- Daniel
Dec 23 2008
next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Daniel de Kok" <me nowhere.nospam> wrote in message 
news:girn6u$2sn4$1 digitalmars.com...

 On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a a.a> said:

 It's far more than a mere presumption:

 class Foo{
   public int x;
 }

 // vs

 class Foo{
   private int _x;
   public int getX() {
       return x;
   }
   public void setX(int x) {
       _x = x;
   }
 }

 It would take a Java mentality to find the second to be every bit as good 
 as
 the first. Yes, it's functionally equivilent, but it's a horrid mess


 I happen to disagree :^).


 provides absolutely no benefit in a language that supports properties. 
 Note
 also, that the second form provides absolutely no more encapsulation
 benefits than the first.


 It *does* provide more encapsulation, since you could modify the getter or 
 setter without changes for the called. This was supposed to be one of the 
 advantages of encapsulation (and it is).


How is that any different from the first form (in a language that supports 
properties)? Like I've been saying, with properties, you *can* change 
"public int x;" into any form of getters/setters without any changes for the 
caller. That's one of the main points of properties. So as long as a 
language supports properties, the encapsulation is exactly the same. The 
idea that "public int x;" has less encapsulation is *only* true when a 
language doesn't support properties.
Dec 23 2008
parent Daniel de Kok <me nowhere.nospam> writes:
On 2008-12-24 02:52:56 +0100, "Nick Sabalausky" <a a.a> said:


 "Daniel de Kok" <me nowhere.nospam> wrote in message
 news:girn6u$2sn4$1 digitalmars.com...

 On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a a.a> said:

 It's far more than a mere presumption:
 
 class Foo{
 public int x;
 }
 
 // vs
 
 class Foo{
 private int _x;
 public int getX() {
 return x;
 }
 public void setX(int x) {
 _x = x;
 }
 }
 
 It would take a Java mentality to find the second to be every bit as good
 as
 the first. Yes, it's functionally equivilent, but it's a horrid mess


 
 I happen to disagree :^).
 

 provides absolutely no benefit in a language that supports properties.
 Note
 also, that the second form provides absolutely no more encapsulation
 benefits than the first.


 
 It *does* provide more encapsulation, since you could modify the getter or
 setter without changes for the called. This was supposed to be one of the
 advantages of encapsulation (and it is).
 


 
 How is that any different from the first form (in a language that supports
 properties)?


I am not saying it is different. I was just replying to your statement 
considering the example that the second form does not provide more 
encapsulation.

-- Daniel
Dec 24 2008
prev sibling parent Chad J <gamerchad __spam.is.bad__gmail.com> writes:
Daniel de Kok wrote:

 On 2008-12-23 22:10:53 +0100, "Nick Sabalausky" <a a.a> said:

 It's far more than a mere presumption:

 class Foo{
   public int x;
 }

 // vs

 class Foo{
   private int _x;
   public int getX() {
       return x;
   }
   public void setX(int x) {
       _x = x;
   }
 }

 It would take a Java mentality to find the second to be every bit as
 good as
 the first. Yes, it's functionally equivilent, but it's a horrid mess


 
 I happen to disagree :^).
 


I suppose you're right.  The horribly twisted mind of a C++ coder could
find that attractive as well.
Dec 23 2008
prev sibling parent Christopher Wright <dhasenan gmail.com> writes:
Daniel de Kok wrote:

 Maybe, but in the setter case you can explicitly see what is going on. 
 Would you expect something that looks like a variable assignment to 
 throw an exception or to perform validation?


If a field should be validated, I want it to be validated every time I 
assign to it. Otherwise I get an exception at some random time, and I 
have to do a lot of work in order to find out where I set a bad value.
Dec 23 2008
prev sibling parent Kagamin <spam here.lot> writes:
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?


High level languages were invented to power programming with abstractions.
Dec 24 2008
prev sibling parent "Tim M" <a b.com> writes:
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  

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
Dec 22 2008