Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 21:28:22 UTC, Stanislav Blinov wrote: The only difference is that `func` became a member function. And now what? You can just as easily "forget" what's in your struct/class as in your whole module. ok. Now, what are your options then (assuming you want an independent type)? (option 1) define one encapsulated type, per module. (option 2) have a means for type independence within a module - i.e. selective hiding. D only gives you one choice here, not two. I would say, that your response backs up my argument, that is, a second option might actually be worthwhile. perhaps, something like: __private (now __private is everything private already is, but additionally, its private outside the scope of the type declaring it, and now, you'd get a compile time guarantee of correctness - e.g. if you accidently tried to ignore that types independence. It's call 'type encapsulation' ;-)
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote: On 11/2/2018 5:44 PM, Laeeth Isharc wrote: When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake. It might be better to suspend judgement for a while and keep an open mind. So true. My ideas on how to write code have changed dramatically over the years, and continue to change. what are your thoughts on implicit conversions, given your obvious experience? To me, implicit conversion are code smells, as they undermine the independence of types (and as you've probably gathered, I very much like type independence..a lot). Did you do it this way for C like compatability? Would you do it differently, if you could? uint x = -10; // what! int x; bool y = true; x = y; // what! etc..
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Mon, 05 Nov 2018 01:23:44 +, nobodycares wrote: > I think there are more than enough real-world examples, of where issues > around 'type safety', or lack of, have caused a sufficient number of > bugs, to warrant a discussion about ways to further improve type safety. You do realize we can all see that you're posting from the same IP address with three different usernames, don't you? How's the dual boot working out? Firefox 52 is kind of old; are you holding off on updating for addon compatibility? If you want to make a good sockpuppet, you'll need to invest some effort. Different browsers for each. Different IP addresses. Usernames that look like reasonable human names or forum handles. Posting about topics other than your personal cause. And if you had actual examples, you'd have shown them already.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 21:35:04 UTC, Walter Bright wrote: On 11/2/2018 5:44 PM, Laeeth Isharc wrote: When one encounters a new idea that's unfamiliar sometimes it's easy to think that because it's unfamiliar it must be unsound. That can be a mistake. It might be better to suspend judgement for a while and keep an open mind. So true. My ideas on how to write code have changed dramatically over the years, and continue to change. I hear the advantages of the way D does it. But nobody wants to hear about the disadvantages. Am I the only one who needs to keep an 'open mind'? What harm can come, from an optional tool, that enables enforceable encapsulation of a type, within a module (from code also in the module, but outside that type)? Can someone please answer that? And yet again, I remind people that this is not a request for change. This is a discussion about what benefit such a tool can bring.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Monday, 5 November 2018 at 01:23:44 UTC, nobodycares wrote: I assume the moderator(s) doesn't like me anymore, as my posts are no longer being published. Great way to run a discussion forum by the way. It not just you, my post had disappear only to reappear on later dates. I can vouch for them by saying that this is a bug that you and I are experiencing. -Alex
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote: There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things. The justification for this feature rests on real-world examples of bugs that have been caused by its lack. I think there are more than enough real-world examples, of where issues around 'type safety', or lack of, have caused a sufficient number of bugs, to warrant a discussion about ways to further improve type safety. D module's are not type safe, at least as far as the code within that module is concerned. To have to go to silly lengths just to get type safety in D. D is language the favors convenience 1st. type safety 2nd... or is it 3rd.. This lack of enforcable type safety *within* a module, leads to undisciplned code. Phobos is a 'real-world' example of it. D needs an 'Industrial Strength D' book, as well as an 'Effective D'. I assume the moderator(s) doesn't like me anymore, as my posts are no longer being published. Great way to run a discussion forum by the way.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote: There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things. The justification for this feature rests on real-world examples of bugs that have been caused by its lack. You keep turning this argument around, as though it is a request to change D. We should be able to have a discussion, about ways to further improve type safety inside a module, without being constantly taunted by your hyperbole. The discussion might even lead to ways to help programmers address the issues being raised, that don't require a change to D (and I don't mean 'just put your class/struct in it's own module'). Now, the fact is, that the D module is a conglomeration of different types. None of the types declared within a module has any independence from any other type, within the module. Fact. Some clearly think this is a good thing. Fine, you have it that way already. That will never change. But some think this requires an undue burden on the part of the programmer to be extra vigiliant around how they compose their types. Sure a few lines in module, you can easily do that. But as the number of line increase, so would the chances of you doing something you never intended to do. There is no way the programmer to provide a guarantee around the use of a type, from other code in the module, since the data and methods in any type are mutable from outside that type. Some think this shared mutability between types within a module, can lead to bugs and unsafe behaviour. Some think it might be nice, if the programmer had a means to provide better guarantees for the their declared types. Type safety is an important and critical component in software architecture. It's not something you should 'agressively filter out' from discussion. Whether the language could handle a change to address this, would be a further stage of the discussion. From what I hear, it may not be able to handle such a change, and the D module is doomed to be what it is, and programmers will bear the responsibilty for type safety within a module.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sunday, 4 November 2018 at 15:40:03 UTC, Neia Neutuladh wrote: On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote: Can we argue about the problems arising from the potential introduction of this feature? There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. No one should/need learn the entire tool itself in order to get thing done. If you found yourself in such a situation, then you seriously need to rethink on what you should be doing. -Alex
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 03:58:16 UTC, Ali Çehreli wrote: On 11/02/2018 03:18 AM, ShadoLight wrote: > Maybe you are thinking of the "Prefer non-member non-friend functions to > member functions" rule from Herb Sutter's "Effective C++" books? Scott Meyers. Ali Thanks for the correction.
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Sun, 04 Nov 2018 11:36:39 +, FooledDonor wrote: > Can we argue about the problems arising from the potential introduction > of this feature? There are many potential features that wouldn't cause problems in isolation. Should we add all of them? Obviously not; the result would be a horribly complex language that takes too much time to learn and is impossible to maintain. So instead, we need to aggressively filter out potential added features to ensure that what they add is sufficiently important to justify later maintenance costs and the effort of learning things. The justification for this feature rests on real-world examples of bugs that have been caused by its lack.
Re: LDC 1.13.0-beta1
On Friday, 2 November 2018 at 21:04:13 UTC, kinke wrote: Glad to announce the first beta for LDC 1.13: * Based on D 2.083.0. * The Windows packages are now fully self-sufficient, i.e., a Visual Studio/C++ Build Tools installation isn't required anymore. * Substantial debug info improvements for GDB. Full release log and downloads: https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1 Thanks to all contributors! I've added native Termux builds for Android, including x86 for the first time. Cross-compiling to Android/x64 mostly works, but LDC itself segfaults when cross-compiled and run on Android/x64, likely because it uses a 128-bit real just like AArch64. I'll see if I can get that fixed before the final 1.13 release.
Re: LDC 1.13.0-beta1
On Fri, Nov 02, 2018 at 09:04:13PM +, kinke via Digitalmars-d-announce wrote: > Glad to announce the first beta for LDC 1.13: > > * Based on D 2.083.0. > * The Windows packages are now fully self-sufficient, i.e., a Visual > Studio/C++ Build Tools installation isn't required anymore. > * Substantial debug info improvements for GDB. > > Full release log and downloads: > https://github.com/ldc-developers/ldc/releases/tag/v1.13.0-beta1 > > Thanks to all contributors! Just wanted to say thanks to the LDC team and everyone else who was involved in making it possible for LDC releases to track DMD releases so closely. I'm quite tempted to switch to LDC as my main compiler instead of DMD git master, because of the better codegen and wider range of arch targets. Thanks, guys! T -- Leather is waterproof. Ever see a cow with an umbrella?
Re: Wed Oct 17 - Avoiding Code Smells by Walter Bright
On Saturday, 3 November 2018 at 16:21:36 UTC, Neia Neutuladh wrote: On Sat, 03 Nov 2018 11:24:06 +, FooledDonor wrote: And if the validity of a person's reasoning is a function of his way of expressing them, well ... do not pose to software engineers at least If you want other people to do work for you, you need to convince them to do it. This is an open source project, so the appropriate way of doing this is with good reasoning and examples, not by insulting people. The answer to your "if" is: NO, this is not the topic. The argument is: does the induction of a true "private" attribute add value to the language or not? It is possible to discuss, in these forums, or everything must be truncated with "if you want to do it, and best wishes to convince then W & A" This is true even if the feature seems obviously good and necessary to one or two people, if those people don't have abnormally large influence over the project. Nothing is "necessary" to a language outside "turing completeness". Can we argue about the problems arising from the potential introduction of this feature?
