www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Safe Navigation Operator =?UTF-8?B?4oCcPy7igJ0=?= for D2 ?

reply "Remo" <remo4d gmail.com> writes:
Apparently C# will get it in the next version.
http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

What do you think how well would this work in D2 ?
Feb 27 2014
next sibling parent "Asman01" <jckj33 gmail.com> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

I was just thinking to create this topic but you did first, haha. I like that, to me +1 for implement.
Feb 27 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

I like it. At my previous job, I extended std.json with an array index operator just to end up replacing it with a variadic getter to get around the problem of incomplete paths. Like that, there are some ways to get around this sort of issue, but I wouldn't complain about having it right out of the box. Perhaps there should also be a ?[] operator. foo?["a"]?[0]?["llama"]
Feb 27 2014
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Wish I could locate bearophile's post on the topic, sadly ?. isn't easy to search for.
Feb 27 2014
prev sibling next sibling parent "Robert Clipsham" <robert octarineparrot.com> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

D doesn't need this, you can implement monadic null checking in the library: http://forum.dlang.org/post/kcrqyvddilteyhyygifc forum.dlang.org There's no need for a special operator for this. See the other posts in that thread for more information. Robert
Feb 27 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham 
wrote:
 D doesn't need this, you can implement monadic null checking in 
 the library:

By that argument, I can implement anything that D can do in assembler, hence I don't need D.
Feb 27 2014
prev sibling next sibling parent "Robert Clipsham" <robert octarineparrot.com> writes:
On Thursday, 27 February 2014 at 16:32:18 UTC, Chris Williams 
wrote:
 On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham 
 wrote:
 D doesn't need this, you can implement monadic null checking 
 in the library:

By that argument, I can implement anything that D can do in assembler, hence I don't need D.

I'm not sure I understand your point. I'm simply stating that in D, right now, without adding any complexity to the language, you can do: just(myObject).method1().method2().method3() Which would have the same effect as: myObject?.method1()?.method2()?.method3() in C#. Is a special operator really needed for this? Robert
Feb 27 2014
prev sibling next sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Thursday, 27 February 2014 at 17:02:02 UTC, Robert Clipsham 
wrote:
 On Thursday, 27 February 2014 at 16:32:18 UTC, Chris Williams 
 wrote:
 On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham 
 wrote:
 D doesn't need this, you can implement monadic null checking 
 in the library:

By that argument, I can implement anything that D can do in assembler, hence I don't need D.

I'm not sure I understand your point. I'm simply stating that in D, right now, without adding any complexity to the language, you can do: just(myObject).method1().method2().method3()

You can't do that. You're reducing your example code - which was several dozen lines and only applied to objects for which you had added the special handler code - to the end result. After you've laid the framework for doing this, yes, you can do it. But there's a bunch of work that has to go into it before you get to that point. (Also, your implementation is far less efficient than something which rewrites the code as a bunch of nested "if (not null)" checks.) If your argument was that there are more important things for the compiler team to work on, or that the syntax of the language was already large enough without adding more things for people to remember, then sure. But if we lived under the premise that there's no reason to add features to a compiler that abstract code down into a simpler syntax, then we'd have never developed variables or functions.
Feb 27 2014
prev sibling next sibling parent "Robert Clipsham" <robert octarineparrot.com> writes:
On Thursday, 27 February 2014 at 17:25:22 UTC, Chris Williams 
wrote:
 just(myObject).method1().method2().method3()

You can't do that. You're reducing your example code - which was several dozen lines and only applied to objects for which you had added the special handler code - to the end result. After you've laid the framework for doing this, yes, you can do it. But there's a bunch of work that has to go into it before you get to that point. (Also, your implementation is far less efficient than something which rewrites the code as a bunch of nested "if (not null)" checks.) If your argument was that there are more important things for the compiler team to work on, or that the syntax of the language was already large enough without adding more things for people to remember, then sure. But if we lived under the premise that there's no reason to add features to a compiler that abstract code down into a simpler syntax, then we'd have never developed variables or functions.

Most of the code I posted would be hidden away in a library, and will work with any type with methods or UDFs. I'll admit it is incomplete (no implicit casting to the original return types for example), but it is possible. End user code would be exactly as that line is. I haven't checked the assembly, but given the simplicity of the generated code I'm fairly certain it will optimise to the same as the if/else chain (feel free to prove me wrong :)). Robert
Feb 27 2014
prev sibling next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with, and having everything nullable is dubious as well. This is fixing a problem that shouldn't exists to begin with.
Feb 27 2014
parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 3/1/14, 4:10 AM, Araq wrote:

 Even if that would be true, the "refactoring über alles" OO crowd
 couldn't care less... You refactor. Problem solved. Massive code
 restructuring is embraced in the OO world because OO encourages
 bad design like no other paradigm.

Araq: could you list the problems you see in the OO world?
Mar 01 2014
parent Jacob Carlborg <doob me.com> writes:
On 2014-03-01 14:54, Araq wrote:

 I could list the problems, but that would fill books. So, I'll focus on
 a single aspect instead here: "Favour composition over inheritance".
 This is commonly regarded as the better solution (and I agree with it
 btw). Ok, fine, so we favour composition and don't use inheritance. If
 we don't use inheritance we have no subtyping either (at least in the
 "classic OO model") and without subtyping we don't need dynamic binding
 either. In other words, we model things as nested structs plus
 functions. We can attach these functions to the structs or make them
 free standing but this is only a cosmetic detail really. So what's left
 of OO? Nothing! "Favour composition over inheritance" is a single big
 confession that OO doesn't work...

You have other parts of the OO paradigm as well, which I would consider more important: 1. Combining data (instance variables) and behavior (methods) as a single entity (object) 2. Encapsulation and information hiding -- /Jacob Carlborg
Mar 01 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2014-02-27 14:27, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx


 What do you think how well would this work in D2 ?

I like it. -- /Jacob Carlborg
Feb 27 2014
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with, and having everything nullable is dubious as well. This is fixing a problem that shouldn't exists to begin with.

+1 Please no.
Feb 27 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 Feb 2014 16:20:47 -0500, Peter Alexander  
<peter.alexander.au gmail.com> wrote:

 On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with, and having everything nullable is dubious as well. This is fixing a problem that shouldn't exists to begin with.

+1 Please no.

Yes. Taken from the example: parent?.child?.child?.child Given no context, this may make sense. But with context, likely you have verified beforehand the answers to some, if not all, of these question marks. However, even with that, I can't help but expect there should be a way to do this in D without changing the language. Something like: ifnull(parent).child.child.child -Steve
Feb 27 2014
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 27 Feb 2014 16:45:11 -0500, Steven Schveighoffer  
<schveiguy yahoo.com> wrote:

 ifnull(parent).child.child.child

brain fart... ifvalid(parent).child.child.child -Steve
Feb 27 2014
prev sibling next sibling parent "Araq" <rumpf_a web.de> writes:
On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with ...

No, it's not a code smell at all and most of this religious OOP/OOD bullshit has been debunked by now.
Feb 27 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 27 February 2014 at 21:49:20 UTC, Steven 
Schveighoffer wrote:
 On Thu, 27 Feb 2014 16:45:11 -0500, Steven Schveighoffer 
 <schveiguy yahoo.com> wrote:

 ifnull(parent).child.child.child

brain fart... ifvalid(parent).child.child.child -Steve

What you want is a maybe monad, and we can do that with D metaprogramming capabilities already.
Feb 27 2014
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Thu, 2014-02-27 at 20:49 +0000, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with, and having everything nullable is dubious as well. This is fixing a problem that shouldn't exists to begin with.

From the responses, this is clearly an emotive issue, but chaining .

people who think it is a code smell. Many people think exactly the opposite and that not using chaining where is can be used is a code smell. Groovy has had safe dereferencing for a long time, as have other dynamic languages, C# is coming very late to this game. Any design decision for D needs to look wider than the C# debate, theoretical examples and philosophizing, to actual use in real situations by languages that have chosen to realize this idea. My experience from Groovy, which is relatively limited in that I am not involved in end-client applications only in maintaining and developing Groovy, GPars and Gant, indicates that it is a very helpful tool, analogous to the whole Maybe/Option stuff in pure functional languages. Groovy is now able to probe the issue of whether this operation is as useful/applicable in a statically compiled context as in a dynamic context since the TypeChecked and CompileStatic AST transforms allow Groovy to be a static language as Java, Scala, Ceylon, Kotlin are, as well as being a dynamic language as JRuby, Jython, Clojure are. No results as yet though as the experiments have not been explicitly tried. Thus there is no explicit data to reflect on. -- Russel. ============================================================================= Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.net 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Feb 27 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with

It is? Why?
Feb 28 2014
prev sibling next sibling parent "Gary Willoughby" <dev nomad.so> writes:
On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote:
 On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with

It is? Why?

I would also like to understand why this is a code smell. I'm completely on the fence but would love to hear arguments either way.
Feb 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote:
 Chaining . operation is a code smell to begin with

It is? Why?

If a system is well-designed, then "null" state either means something (and needs to be explicitly handled) or is not possible. ?. provides simple and easy way to write a sloppy code that does not tell the reader if resulting code flow for null case was intentional. Also it is very easy to get accustomed to use ?. everywhere instead of . and get broken logic instead of NullPointerException for cases when pointer is wrongly assumed to never be null.
Feb 28 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
On Friday, 28 February 2014 at 11:11:28 UTC, Dicebot wrote:
 On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote:
 Chaining . operation is a code smell to begin with

It is? Why?

If a system is well-designed, then "null" state either means something (and needs to be explicitly handled) or is not possible. ?. provides simple and easy way to write a sloppy code that does not tell the reader if resulting code flow for null case was intentional. Also it is very easy to get accustomed to use ?. everywhere instead of . and get broken logic instead of NullPointerException for cases when pointer is wrongly assumed to never be null.

I sometimes come across situations like this: writeln_or_whatever(person ? person.name : ""); (This is a case of "means something".) Using `person?.name` is a bit shorter and DRYer. But it would be more useful if I could specify the default value it returns. With an explicit `maybe` this would be possible: person.maybe("<n/a>").name;
Feb 28 2014
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 28 February 2014 at 11:11:28 UTC, Dicebot wrote:
 On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote:
 Chaining . operation is a code smell to begin with

It is? Why?

If a system is well-designed, then "null" state either means something (and needs to be explicitly handled) or is not possible. ?. provides simple and easy way to write a sloppy code that does not tell the reader if resulting code flow for null case was intentional. Also it is very easy to get accustomed to use ?. everywhere instead of . and get broken logic instead of NullPointerException for cases when pointer is wrongly assumed to never be null.

Do you mean: Chaining operations that can return null (or some other known-to-be-invalid state) is a code-smell. That's quite different to saying: Chaining operations using . is a code-smell. which is what deadalnix said. Either way, a do-this-if-you-can pattern is quite reasonable IMO. However, I do question whether it's common enough to justify syntax sugar.
Feb 28 2014
prev sibling next sibling parent "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 28 February 2014 at 11:21:47 UTC, Marc Schütz wrote:
 I sometimes come across situations like this:

 writeln_or_whatever(person ? person.name : "");

 (This is a case of "means something".)

 Using `person?.name` is a bit shorter and DRYer. But it would 
 be more useful if I could specify the default value it returns. 
 With an explicit `maybe` this would be possible:

 person.maybe("<n/a>").name;

With C#, you can't use 'person' to imply 'person !is null'. So instead you have var name = person != null ? person.name : null; Which is less nice than var name = person?.name So this feature is a bit more useful there than here. It also ties in well with the ?? operator, for something like: var name = person?.name ?? "Unknown";
Feb 28 2014
prev sibling next sibling parent "Dicebot" <public dicebot.lv> writes:
On Friday, 28 February 2014 at 12:28:22 UTC, John Colvin wrote:
 Do you mean:

 Chaining operations that can return null (or some other 
 known-to-be-invalid state) is a code-smell.

 That's quite different to saying:

 Chaining operations using . is a code-smell.

 which is what deadalnix said.

Chaining . for non-nullables should be OK, I don't know what issue deadlnix sees here (or it is just a typo?)
Feb 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote:
 On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:
 On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

Chaining . operation is a code smell to begin with

It is? Why?

Long story : http://c2.com/cgi/wiki?LawOfDemeter Short story : It tends to make a lot of code dependent of the structure of your project, which affect evolution and maintenance negatively.
Feb 28 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 28 February 2014 at 12:28:22 UTC, John Colvin wrote:
 Do you mean:

 Chaining operations that can return null (or some other 
 known-to-be-invalid state) is a code-smell.

That is the worse.
 That's quite different to saying:

 Chaining operations using . is a code-smell.

 which is what deadalnix said.

Yes. That must not be understood as a hard rule, but something that is true most of the time. You want to look up "Law of Demeter". The problem when you chain is that you make a lot of code dependent on the structure of the project, which makes it hard to evolve or maintain the project, as any change in the structure will impact more code than it should. Obviously, this idea may be in tension with other principle, and good judgement is always welcome. As a general rule, unless you have some really good reason to, avoid chaining.
 Either way, a do-this-if-you-can pattern is quite reasonable 
 IMO. However, I do question whether it's common enough to 
 justify syntax sugar.

This pattern exist. That is called the maybe monad. To take previous example: writeln(person ? person.name : ""); Can become Maybe!Person person; writeln(person.name.get("")); If person is a Maybe!Person, the person.name is a Maybe!string (assuming name is a string) and the get method will provide a default value if nothing is present in the Maybe monad. That ensure that null is checked consistently and provide what you want, a do-this-if-you-can pattern.
Feb 28 2014
prev sibling next sibling parent "SomeDude" <lolilol mytrashmail.com> writes:
On Friday, 28 February 2014 at 11:21:47 UTC, Marc Schütz wrote:
 On Friday, 28 February 2014 at 11:11:28 UTC, Dicebot wrote:
 On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote:
 Chaining . operation is a code smell to begin with

It is? Why?

If a system is well-designed, then "null" state either means something (and needs to be explicitly handled) or is not possible. ?. provides simple and easy way to write a sloppy code that does not tell the reader if resulting code flow for null case was intentional. Also it is very easy to get accustomed to use ?. everywhere instead of . and get broken logic instead of NullPointerException for cases when pointer is wrongly assumed to never be null.

I sometimes come across situations like this: writeln_or_whatever(person ? person.name : ""); (This is a case of "means something".) Using `person?.name` is a bit shorter and DRYer. But it would be more useful if I could specify the default value it returns. With an explicit `maybe` this would be possible: person.maybe("<n/a>").name;

I am also on the opinion that chaining on nullable objects encourages sloppy code and should therefore be avoided. Because the null case should often be handled. Chaining skips handling the null case. Thus this syntaxic sugar is a bad idea. The chaining pattern is okay to make code more expressive, but it is always assumed that the objects on which it's applied are non-nullable.
Feb 28 2014
prev sibling next sibling parent "Araq" <rumpf_a web.de> writes:
 Yes. That must not be understood as a hard rule, but something 
 that is true most of the time. You want to look up "Law of 
 Demeter".

No, it's not true "most of the time". It's just another piece of arbitrary crap from the object oriented cargo cult that has no scientific basis.
 The problem when you chain is that you make a lot of code 
 dependent on the structure of the project, which makes it hard 
 to evolve or maintain the project, as any change in the 
 structure will impact more code than it should.

Even if that would be true, the "refactoring über alles" OO crowd couldn't care less... You refactor. Problem solved. Massive code restructuring is embraced in the OO world because OO encourages bad design like no other paradigm.
Feb 28 2014
prev sibling next sibling parent "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> writes:
 I sometimes come across situations like this:

 writeln_or_whatever(person ? person.name : "");

 (This is a case of "means something".)

 Using `person?.name` is a bit shorter and DRYer. But it would 
 be more useful if I could specify the default value it 
 returns. With an explicit `maybe` this would be possible:

 person.maybe("<n/a>").name;

I am also on the opinion that chaining on nullable objects encourages sloppy code and should therefore be avoided. Because the null case should often be handled. Chaining skips handling the null case. Thus this syntaxic sugar is a bad idea.

The null case _is_ handled, because you're explicitly specifying "maybe()". I can agree that it might lead to problems if it happens automatically and you don't see what's going on, but that isn't the case here.
Mar 01 2014
prev sibling next sibling parent "Araq" <rumpf_a web.de> writes:
 Even if that would be true, the "refactoring über alles" OO 
 crowd
 couldn't care less... You refactor. Problem solved. Massive 
 code
 restructuring is embraced in the OO world because OO encourages
 bad design like no other paradigm.

Araq: could you list the problems you see in the OO world?

I could list the problems, but that would fill books. So, I'll focus on a single aspect instead here: "Favour composition over inheritance". This is commonly regarded as the better solution (and I agree with it btw). Ok, fine, so we favour composition and don't use inheritance. If we don't use inheritance we have no subtyping either (at least in the "classic OO model") and without subtyping we don't need dynamic binding either. In other words, we model things as nested structs plus functions. We can attach these functions to the structs or make them free standing but this is only a cosmetic detail really. So what's left of OO? Nothing! "Favour composition over inheritance" is a single big confession that OO doesn't work...
Mar 01 2014
prev sibling next sibling parent "Araq" <rumpf_a web.de> writes:
 You have other parts of the OO paradigm as well, which I would 
 consider more important:

 1. Combining data (instance variables) and behavior (methods) 
 as a single entity (object)

That's an ADT then, not OOP. (I follow Cook's definition of OO here.)
 2. Encapsulation and information hiding

That's a module system, not OOP.
Mar 01 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 1 March 2014 at 07:10:56 UTC, Araq wrote:
 The problem when you chain is that you make a lot of code 
 dependent on the structure of the project, which makes it hard 
 to evolve or maintain the project, as any change in the 
 structure will impact more code than it should.

Even if that would be true,

It is.
 the "refactoring über alles" OO crowd
 couldn't care less...

Could you teach me some of you mind reading capabilities ?
 You refactor. Problem solved.

So, to make refactoring easier, you refactor. I knew the functional crowd liked recursence, but I just learnt that tail recusrion can also be used to crate circular logic.
 Massive code
 restructuring is embraced in the OO world because OO encourages
 bad design like no other paradigm.

The anti OO world don't need that, as they know all future evolution at day one. Probably because they do not have users.
Mar 01 2014
prev sibling next sibling parent "Araq" <rumpf_a web.de> writes:
 The anti OO world don't need that, as they know all future 
 evolution at day one. Probably because they do not have users.

The idea that *more* code makes your code "easier to evolve" only comes from OO people, makes no sense and has largely been proven not to work. Even the OO people realized that and came up with YAGNI. The law of dementer contradicts YAGNI and DRY...
Mar 02 2014
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Sunday, 2 March 2014 at 08:16:43 UTC, Araq wrote:
 The anti OO world don't need that, as they know all future 
 evolution at day one. Probably because they do not have users.

The idea that *more* code makes your code "easier to evolve" only comes from OO people, makes no sense and has largely been proven not to work. Even the OO people realized that and came up with YAGNI. The law of dementer contradicts YAGNI and DRY...

No.
Mar 02 2014
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/27/2014 02:27 PM, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx


 What do you think how well would this work in D2 ?

auto foo = bar?.baz?.fun:hun;
Mar 02 2014
prev sibling next sibling parent "Boyd" <gaboonviper gmx.net> writes:
While at the moment it may seem like a must have feature. If D is 
going to get better nullability handling, like the proposed 
 nullable or Nullable!X, then the safe navigation operator is not 
really needed. The explicit nullability would provide the needed 
safety.

auto x = parent.child.child.child; // error, result may be null
 nullable auto x = parent.child.child.child; // no error

I'd definitely prefer that to a weird operator that may also 
conflict with the inline if statement.
Mar 02 2014
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:
 Apparently C# will get it in the next version.
 http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx

 What do you think how well would this work in D2 ?

AFAIKS nullability in Kotlin has already been mentioned, but not how you have to declare some value to be nullable: var value : String = "" value = "hello" // fine value = null // compiler error: must not assign null var valueOrNull : String? valueOrNull = null // line 5 Assigning null to valueOrNull in line 5 is fine as valueOrNull is declared to be String or null (denoted by the ? in String?). However, also Kotlin does not get around the Scala/Rust-style Otpion class this way, see http://kenbarclay.blogspot.de/2014/02/kotlin-option-type-1.html and http://kenbarclay.blogspot.de/2014/02/kotlin-option-type-2.html. Let's say you retrieve the value associated with some key from some map and the key does not exist in the map. Then you would get null from the retrieval and the compiler can't tell at compile time. So you need return an Option object to force the user to check for the value returned being null. My preliminary conclusion to this is that in the end you have to introduce an Option type as in other languages. I would say this pretty much makes a need for a language extension obsolete. To be consistent you would have to add new methods to Phobos and other libraries to return Option (e.g., for the map class and others). If you want to you can still add your ?. method to subclasses of Option (aka None and Some). -- Bienlein
Mar 03 2014
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Sunday, 2 March 2014 at 09:12:08 UTC, deadalnix wrote:
 No.

Gotta love the well thought out responses...
Mar 03 2014
prev sibling next sibling parent "Bienlein" <jeti789 web.de> writes:
On Saturday, 1 March 2014 at 13:54:49 UTC, Araq wrote:
 Araq: could you list the problems you see in the OO world?

I could list the problems, but that would fill books. So, I'll focus on a single aspect instead here: "Favour composition over inheritance". This is commonly regarded as the better solution (and I agree with it btw). Ok, fine, so we favour composition and don't use inheritance. If we don't use inheritance we have no subtyping either

Favouring composition over inheritance means not to create too deep class hierarchies. It doesn't mean not to make use of inheritance anymore at all. The deeper a class hierarchy the more inflexible: if you change the parent class of a class in a big hierarchy tree you break a lot of things (all subclass of the classs with the changed parent class are affected). So create light hierarchies and then go with composition. Overriding inherited methods is still a great way to achieve flexibility without breaking encapsulation.
Mar 03 2014
prev sibling next sibling parent "Jesse Phillips" <Jesse.K.Phillips+D gmail.com> writes:
On Sunday, 2 March 2014 at 01:28:32 UTC, deadalnix wrote:
 So, to make refactoring easier, you refactor. I knew the 
 functional crowd liked recursence, but I just learnt that tail 
 recusrion can also be used to crate circular logic.

I can't find what I'm thinking of, but Conditional Proof seems to be close: http://en.wikipedia.org/wiki/Conditional_proof This was used in my philosophy class. You start with an assertion, then list off things which are true because of it until you come back and the only logic conclusion is that the assertion was true.
Mar 03 2014
prev sibling parent "Bienlein" <jeti789 web.de> writes:
On Saturday, 1 March 2014 at 16:27:45 UTC, Araq wrote:

 That's an ADT then, not OOP. (I follow Cook's definition of OO 
 here.)

 2. Encapsulation and information hiding

That's a module system, not OOP.

Can you create an instance of a module? Then it's not an object in the sense of OOP.
Mar 03 2014