|
My system shuts down and restarts without me needing to say anything.
cheers
Chris Maunder
|
|
|
|
|
The company wants to offer cell plans for sale through the Windows Store, but that might not fly I'm sure they'd love to sell data plans for those
|
|
|
|
|
This time around, the plan is for ARM to be just another PC platform. RT: Really Terminated
|
|
|
|
|
MIT researchers have developed a new approach to training speech-recognition systems that doesn’t depend on transcription. It sounds like you said, "Kill all the humans". Is that correct?
|
|
|
|
|
Microsoft is combining some of its previously separate large-format conferences for 2017, and is pushing back its Build developers confab to May next year. Seattle is lovely that time of the year
I'll go out on a limb and suggest that maybe Visual Studio 2017?
|
|
|
|
|
Launched before mobile and cloud computing, the Microsoft .NET framework has gone open source, added tools for cross-platform development, and adopted a common library model. "More, more, more! How do you like it? How do you like it?"
Again, not much new if you've been paying attention, but handy all in one spot
|
|
|
|
|
Kurzweil hasn’t always been right, including on the future of clothing, but he has proved surprisingly adept at foreseeing innovations. "People ask me to predict the future, when all I want to do is prevent it."
|
|
|
|
|
In the old days of OOP, inheritance was the way to go to extend your objects' functionality. Now, it's almost shunned. See why and learn a better way to handle it. I hope not - I have a rich uncle
|
|
|
|
|
Article implies inheritance should die; proceeds to use inheritance in one of the solutions. Seems legit Mostly joking. He does raise a good point about class hierarchy but implying decorator can replace inheritance is foolish at best. He even seems to realize this fault later in the article.
|
|
|
|
|
Decorator pattern seems like a poor mans multiple inheritance.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
It can be but can also be more flexible - depends on what you need. I think of it like a builder pattern for behavior. Instead of just smashing classes together (inheritance) it routes classes through each other. It also avoids the Deadly Diamond[^].
|
|
|
|
|
Forsooth.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
The "Deadly Diamond" problem was solved in Eiffel in the 1990's. Unfortunately, every looked C++, got scared, and adopted single inheritance.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Personally I prefer the approach Perl takes. Not only does it have well-defined behavior without adding verbosity to the language but it's also customizable by the developer. After using C# for years though I realize multiple inheritance isn't all that useful outside of specific circumstances like mixins. Very easy to abuse as well though one could argue that's the fault of the developer.
|
|
|
|
|
I had to look up what Perl does with MI, but it was an approach I've seen elsewhere.
The issue with schemes like that is that you have to look at the implementation of a class, in particular its inheritance structure, to be able to be sure of the effect of a method call. That, to my mind, breaks encapsulation and the principle of least surprise.
What Eiffel does is effectively to disallow conflicts. If a conflict is detected, compilation fails (it is a statically-typed language). However, the renaming and remapping concepts provide the mechanisms required to resolve the conflict. In Eiffel, it is possible to generate a "flat" view of a class, that lists all available methods, without needing to refer to its hierarchy at all.
I also appreciate the mixin approach, but multiple inheritance does not prevent this - it is simple to define a mixin with MI, but the converse is not true. Similar to how prototype-based languages (notably Self - which, in its standard distribution, includes a complete Smalltalk-80 subsystem) can easily model classes, simply by having the class object be a prototype, while the converse is not true.
I'm a great fan of using the simplest model that allows full expressiveness, it is simple then to program in various idiomatic styles. Unnecessarily limiting expressiveness makes you jump through hoops, or become a language lawyer, to solve problems. The worst offenders I know of are C++ (where overload resolution mechanisms in the presence of templates are a dark art) and JavaScript, where some early mistakes in the language definition (understandable, given the time Douglas Crockford was given to create a language) still haunt us today.
Funny that the two could be regarded as being at different extremes of the various ways you can categorise languages (static-typing vs. dynamic typing, prototype-based vs. class-based, forgiving vs. strict with respect to syntax).
(I am a bit of a language nerd though, so maybe that colours my perspective too much).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger wrote: I also appreciate the mixin approach, but multiple inheritance does not prevent this - it is simple to define a mixin with MI, but the converse is not true.
That's what I meant - MI is useful for mixins I'd never heard of Eiffel before. That's an interesting approach to inheritance. Not really sure what you mean about encapsulation in Perl. If you want enforced encapsulation for Perl classes you can use the lexical closure technique. For inheritance you only need to know the class hierarchy if you're changing the method resolution order at run-time. I'm at best intermediate with Perl though - I just dabble in it from time to time for fun. So if I missed something let me know
|
|
|
|
|
Someone wrote: inheritance was the way to go
It still is, but OOP isn't required for every task you may have.
Use the right tool...
I still prefer plain-old C with C++ and OOP only as required. I do not like that C# requires that everything be in OOP -- that's just silly.
|
|
|
|
|
PIEBALDconsult wrote: Use the right tool... ... and you will already have 50% of the job done.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
PIEBALDconsult wrote: I do not like that C# requires that everything be in OOP It doesn't. I have seen plenty of C# projects that are written as a collection of static classes. In this case, the class name just serves as a namespace. And with C# 6 you can do using Namespace.ClassName; to pull that static members of static 'ClassName' into the current translation unit.
So, yes, you can do 'C' style structured programming in C# and use OOP only as required. Not that it's necessarily recommended. But, hey, whatever.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
TheGreatAndPowerfulOzyes, you can do 'C' style structured programming in C#
No, you can't -- everything has to be in a class (or struct maybe). Beginners should be freed of that.
|
|
|
|
|
Uh, yes you can. And I already mentioned that -- like I said, the static class can be treated as a namespace. It's not that much of a mental leap for a beginner.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
A class is a class. Having to needlessly embed code in any kind of wrapper for no good reason hinders understanding.
|
|
|
|
|
I disagree. Why wrap any code in function names at all? Why not put all code in one function then? Or no function at all. That's what BASIC started out as. And we know that spaghetti ensued.
Code segregation, i.e. "cohesion", enhances understanding. Namespaces and static classes and non-static classes enhance understanding.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|
|
But a developer should need to do that only as needed.
|
|
|
|
|
Sure, just put all the code in Program.cs and Program.Main() then.
#SupportHeForShe
Government can give you nothing but what it takes from somebody else. A government big enough to give you everything you want is big enough to take everything you've got, including your freedom.-Ezra Taft Benson
You must accept 1 of 2 basic premises: Either we are alone in the universe or we are not alone. Either way, the implications are staggering!-Wernher von Braun
|
|
|
|