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. - C# is not that far from D, and it has several advantages (named arguments, 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 compete with C#? While I can see how normal compiled D may compete with C# in some lower level niche, I don't see yet how D.net may compete with C#. What has D# to offer over C#? Maybe nothing? 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
between the Phobos and Tango communities, with now just a common kernel). D#
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.
 - C# is not that far from D, and it has several advantages (named
 arguments, 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 compete with C#? While I can see how
 normal compiled D may compete with C# in some lower level niche, I
 don't see yet how D.net may compete with C#. What has D# to offer
 over C#? Maybe nothing?

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

Uhmmmm... So far I don't see much advantages of using D# over C#. In C# 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. More: How can the dotnet GC support all the capabilities of D code? :-) I think SafeD# can run pretty well on dotnet. It can even use the dotnet GC to its fullest, if SafeD# is well implemented. Note that there are ways to translate dotnet IL to VM asm of the JavaVM, so later you may be able to run this D# on the JVM too. ----------------------- 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.
I think D's syntax is far superior to C#<

I have already listed several advantages of C# over D and more can be written. 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.
I think D's syntax is far superior to C#<

I have already listed several advantages of C# over D and more can be written. So I don't agree much.

foreach in C# sucks compared to D arrays in C# suck compared to D 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. Basically, when I start working on C# programs after working on D programs, 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.<

Uhmmmm... So far I don't see much advantages of using D# over C#. In C# 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; } Try doing that in 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 my C# projects, which run just like normal executables. They perform just 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?
 - C# is not that far from D, and it has several advantages (named 
 arguments, 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 compete with C#? While I can see how normal 
 compiled D may compete with C# in some lower level niche, I don't see yet 
 how D.net may compete with C#. What has D# to offer over C#? Maybe 
 nothing?

I think D's syntax is far superior to C# (save some C# features such as 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
be migrating to C# too, I'm sure they will love D.NET. 

Right now I'm trying to get into the programming business and C# is my best
option. I was amazed to find out I could just program in C# without any
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
modest things I missed in C# too. It's type inference is inferior for example,
and lack of free functions very annoying. Also nothing as clean as scope
statements.  

C# on the other hand has reflection, properties and Linq, which is just
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.

The fact that C# and D are so similar will only help C# programmers migrating
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.

This is exactly where I'm coming from. I used to use C# properties a lot. They are super effective.
Dec 23 2008
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
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
Dec 23 2008
parent Mosfet <mosfet anonymous.org> writes:
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; } } }

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

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

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".
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 C# 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
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.
 Not that I religiously want to debate against properties, but I think C# 
 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  
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

Dec 22 2008