www.digitalmars.com         C & C++   DMDScript  

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

reply "Remo" <remo4d gmail.com> writes:

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:


 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:


 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:


 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 reply "Robert Clipsham" <robert octarineparrot.com> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:


 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
parent reply "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
parent reply "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()



Robert
Feb 27 2014
parent reply "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
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:


 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
next sibling parent reply "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:


 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
parent reply "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:


 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
parent reply "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
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 "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:


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


 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 .


operations and using fluent interfaces is only a code smell to those
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


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 parent reply "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:


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


 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 reply "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
next sibling parent reply "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
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;




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 parent reply "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
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 parent reply "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
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 parent reply "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
parent reply "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
next sibling 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 reply "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
next sibling parent reply 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
parent reply "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
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
prev 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 parent reply "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
next sibling parent reply "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
parent reply "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
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 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 "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:


 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 Jacob Carlborg <doob me.com> writes:
On 2014-02-27 14:27, Remo wrote:


 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 Timon Gehr <timon.gehr gmx.ch> writes:
On 02/27/2014 02:27 PM, Remo wrote:


 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 parent "Bienlein" <jeti789 web.de> writes:
On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:


 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