digitalmars.D - Safe Navigation Operator =?UTF-8?B?4oCcPy7igJ0=?= for D2 ?
- Remo (3/3) Feb 27 2014 Apparently C# will get it in the next version.
- Asman01 (3/6) Feb 27 2014 I was just thinking to create this topic but you did first, haha.
- Chris Williams (8/11) Feb 27 2014 I like it. At my previous job, I extended std.json with an array
- Jesse Phillips (3/6) Feb 27 2014 Wish I could locate bearophile's post on the topic, sadly ?.
- Robert Clipsham (7/10) Feb 27 2014 D doesn't need this, you can implement monadic null checking in
- Chris Williams (4/6) Feb 27 2014 By that argument, I can implement anything that D can do in
- Robert Clipsham (10/16) Feb 27 2014 I'm not sure I understand your point. I'm simply stating that in
- Chris Williams (17/30) Feb 27 2014 You can't do that. You're reducing your example code - which was
- Robert Clipsham (11/27) Feb 27 2014 Most of the code I posted would be hidden away in a library, and
- deadalnix (4/7) Feb 27 2014 Chaining . operation is a code smell to begin with, and having
- Peter Alexander (3/12) Feb 27 2014 +1
- Steven Schveighoffer (12/25) Feb 27 2014 Yes. Taken from the example:
- Steven Schveighoffer (5/6) Feb 27 2014 brain fart...
- deadalnix (4/10) Feb 27 2014 What you want is a maybe monad, and we can do that with D
- Araq (3/10) Feb 27 2014 No, it's not a code smell at all and most of this religious
- Russel Winder (27/38) Feb 27 2014 operations and using fluent interfaces is only a code smell to those
- John Colvin (2/9) Feb 28 2014 It is? Why?
- Gary Willoughby (4/14) Feb 28 2014 I would also like to understand why this is a code smell. I'm
- Dicebot (9/11) Feb 28 2014 If a system is well-designed, then "null" state either means
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (8/21) Feb 28 2014 I sometimes come across situations like this:
- Kapps (9/16) Feb 28 2014 With C#, you can't use 'person' to imply 'person !is null'.
- SomeDude (8/31) Feb 28 2014 I am also on the opinion that chaining on nullable objects
- "Marc =?UTF-8?B?U2Now7x0eiI=?= <schuetzm gmx.net> (4/19) Mar 01 2014 The null case _is_ handled, because you're explicitly specifying
- John Colvin (10/23) Feb 28 2014 Do you mean:
- Dicebot (3/9) Feb 28 2014 Chaining . for non-nullables should be OK, I don't know what
- deadalnix (22/31) Feb 28 2014 Yes. That must not be understood as a hard rule, but something
- Araq (7/14) Feb 28 2014 No, it's not true "most of the time". It's just another piece of
- Ary Borenszweig (2/6) Mar 01 2014 Araq: could you list the problems you see in the OO world?
- Araq (12/19) Mar 01 2014 I could list the problems, but that would fill books. So, I'll
- Jacob Carlborg (8/19) Mar 01 2014 You have other parts of the OO paradigm as well, which I would consider
- Araq (3/8) Mar 01 2014 That's a module system, not OOP.
- Bienlein (3/7) Mar 03 2014 Can you create an instance of a module? Then it's not an object
- Bienlein (10/17) Mar 03 2014 Favouring composition over inheritance means not to create too
- deadalnix (8/20) Mar 01 2014 Could you teach me some of you mind reading capabilities ?
- Araq (4/6) Mar 02 2014 The idea that *more* code makes your code "easier to evolve" only
- deadalnix (2/8) Mar 02 2014 No.
- Tofu Ninja (2/3) Mar 03 2014 Gotta love the well thought out responses...
- Jesse Phillips (8/11) Mar 03 2014 I can't find what I'm thinking of, but Conditional Proof seems to
- deadalnix (5/15) Feb 28 2014 Long story : http://c2.com/cgi/wiki?LawOfDemeter
- Jacob Carlborg (4/7) Feb 27 2014 I like it.
- Timon Gehr (2/5) Mar 02 2014 auto foo = bar?.baz?.fun:hun;
- Boyd (9/9) Mar 02 2014 While at the moment it may seem like a must have feature. If D is
- Bienlein (28/31) Mar 03 2014 AFAIKS nullability in Kotlin has already been mentioned, but not
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
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
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
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
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
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
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: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() RobertD 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
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: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.On Thursday, 27 February 2014 at 16:08:26 UTC, Robert Clipsham wrote: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()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
On Thursday, 27 February 2014 at 17:25:22 UTC, Chris Williams wrote: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 :)). Robertjust(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
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
On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:+1 Please no.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
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: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 -SteveOn Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:+1 Please no.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
On Thu, 27 Feb 2014 16:45:11 -0500, Steven Schveighoffer <schveiguy yahoo.com> wrote:ifnull(parent).child.child.childbrain fart... ifvalid(parent).child.child.child -Steve
Feb 27 2014
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:What you want is a maybe monad, and we can do that with D metaprogramming capabilities already.ifnull(parent).child.child.childbrain fart... ifvalid(parent).child.child.child -Steve
Feb 27 2014
On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:No, it's not a code smell at all and most of this religious OOP/OOD bullshit has been debunked by now.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 ...
Feb 27 2014
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
On Thursday, 27 February 2014 at 20:49:59 UTC, deadalnix wrote:On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:It is? Why?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
Feb 28 2014
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: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.On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:It is? Why?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
Feb 28 2014
On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin wrote: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.Chaining . operation is a code smell to begin withIt is? Why?
Feb 28 2014
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: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;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.Chaining . operation is a code smell to begin withIt is? Why?
Feb 28 2014
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
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: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.On Friday, 28 February 2014 at 09:24:23 UTC, John Colvin 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;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.Chaining . operation is a code smell to begin withIt is? Why?
Feb 28 2014
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.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.
Mar 01 2014
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: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.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.Chaining . operation is a code smell to begin withIt is? Why?
Feb 28 2014
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
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
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
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
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...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
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
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 hidingThat's a module system, not OOP.
Mar 01 2014
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.)Can you create an instance of a module? Then it's not an object in the sense of OOP.2. Encapsulation and information hidingThat's a module system, not OOP.
Mar 03 2014
On Saturday, 1 March 2014 at 13:54:49 UTC, Araq wrote: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.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
Mar 03 2014
On Saturday, 1 March 2014 at 07:10:56 UTC, Araq wrote:It is.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...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
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
On Sunday, 2 March 2014 at 08:16:43 UTC, Araq wrote:No.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
On Sunday, 2 March 2014 at 09:12:08 UTC, deadalnix wrote:No.Gotta love the well thought out responses...
Mar 03 2014
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
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: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.On Thursday, 27 February 2014 at 13:27:14 UTC, Remo wrote:It is? Why?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
Feb 28 2014
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
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
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
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