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

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

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

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.

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

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.

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;

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.

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

On Sunday, 2 March 2014 at 09:12:08 UTC, deadalnix wrote:
> No.

Gotta love the well thought out responses...