Re: how to make private class member private
On Sunday, 18 March 2018 at 18:45:23 UTC, Steven Schveighoffer wrote: If we could go back in time and talk with a young Walter about the consequences of choosing the scheme the way it is, maybe he might have made different choices, but at this point, it's hard to change it. I think this highlights the real problem with D. Power is too centralised, and kinda arbitrary. I'm going back to Java ;-)
Re: how to make private class member private
On Sunday, 18 March 2018 at 11:12:46 UTC, Alex wrote: ´´´ Are there any scenarios in which the person writing the class, would want to encapsulate their class, or some parts of it, from the rest of a module (while being forced to put the class in this module)? ´´´ The answer is no. As the person which is writing the class has always the power to decide which module to edit to put the class in. And due this fact, the statement The fact is, the creator of the class is also the creator of the module.. is the coolest semantic statement of the whole thread so far, I think :) Well, it seems to me, that the only real objection one can have to improving encapsulation within a module, is objecting to improving encapsulation within a module. The fact that the creator of a class, is also the creator of the module that contains that class, is not a valid reason for not seeking to improve encapsulation of that class.
Re: how to make private class member private
On Sunday, 18 March 2018 at 10:14:30 UTC, Alain Soap wrote: BTW i think adding this can be useful. The FreePascal language has `strict private` for example. " Private - All fields and methods that are in a private block, can only be accessed in the module (i.e. unit) that contains the class definition. They can be accessed from inside the classes’ methods or from outside them (e.g. from other classes’ methods)" " Strict Private - All fields and methods that are in a strict private block, can only be accessed from methods of the class itself. Other classes or descendent classes (even in the same unit) cannot access strict private members. " https://www.freepascal.org/docs-html/ref/refse34.html interesting...someone else clearly had the idea. hey..perhaps I'm not a moron after all.
Re: OT: Behaviour of Experienced Programmers Towards Newcomers
On Sunday, 18 March 2018 at 06:28:11 UTC, Amorphorious wrote: And who the fuck are you? See, it's funny how you say I'm a noob with mental problems that says shit about people yet you are doing THE EXACT SAME THING! At the very least, you are no better than me, in fact worse, because you pretend you are all high and mighty and then throw your underhanded attacks in. hey. I understand that someone saying you have mental problems can be taken as an attack. I think the person that made the comment, should not have said it. I think we all have mental problems... it's comes from being human ;-) I volunteer in the mental health sector, so I know the mental health issues and being human seem highly correlated ;-) In any case, you are clearly a very intelligent person (based on my analysis of your previous discussions over a long... period of time), so why not use your brain to benefit people instead of attacking them? Try to explain how people are wrong, so they can learn. Don't call people morons. It's pointless, and just reflects badly on you.
Re: how to make private class member private
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote: The fact is, the creator of the class is also the creator of the module.. and preventing him from having full access to the class is ignorant. He doesn't need to encapsulate himself. Encapsulation is ONLY meant to reduce dependencies. If the programmer, probably someone like you, can't trust himself to understand his own code then he shouldn't be coding. btw. I am talking here about 'encapsulation' not 'information hiding' (although the two terms are often considered related). Clearly, there is no point in hiding information contained within the module, from the implementer of the module. That's just silly. However, are there no scenarios in which the person writing that module, would not want to encapsulate their class, or some parts of it, from the rest of the module (while not being forced to put the class in it's own file)? If the answer is certainly no, not under any circumstances, then fine, my idea is not worth any further consideration. And by no, I mean no for all, not just you.
Re: how to make private class member private
On Sunday, 18 March 2018 at 05:01:39 UTC, Amorphorious wrote: Why do you insist that you know how everything works and you are the harbinger of truth. The fact is, you don't know squat about what you are talking about and you just want to conform D to your naive ignorant ...etc...etc..etc..etc..etc you're funny. and btw. My suggestion would not stop anyone from doing what they're currently doing within modules. It would just return class encapsulation, within a module, for when it was deemed worthwhile (as opposed to being forced to move the class out of the module). It's just an idea, not a request. One day I might do a data matching analysis of the dmail-archive, to find out who you really are.
Re: how to make private class member private
On Saturday, 17 March 2018 at 21:33:01 UTC, Adam D. Ruppe wrote: On Saturday, 17 March 2018 at 21:22:44 UTC, arturg wrote: maybe extend that to a list of types? this is basically what C++ friend does and D was trying to avoid the complexity of Really, the complexity of 'friend' comes from people abusing it. In D, I would prefer no breaking change here. Leave private as it is. Just a simple attribute that only applies within a class, and only to private members within that class. @strictly private string firstName_; Nothing outside of the class, not even the module, can access this now. It's all encapsulated. It breaks nothing (AFAIK). It's very clear what the intention is here. It's an easy attribute to remember. It restores the principle of class enscapsulation within a module, for when it's really needed. Now D programmers would have the best of both worlds.
Re: how to make private class member private
On Saturday, 17 March 2018 at 14:16:19 UTC, bauss wrote: I don't like the name @deny . how about: @reallyis private string firstName_; mmm..perhaps not... then how about... @strictly private string firstName_;
Re: how to make private class member private
On Saturday, 17 March 2018 at 09:18:13 UTC, Nick Treleaven wrote: It's a language design decision as to whether a particular feature is worth supporting. I would like this feature too though. I'm not sure how much compiler complexity would be added by having another visibility modifier. D could add an new attribute to class members: @deny A @deny attribute can come before a classes private member, to indicate that the private member is to remain private, even within the module. Cause sure, it nice to be among friends, but you don't want your friends knowing every thought that is going through your mind! Sometimes, somethings, just need to remain private. @deny private string _userName; now... _userName is no longer accessible at the module level, and class encapsulation is restored. If had I any clue about compilers, I'd think this through more ;-)
Re: OT: Behaviour of Experienced Programmers Towards Newcomers
On Saturday, 17 March 2018 at 07:16:22 UTC, Jonathan M Davis wrote: Unfortunately, we do periodically have folks act like that around here, but fortunately, for the most part, it's folks who don't stick around long, and our regular posters are generally well-behaved. - Jonathan M Davis yeah I agree 100% the people that actually know stuff around here, are NOT the people that treat others badly. I have certainly worked in environments where the opposite is true. I usually left them pretty quickly. Life is short. I've also trained sysadmins myself, and I can say, that holding back the sarcasm takes a real personal committment - to just not doing it. Once you make that committment, it becomes easier and easier...and soon enough, you're back to treating people the way they deserve to be treated. ultimately, its a personal choice, to treat people properly, or not. I don't think it's a 'community' thing. treating people properly is not dependent on any sense of being in a 'community'. so here I differ with the view in that article. (having said that, not all sarcasm is meant to offend. the best of friends can throw sarcasm at each other, and still be the best of friends).
Re: OT: Behaviour of Experienced Programmers Towards Newcomers
On Saturday, 17 March 2018 at 07:01:53 UTC, rumbu wrote: 3 days ago: https://forum.dlang.org/post/ylngefsfuwqodaprw...@forum.dlang.org yeah...but that presumes Amorphorious is an 'expert programmer'. which is not the impression I got ;-)
Re: D beyond the specs
On Friday, 16 March 2018 at 11:44:59 UTC, Chris wrote: Hint: there's a Ph.D. in it ;) Hint: Do not write a Ph.D based on impressions ;-)
Re: Vision document for H1 2018
On Friday, 16 March 2018 at 07:58:33 UTC, Dmitry Olshansky wrote: Playing captain the obvious but this is COPY not slice. Shh. Don't tell my customers that. D had slices since 2000s, pointing to any kind of memory. Mmm..D showing off.. as always ;-)
Re: Vision document for H1 2018
On Thursday, 15 March 2018 at 18:39:08 UTC, rumbu wrote:
My quote is out of context. Somebody asked surprised why C#
developers are interested in D. For me (mainly a C# developer),
this is the main reason: native compilation (and this includes
memory management). I highlighted the fact that the C# team
keep implementing D specific ideas in each new version, so
don't be surprised if your list of D exclusive features becomes
smaller with each new C# iteration. My complaint was the fact
that D drops features or push them into library solutions.
That was me ;-)
Yeah..native compilation is so nice..it's hard to resist.
And so is a good GC implementation (does D have one of those ??)
btw. run your C# or Java program for long enough, and it's
essentially native compiled anyway. When I run some of my java
programs, I still don't know how 'native compilation' would make
it go any faster (noticably). Same goes for my C# Windows Forms
apps..they just fly...native compilation wouldn't add much.
btw C# has had slices since day 1. Just required an extra
forklift or two - as opposed to taking it off the nearby shelf.
-
using System;
using System.IO;
public class Program
{
public static int Main()
{
int[] arr = { 1, 2, 3, 4, 5 };
int[] sliceOfArr = arr.Slice(2, 3);
Console.WriteLine(string.Join(", ", arr));
Console.WriteLine(string.Join(", ", sliceOfArr));
return 0;
}
}
public static class Utils
{
public static T[] Slice(this T[] arr, int start, int len)
{
T[] slice = new T[len];
Array.Copy(arr, start, slice, 0, len);
return slice;
}
}
Re: how to make private class member private
On Tuesday, 13 March 2018 at 21:38:59 UTC, Amorphorious wrote: You are a moron...etc..etc..etc..etc. See. This is what happens when you have access to a keyboard while high on ice.
Re: D course material
On Tuesday, 13 March 2018 at 12:39:24 UTC, Dmitry Olshansky wrote: Hi, folks! I’m testing waters for a D course at one University for first time it’ll be an optional thing. It’s still discussed but may very well become a reality. Before you ask - no, I’m not lecturing and in fact, I didn’t suggest D in the first place! Academics are finally seeing light in the gloom of 1 year OOP in C++ course having underwhelming results. Now to the point, I remeber Chuck Allison (pardon if I misspelled) doing D lectures at Utah Valley University, here: https://dconf.org/2014/talks/allison.html There is also Ali’s book. But anything else easily adoptable as course material? — Dmitry Olshansky Just make sure it involves problem solving because that is why we have brains. We don't have brains so we can sit through long boring presentations and seminars. Students who program, want to solve problems. Not boring silly problems, and not overly complex problems that will take up too much of their time - one of the biggest concerns expressed by students at my uni, is workload - which never seems to stop increasing. And students are really distracted these days too, so the problem is compounded. Our new is concerned about the increasing rop out rate too, which I suspect is related. And don't make them all solve the same problem. Give a range of problems so they can select something that might interest them. There's plenty of material out there, that deals with motivating students to learn.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. Actually I wonder if it's the opposite of that, because now, if I have a bug in my class implementation, the code is no longer localised to the class, but to the module - this greatly increases the burden of program correctness and maintenance. It also means the author of the class is no longer free to make changes, because all the surrounding code in the module needs to be assessed for impact - this greatly increases the burden of program correctness and maintenance.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 12:10:07 UTC, rikki cattermole wrote: On 14/03/2018 1:02 AM, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) The number of lines of code is more of a code smell which suggests that the module is going out of scope in size and functionality. I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though) While it is new to some people, we would only be rehashing existing ideas that have existed in the literature for 40+ years. Mmm...I think more than just 'some people' will be suprised when they come to D, and suddenly find that a private member may not be private at all. Particulary those C++/C#/Java programmers - who represent the vast majority of programmers on the planet. private string _Name; (oh..in D, this might be private..or it might not be..depends on what you mean by private)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 11:31:12 UTC, rikki cattermole wrote: Ah yes. You're completely correct if you subscribe to Adam's and ketmar's file sizes expectation. A D module and package is one level of abstraction. If that level of abstraction starts to fill up and gets large, you split it up. My rule is soft 1k LOC and hard 2-3k (after that it needs a VERY good reason to stay together). This makes each file to be very right down to the point and do nothing else. You should be doing this no matter the language IMO. Just the difference is in Java only one class is publicly accessible per file. Nothing stops you from doing that here either. Fair enough. I doubt I'll use your 'lines of code' method as a means of encapsulation though ;-) I have to think more, about what a module is really trying to encapsulate. I'm sure there is a good blog that could come out of this conversation. (not by me though)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. But, a module can contain so many 'friends'. Q. How many 'friends' does it take, before you lose the capacity to reason about who really is a friend?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:29:42 UTC, Alex wrote:
package myPackage;
public class Main {
public static void main(String[] args)
{
System.out.println("Hello World!");
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
System.out.println(c.myPrivateClassMember);
}
private static class myClass
{
private String myPrivateClassMember; // private does
not mean private anymore??
}
}
´´´
(may the forum forgive me :p )
But a class and its inner classes together, can be still be
reasoned about locally.
With 'modules', the boundaries of what 'local' means, becomes
more and more fuzzy, as the module gets longer and longer, and
more and more complex.
In those circumstances, it becomes much harder to reason locally
about the correctness of a class.
And a D module can go on..well...for ever.
I would still prefer that classes within a module, at least have
a capacity to specify access privileges to objects in the same
module, rather than just trusting everything in that module,
without exception.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 09:52:06 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 09:14:26 UTC, psychoticRabbit wrote: That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are) Is there a practical difference between a) a module that contains a class with 20 member functions all accessing private members of the class and b) a module that contains a class with two member functions and 18 free functions all accessing private members of the class? Does it really make a difference that some functions are on one side of a closing brace and some on the other? The scenario you mentioned is fine, as long as I don't want to protect any of my class members from free functions within the module. When I do decide that something in my class really does need protection, I have to move the class outside of the module. This concept is new to me. I have to keep thinking about it. To lose control at the level of class encapsulation, and surrender it completely to the module, no matter what..well..I'm a little unsure about it. I'd be more comfortable with being able to have your scenario and mine 'both work'. At what point, does 'principled' violation of encapsulation, just become a violation of encapsulation?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:44:48 UTC, Mike Parker wrote: Any new keywords, or reuse of existing keywords, does make the language more complex. Everything that is added must have a reason. Private is module level because friend is so common in C++, i.e. people find it useful and it would be great to support something similar in D. Making modules the lowest level of encapsulation does that without the need for an extra keyword for friends while still maintaining a strict border between external and internal APIs. Moreover, it restricts friends to the same module, easing the maintenance burden and decreasing the chance of error. It was a great decision. yeah, I probably agree that it's a good decision, when the module is the boundary. (aka so-called 'principled' violation of encapsulation) what I don't like, is that I have no way at all to protect members of my class, from things in the module, without moving that class out of that module. D wants me to completely trust the module, no matter what. That's make a little uncomfortable, given how long and complex modules can easily become(and aleady are)
Re: how to make private class member private
On Tuesday, 13 March 2018 at 08:05:43 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". what about a new access attribute (and no, I haven't though this through much): owned string _FirstName; (now the class 'owns' this. It is neither readable nor writeable outside the boundary of that class. This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership. or another idea: ownedBy T string _FirstName; where T could be 'Module' (meaning it works the way it currently does. The module can read/write to it). or T could 'Universe' (where universe means everyone can do whatever they want with it). or T could be 'This'(so class can regain control overs its own members), The default could be ownedBy Module, to retain existing behaviour. I'd even go further, with extended attributes... ownedBy Module Read string _FirstName; ownedBy Module Write string _FirstName; ownedBy Module ReadWrite string _FirstName;
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". what about a new access attribute (and no, I haven't though this through much): owned string _FirstName; (now the class 'owns' this. It is neither readable nor writeable outside the boundary of that class. This retains the existing flexibilty offered by module level encapsulation, while restoring class level encapsulation/ownership.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 07:05:48 UTC, rikki cattermole wrote: Your thought model is much younger than modules. Modules have existed since the mid 70's. They work, other designs over the years have proven to have faults and problems. D's design is evolved from already existing ideas to try and give the best of both worlds and modules is no different. The reality is, Java and C++ both are great examples where module system was added after many years too late. D had it built in from the get go and was designed to benefit from it. I don't have any objection to the idea that a module can have privileged access to members of classes within that model. It sounds sensible enough, if the module is a level of encapsulation also. My arguments is that, this was implemented in D, at the cost of removing the capacity for a class in the same module to protect it's own members (within the module). That's what I don't like about it. My other objection, as stated, is that D uses the same syntax as C++/C#/Java, but the semantics of that same syntax are completely different. I also don't like that.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:43:55 UTC, ketmar wrote: that is, we should stick to defective design only 'cause there is no "other D" that made it right? ;-) also, your question is not valid. you were told several times that you're evaluating the whole thing wrong, but you're insisting on your view being right. and you're keep asking, omiting the *critical* piece of the picture: modules. you were told that in D, encapsulation unit is *module*, not class/struct. it is not a "misdesign", it is the proper modular design. it doesn't matter what others are doing in this case. p.s.: yes, i know such language. Delphi/FreePascal. Gee.. I feel like I'm on a Rust forum, being attacked my their sjw moderators. Whatever happened to the 'discussion' component of these 'discussions'?
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: The same applies here. Encapsulation simply isn't broken by this feature. What you're saying, is in D, class encapsulation is really 'module' encapsulation. I get it. Fine. It's an intersting design decision. But, in doing that, D has shifted the boundary of class encapsulation, to a boundary that is outside the class. To me, that sounds like D has broken class encapsulation. I don't know how else one could describe it. I continue to think, that class encapsulation is sacred, a well defined, well understood, concept that has been around for a very long time. private could have still meant private, and surely someone could have come up with a different access modifier to mean 'private at module level'. Was that too hard the language designers? Was it not hard, but just to complex to implement? I don't get it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:26:13 UTC, Radu wrote: On Tuesday, 13 March 2018 at 06:14:49 UTC, psychoticRabbit wrote: On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong?? Yes, they got it wrong! Because they don't have modules, and because Java & C# are OOP bondage-everything-is-a-class, and preach that the world spins on classes. C++ tried to fix it with 'friend', and it shows the hack that it is. Don't know why you think D should be just another Java or C#? Well I don't really. But one of the great things about D, is that a C++/C#/Java programmers can jump right in. But when the same syntax suddenly means something really different, I tend to think that's not a good design decision. And that's really the main point of my argument. As I said, this was a real gotcha for me. I only realised after I accidently tried to modify a private member directly, and discovered I did actually modify it! Maybe, a different modifier that made it private to the module would have been a better design decision.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:25:39 UTC, ketmar wrote: psychoticRabbit wrote: So the 3 most used languages got it wrong?? yes. do you know any other language, where a private class memeber, is not private to the class? (btw. that's a question, not a statement).
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:03:11 UTC, Mike Parker wrote: I think it's a great feature and I use it frequently. It's allows more flexibility in class design. Without it, we'd need another protection attribute to enable the concept of "private to the module". That's kind of my point. That's what I would have done, if for no other reason, to prevent the same syntax from having different semantics (when C++/C#/Java programmers come over to D). And I switch between them all, and now, I have to remember D's private memeber is something very different indeed. In Java, it's recommended to manipulate private member variables through their accessors even in methods of the same class. I've always found that extreme. Java is extreme in many ways ;-) but at least, private member, is still a private member (to the class). If my private class memeber can be directly modified outside of the class, then class encapsulation IS broken. Just saying, oh no, it's module encapsulation you should be thinking about, seems kinda strange, since we still use classes - which are their own level of encapsulation. That's the whole point of them.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:35:30 UTC, Amorphorious wrote: There is another problem: 3rd: You are a brainwashed monkey who can't think for himself. Gee..takes some real brains to come up with that one. See, You learned a little about C++/C#/Java and think the world must conform to what they say is correct and deny everything that contradicts it rather than first seeing if you are on the wrong side of the contradiction. The fact is, there is no reason a module should be restricted to see it's own classes private members. Yeah that sounds fine. As long as you're willing to give up the concept of class encapsulation. And, as long as you are willing to have programmers use the same syntax in D, as used in the 3 most widely used lanaguages on the planet, but get very different semantics. It's a real gotcha for those programmers. It's sorta like a family who runs around pretending that they can't see each others private parts. Sure, it sounds like a good thing... until someone accidentally drops the towel and the offended calls the cop on their brother and has him arrested for breaking the law. I'm not interested in your fanatasies. Keep them to yourself. You should learn that your view of the world is very minute and stop trying to fit the world in to your box. It's called growing up. If you can't make a distinction between C++ encapsulation and D encapsulation you have far bigger problems than you think. I think the view of the 3 most widely used langauges on the planet, is not something to dismiss so easily. D has what, 1000 programmers, maybe.. so I wonder whose world is really minute. In any case, I'm not attacking D. I use it. I am just questioning whether the different semantics for private, in D, is really worth it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 06:01:43 UTC, ketmar wrote: ah, yes, sorry: i completely forgot that C++ was invented after c# and java. mea maxima culpa! My point was, that the 2 most widely used and popular languages on the plant, C# and Java, decided NOT to make private, something mean else, like D has done. So the 3 most used languages got it wrong??
Re: how to make private class member private
On Tuesday, 13 March 2018 at 05:52:55 UTC, ketmar wrote: psychoticRabbit wrote: There are two problems I see: 1) it is not how C++ done it. 2) it is not how C++ done it. and you're completely right: it is not how C++ done it. umm...didn't you forget something: 1) it is not how C# done it. 2) it is not how C# done it. 1) it is not how Java done it. 2) it is not how Java done it.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 02:24:38 UTC, Mike Parker wrote: On Tuesday, 13 March 2018 at 02:06:57 UTC, psychoticRabbit wrote: Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all. If you have access to the module source, you have access to the source of types inside it. Making the module the lowest level of encapsulation makes sense from that perspective. There are two problems I see: 1st - D has broken the concept of class encapsulation, simply for convenience at the module level. Not good in my opinion. 2nd - C++/C#/Java programmers will come to D, use the same syntax, but get very different semantics. Not good in my opinion. (i.e. I only realised private was not private, by accident). D has made many good design decisions. I do not see this as one of them.
Re: how to make private class member private
On Tuesday, 13 March 2018 at 01:39:13 UTC, Jonathan M Davis wrote: private is private to the module, not the class. There is no way in D to restrict the rest of the module from accessing the members of a class. This simplification makes it so that stuff like C++'s friend are unnecessary. If your class in a separate module from main, then main won't be able to access its private members. - Jonathan M Davis Mmm.. I don't think I like it. I feel you should be able to make a member of a class, private, regardless of where the class is located. This seems to break the concept of class encapsulation. No. I don't like it at all.
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 19:09:42 UTC, Dennis wrote: On Monday, 12 March 2018 at 16:07:40 UTC, SealabJaster wrote: This post may not be all that helpful, but I feel the need to voice the frustrations with my experience. Sorry for the pointless/off-topic rant. Thank you for this post, I found this actually really insightful. I'm also (relatively) inexperienced, a Windows user, and I have time/motivation for contributing. Your post is very relatable to me. But while you actually tried to compile dmd, I kind of pushed it aside after seeing how much there is involved in setting it up, predicting a big hassle like you describe. I really wish it could be as simple as cloning the repository and running a command on Windows. hey... I have 25+ years experience as a systems administator. i.e I'm very, very used to doing very complex things. complex, is my day at the office. But even I couldn't get my head around how to compile D from source on Windows ;-) I do have it compling just fine on my freebsd system, and multiple different linux's I use. But Windows? Forget it. Someone will need to explain in detail how that is actually done - I no longer have the patience for working that one out.
how to make private class member private
I cannot get my head around, why private is not private, in D.
How do I make a private member, private?
-
module test;
import std.stdio;
void main()
{
myClass c = new myClass();
c.myPrivateClassMember= "wtf";
writeln(c.myPrivateClassMember);
}
class myClass
{
private string myPrivateClassMember; // private does not mean
private anymore??
}
--
Re: Vision document for H1 2018
On Monday, 12 March 2018 at 06:13:35 UTC, rumbu wrote: I'm comparing two open source projects, both hosted on github. Both available in the same supermarket. It seems that one of them is easy to reach to, the other one is on the top shelf and you need a forklift to reach it. And when you bring the forklift, you find out that you need two additional excavators running on a special kind of fuel which is not available in your country. I'm comparing the contributing experience, because almost every time when someone complains about something, is invited to contribute himself. yeah, but if you know in advance, that you need a fork lift to reach it, and that you'll also need two additional excavators running on a special kind of fuel, which is not available in your country...then..and only then.. are your expectations in line with reality ;-) but people come to D, thinking they can just walk over to the shelf and take it. (because that's often what they are used to). Some of us are actually used to the very opposite - i.e you always have make that extra effort, even to do the most simple things. But that effort just seems normal to us. I agree, there needs to be more middle ground, which both types will benefit from in the end.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 16:15:22 UTC, rumbu wrote: On Sunday, 11 March 2018 at 14:37:28 UTC, bachmeier wrote: And this clarifies the source of your confusion. The D programming language is an open source project, not a for-profit company. D is not the language you're looking for. There are 3 years since C# is also open source project. Last week 72 pull requests form 24 contributors were merged on ~master. And this is only for Roslyn (the C# compiler). The difference (at least for me) is that contributing to C# is a no-brainer. Contributing to D needs an advanced degree in computer science. Using the information on the D wiki didn't helped me until now to successfully compile and test a fresh copy of dmd or phobos. Hey.. I feel your pain.. I like things to be easy too ;-) but I think comparing things in the C# world, to things in the D world, does not make a lot of sense, really. It's like comparing my local corner shop to some worldwide supermarket chain. What's the point in going into the local corner shop and complaing that they don't stock this or that, but the supermarket down the road does. Or complaining that they charge $4 for a loaf of bread, when down the road at the supermarket it only costs $2.50. You have to compare apples with apples, not apples with shiny red toffee apples ;-)
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 13:36:27 UTC, R wrote: I am sure that lots of D members will be quick to point out, that C# is run by a commercial company and D has only open source contributors. Now why did you not contribute! /sarcasm I'd like to point out, that C# is run by a commercial company and D has only open source contributors. For that matter, so is Rust (a 1/2 billion $ organisation, at least), run by sjw's who will 'attack' (as opposed to 'point out') anyone that speaks out against anything. As for cross platform, have you tried running Rust in Windows XP? Anyway.. I'm going back to the sandbox, to play with my own toys.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 07:59:53 UTC, rumbu wrote: My opinion is that the day when C# will compile to native (on any platform), the C# developer interest in D will drop instantly. OT: Interestingly, my uni is still stuck in the OOP paradigm, and is now teaching intro to OOP using .NET Core, cause it's now cross platform, and people can also used VS code, which also cross platform. but running > dotnet myprogram (.dll) is just an awful experience ;-) although, that's how java works to.. and java is probably the most widely used language of all.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 05:41:02 UTC, Dylan Graham wrote: I regret some of things I said. I'm sorry for any offence caused, specifically towards members of the DLF. I don't think you need to regret saying anything. You've demonstrated a willingness to engage in a conversation that we can *all* learn from. I also doubt anyone actually got offended ;-) .. we're all pretty strong minded here. But I get back to my point about "programmer" portability. Other developers of newer languages just don't seem to get that. And it's hardly surprising that D would be focused in some way, on languages used by the vast majority of programmers (C/C++/Java/C#... and dare I say it..python) That is D's great strength. (and betterc is just a part of it - and not one that particulary interests me). Because D resources are rather contstrained, betterc gets more push back than it really should. But the main take away point I get from that vision statement, is a greater focus on increasing contributions - which is really what D needs more than anything (apart from a correct and complete language specification).
Re: List installed modules
On Sunday, 11 March 2018 at 03:52:19 UTC, psychoticRabbit wrote: Whether dub does that currently I do not know, as i don't use dub, or any additional packages outside of phobos. oh > dub list ;-)
Re: List installed modules
On Sunday, 11 March 2018 at 01:04:27 UTC, Roberto wrote: How do I list installed modules? or.. https://dlang.org/phobos/index.html
Re: List installed modules
On Sunday, 11 March 2018 at 01:04:27 UTC, Roberto wrote: How do I list installed modules? dmd --list-modules datefmt dateparser std.algorithm std.array std.conv std.datetime std.digest std.exception std.file std.format std.getopt std.json std.math ... Presumably, you mean packages installed by dub, as opposed to what comes with phobos as part of the installation. If that's what you mean, then that could be an enhancment request - i.e. to have dub maintain a list of what's installed, like any good package manager should. Whether dub does that currently I do not know, as i don't use dub, or any additional packages outside of phobos.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:58:50 UTC, psychoticRabbit wrote: i.e. How can the D Foundation encourage new additional resoures to focus on things that also matter to the community. and btw. the mention about strengthing the use of DIPS, does just that. there are many improvement to 'process' that can be done to encourage more people to contribute to D. This is not about betterc at all, really.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:53:30 UTC, Dylan Graham wrote: That sentence was to counter psychoticRabbit. I didn't mean it literally. If you've read my earlier posts, it's not BetterC I have an issue with, it's the allocation of time. Well that should have been the basis of your original argument. i.e. How can the D Foundation encourage new additional resoures to focus on things that also matter to the community. Instead, you started by attacking the D Foundation for allocating resources to betterc.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:46:09 UTC, Dylan Graham wrote: Rust was more popular and who could use that? Rust is popular because of its ideas, not because it pandered. I don't see "programmer" portability as being pandering. It common sense. Rust is good, in that it seeks to do something different. I like that. But I live in the real world, and need to switch between languages often. Language theory is nice and all that, but "programmer" portability is paramount for me.. not popular ideas. And Rust is popular... with Rust programmers.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:36:51 UTC, Dylan Graham wrote: The D Language Foundation, being the leading body of D, should hold some responsibility to the interests of the majority. And also the minority. A lesson that humanity has to learn over and over again.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:25:07 UTC, Dylan Graham wrote: I'm not sure what you mean at that last sentence. I mean, cause D is so compatible with C/C++/Java/C# - that you can easily switch between them. Whereas as Go and Rust have their own thing going, making those languages really difficult in terms of "programmer" portability. C++ became popular cause C programmers could easily use it. Java became popular cause C/C++ programmers could easily use it. C# became popular cause C/C++/Java programmers could easily use it. D is gradually becoming popular cause C/C++/Java/C# programmers can easily use it.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote: And "scripting" language like PHP, that everybody criticizes just keeps growing and gained 11% market share in the last 7 years ( at now 83% ). Where as D its gain has been minimalist thanks to people leaving almost as fast as it gain. Well, according to the TIOBE Index, C was the language of 2017. Java is almost always on top, followed by C, followed closely by C++. And it's not just 'old timers' using those languages... surely. And scripting language can pretty much replace any other scripting language. It's the 'real' programming languages that matter ;-) And D's not doing to badly at all...despite betterc https://www.tiobe.com/tiobe-index/d/ (although I wonder what happended back in 2009 ??)
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 01:06:08 UTC, R wrote: Point to the wall on the left side. That is what your talking to. D its focus on C++ as a bad plan has been made pushed by many people ( lots who left ). Its like asking Go for Generics. And its very nice to see the "71% in the poll do not want BetterC", well, screw them comment. So what is the point again by asking people opinions? And sure, BetterC can be reused to improve the D core but that is not what people want NOW. And yet, its a priority when 71% say its not! D simply is not equipped for dealing with people who come from languages like C#, Ruby, PHP, Python, ... because too many people here are C++ old timers ( yes, there are exceptions ) and they only think in that direction. There is a lesson the be learned in this somewhere... Again, D is not run by some corporation. Nor is it a democracy - where majority rule. (read this sentence over and over till you get it) It's a language that develops because people are sufficiently motivated to put in the time to develop what interests them. Have your say and leave it at that. Stop attacking the work others are doing. And stop your discriminatory use of the phrase 'old timers'.
Re: Vision document for H1 2018
On Sunday, 11 March 2018 at 00:36:19 UTC, Dylan Graham wrote: Every day D becomes more like C++ 2.0, why can't it just be D? Oddly enough, I think this is D's strength. Golang tried to draw the line, and look where that got it. Now it's a limited language for a specific domain (at least until Go 3.0). Rust decided (and Go to some extent), to introduce foreign syntax that was vastly different to what the majority of programmers are familiar with, and, it makes it difficult to transistion to because its syntax is so unlike the syntax most people will continue to have to work with. D's strength, is that most C/C++/Java/C# programmers can just jump right in and use it. And, they can continue to go back and forth without syntax related psychosis developing. betterc is just another way of supporting that crowd..and it's a very big crowd. Your problem is not betterc, but something else. So focus on that instead. And personally, depending on the problem, C# is better to program in than D. I still don't know why C# programmers are willing to give up C# and prefer to use D. C# is vastly surperior for what it does. D is also particulary useful for some problems. Better to use both, not one or the other. Thanks to not being Go or Rust, you can do that - cause concepts, syntax etc, are really compatible with both.
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote: I'm talking about the D Foundation priority list, not about the open source community surrounding it. I have nothing against betterC, the community is free to work on it, but I don't understand why it's a *priority* for the D foundation. Is there any funding involved requesting explicitly betterC support? perhaps this question can be one of many, that the community ask the members of the D foundation, on stage, during the Q and A at the upcoming Dconf ;-) there will be a roasting.. won't there?
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 11:45:25 UTC, rumbu wrote: I'm talking about the D Foundation priority list, not about the open source community surrounding it. I have nothing against betterC, the community is free to work on it, but I don't understand why it's a *priority* for the D foundation. Is there any funding involved requesting explicitly betterC support? I think cause interoperating with C/C++, as well as encouraging migrating C/C++ code over D..has always been a key objective for Andrei and Walter (as least that's the impression I get - as a relative newcomer to D). So I doesn't surprise me that it would be (remain) a priority for the D foundation, which they (and others) represent. All power to em... Although... I'm just not convinced that C programmers will give up C, and C++ programmers will give up C++ ... well... certainly I don't see any mass migration on the horizon of my crystal ball. Everyone will end up programming in C++, Java, or .NET .. says the crystal ball.
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 10:05:49 UTC, rumbu wrote: According to the State of D Survey, 71% of the respondents don't care about betterC. Why is betterC on the priority list? who cares what 'the majority' want... I mean really. stuff em! (ohh... that was in jest.. don't take that seriously)
Re: Vision document for H1 2018
On Saturday, 10 March 2018 at 10:47:09 UTC, Dylan Graham wrote: Yeah. Why should D worry about tying itself into C when it can't even interface with itself through DLLs? A reasonable point. But.. in any case.. people work on what they are motivated to work on. That's really all there is to it. That's how the open source community works. Top down, corporate direction, simply does not apply here. One day you (or some other D programmer) might need betterC - who knows - and it'll be there for you - cause someone else was motivated to do it.
Re: Vision document for H1 2018
On Friday, 9 March 2018 at 21:43:53 UTC, Andrei Alexandrescu wrote: Hello, the vision document of the Founation for the first six months of 2018 is here: nice. andd that 'langauge specification' is really important too.. or people will drift towards languages that 'are' properly specified. None of us like to be surprised by what the compiler does. The spec should tell it what to do. and...just don't implement a 'no hugs' policy, or I'm outta here ;-)
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 20:50:37 UTC, Jack Stouffer wrote: Also, if you'll allow me to have crazy ideas for a moment, one wonders why we shouldn't just release Phobos itself through dub? Rust makes people use their build tool, why not us? That's the day I stop using D. I do not, and will not, use dub. Full stop. Same goes for Rust ;-)
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 07:11:24 UTC, Jonathan M Davis wrote: That example actually should be perfectly @safe, because the array is null, and it's using writeln. Dereferencing null is @safe, because it segfaults and thus can't corrupt memory or access invalid memory. You obviously don't want it to happen, but it's @safe. Also, passing a pointer to writeln is fine, because it's just going to print the value, so that's @safe too, even if the pointer value is garbage. my point had nothing to do with writeln. my point was, that a RangeError exception may help save the day, but not when you use .ptr thankfully Steven gave a much better example to make the point clearer ;-) (I assume that int is meant to be size_t)
Re: Release D 2.079.0
On Tuesday, 6 March 2018 at 05:22:58 UTC, Void-995 wrote: Can somebody explain how [0] is more safe than array.ptr? Just want to understand why second statement isn't allowed in safe anymore. int[] a; writeln([0]); // good - runtime produces a core.exception.RangeError //writeln(arr.ptr); // what do you think will happen here?
Re: Speed of math function atan: comparison D and C++
On Monday, 5 March 2018 at 06:01:27 UTC, J-S Caux wrote: So the codes are trivial, simply some check of raw speed: double x = 0.0; for (int a = 0; a < 10; ++a) x += atan(1.0/(1.0 + sqrt(1.0 + a))); for C++ and double x = 0.0; for (int a = 0; a < 1_000_000_000; ++a) x += atan(1.0/(1.0 + sqrt(1.0 + a))); for D. C++ exec takes 40 seconds, D exec takes 68 seconds. should a be an int? make it a double ;-)
Re: string object won't compile
On Monday, 5 March 2018 at 23:34:50 UTC, askjfbd wrote: Someone please tell me how, for I am a newbie and don't know any solutions even to this very simple problem. As I learned dlang using the Dlang tour page, I stuck at the alias & Strings page. I have tried to compile the following simple code many times but still get the same error both from dmd and gdc. They both say that... This is mistake I made too, when i began using D. I quickly got into the habit of putting module test; at the beginning of every file I create, unless I determine a better module name. Actually, I wrote my own IDE, so it does that for me whenever I select a new D file. Personally, I think that is one of the first things newcomers need to learn about - modules. - "Modules have a one-to-one correspondence with source files. The module name is, by default, the file name with the path and extension stripped off, and can be set explicitly with the module declaration." "Modules automatically provide a namespace scope for their contents." https://dlang.org/spec/module.html
Re: Release D 2.079.0
On Monday, 5 March 2018 at 23:40:35 UTC, Atila Neves wrote: I'd have a snowball's chance in hell convincing anyone at a "regular" company of adopting D if anyone there even imagined any of the above could happen. We have to do better than this. Atila Fair enough. Doing better is always a good thing to aim for. But really, who use something 'just released' in production? As far as I'm concerned, every release is a beta... even if the beta tag is removed. The real problem is something you mentioned .. new comers downloading the latest release..which as I mentioned, is really a beta. But that's just the way software developement works these days - sadly - ship quickly, and ship often. As a result, we're all just testers for the latest release.
Re: Release D 2.079.0
On Saturday, 3 March 2018 at 01:50:25 UTC, Martin Nowak wrote: Glad to announce D 2.079.0. This release comes with experimental `@nogc` exception throwing (-dip1008), a lazily initialized GC, better support for minimal runtimes, and an experimental Windows toolchain based on the lld linker and MinGW import libraries. See the changelog for more details. Thanks to everyone involved in this https://dlang.org/changelog/2.079.0.html#contributors. http://dlang.org/download.html http://dlang.org/changelog/2.079.0.html - -Martin Well done to all! (especially the work on the toolchain) I'm going to download it and test that import syntax thingo...just to make sure it really is gone ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 12:20:31 UTC, Paulo Pinto wrote: And if you like C so much, what are you doing in a safe systems programming language forum? How safe is D.. i mean really ;-) and why do people ask me that question.. I don't get it. I program (or try to) in as many languages as my brain can handle ;-) (which oddly enough, seems to be stuck at about 7)
Re: [OFF TOPIC] State of D 2018 Survey
On Friday, 2 March 2018 at 13:05:58 UTC, Russel Winder wrote: Science, in and of itself, cannot be dodgy. science must involve humans, and humans are often dodgy. Yes there are debates to be had, cf. Popper, Kuhn, etc. but the foundation of science is hypotheses, experimentation, and reproducibility. It can be done badly or well by people, but it is not a dodgy thing. there is no science without humans - they are two sides of the one coin. If humans can be dodgy, so can science. Perhaps you do not, but Rust, like Go, is getting traction in the world out there. Like COBOL, C will always be there, but its use will diminish rapidly. Only when hardware becomes significantly faster, will C begin to fade, as then the case for C diminishes. I do like the simplicity of Go - and then there are days when I just hate that simplicity. That R?s? thing...well...it is too odd for most people to embrace, I think It is worth keeping an eye on .NET - as Microsoft are very determined to make this a cross platform runtime, and programming in C# is just .. nice. And if I recall correctly, Java and .NET still dominate the employment opportunities, and as 'safety' is becoming even more and more important, I think that is likely to stay that way for a long time to come. So I think all these new languages will just be playgrounds for ideas, or become domain specific languages, while .NET and JAVA use will continue to increase.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 12:02:43 UTC, Russel Winder wrote: On Fri, 2018-03-02 at 11:52 +, Russel Winder wrote: […] report science, does make science dodgy. But that stray off topic for […] s/does/does not/ Obviously. :-) mmm...freudian slip?? I study science...and what's being taught to us .. is dodgy. and anyway, since when do D forum discussion stay on topic? C ruleZ! ..and D does too ;-) ... and I don't want to hear about Rust. So lets agree to never, ever mention that word...ever again.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 11:00:09 UTC, Jonathan M Davis wrote: In any case, I expect that anyone who wants D3 is going to have a very hard time convincing Walter and Andrei that such large breaking changes would be worth it at this point. - Jonathan M Davis I agree. I don't think there is enough to warrant a D3 at this point. But still, imagine if every time an architect built a house, it had to be built using the same specs as the previous house. You'd end up with garbage, piled upon garbage. In essence, you'd get C++. So exploring ideas around what a new design might look like, can be useful too, so let's not discourage that by talking about 'forking' concerns.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 10:21:05 UTC, Russel Winder wrote: ...continue with C in the face of overwhelming evidence it is the wrong thing to do. yeah, the health fanatics who promote their crap to goverments and insurance agencies, use very similar arguments about sugar, salt, alchohol, this and that when really, it's all about moderation, not prohibition (or increased taxes on things people say are bad). and science is so dodgy these days, that even scientific evidence requires evidence. c rules!
Re: single loop copy in D
On Friday, 2 March 2018 at 10:08:57 UTC, Simen Kjærås wrote:
This is of course only partly true.
while ((*dst++ = *src++) != 0) {}
works just great, and also better shows what's actually being
tested for in the loop.
--
Simen
That's what I was after. Thanks!
single loop copy in D
trying to do this C code, in D, but getting error:
"Error: assignment cannot be used as a condition, perhaps `==`
was meant?"
any help much appreciated:
--
while ((*dst++ = *src++)) {}
--
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 03:57:25 UTC, barry.harris wrote: Sorry little rabbit, your are misguided in this belief. Back in day we all used C and this is the reason most "safer" languages exist today. You can write pretty safe code in C these days, without too much trouble. We have the tooling and the knowledge to make that happen.. developed over decades - and both keep getting better, because the language is not subjected to a constant and frequent release cycle. Ironically, the demands on programmers to adapt to constant change, is actually making applications less safe. - and least, that's my thesis ;-) The real problem with using C these days (in some areas), is more to do with its limited abstraction power, not its lack of safety. And also C is frowned upon (and C++ too for that matter), cause most programmers are so lazy these days, and don't want to write code - but prefer to just 'link algorithms' that someone else wrote. I include myself in this - hence my interest in D ;-) Keep those algorithms coming!
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:35:46 UTC, Meta wrote: D1 -> D2 nearly killed D (can't remember which, but it was either Walter or Andrei that have said this on multiple occasions). A D2 -> D3 transition might generate a lot of publicity if done very carefully, but more than likely it would just put the nails in the coffin for good and destroy all the momentum D has built up over the past 3 years (I feel like 2015 was a big turning point where D finally got back on peoples' radars). I've read a bit about that history, but really, sometimes you have to be agressive with change or just it won't come about. And I don't see how D2 could have come about without an agressive push for change. And it's unlikely that D would have died. Some people might have left (and probably did). But D is better because it's D2. Imagine promoting D1 to the world! D3 could be even better. (e.g. @safe by default..just for starters). And I personally think all this ongoing integration with C and C++ is not ideal. It's creating a really complex beast, that has to be maintained indefinitely... by someone. So I'd like to see D3 dump all the compatibility crap ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 02:02:42 UTC, psychoticRabbit wrote: btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." I'd also argue, that languages that are relatively stable, are far 'safer' than languages that constantly change. So given that the world is so focused on developing a variety of so called 'safer' languages, with ever rapid, frequent, release cycles, the world would actually be alot 'safer' if everyone went back and programmed in C ;-)
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 01:19:53 UTC, H. S. Teoh wrote: Because it has not stopped changing. To wit: K C (1978) C89 / C90 / ANSI C (1989-1990) The 1995 amendment to ANSI C (1995) C99 (1999) (Embedded C (2008)) C11 (2011) T btw. I never said 'stop changing', I said "I wish programming languages would just stop changing so often." And that last update to C, in 2011, was 7 years ago.. relative stability is a sure sign that something is right. constant, regular, change is a sure sign that something is wrong. And if stability were not the preferred state towards which things evolve, then the universe would be a very different place indeed.
Re: State of D 2018 Survey
On Friday, 2 March 2018 at 00:53:02 UTC, H. S. Teoh wrote: On Fri, Mar 02, 2018 at 12:39:08AM +, psychoticRabbit via Digitalmars-d-announce wrote: [...] On the otherhand, I wish programming languages would just stop changing so often. [...] Change is inevitable, except from a vending machine. :-P The day a language stops changing is the day it begins to die. T C will never die !!
Re: State of D 2018 Survey
On Thursday, 1 March 2018 at 21:49:31 UTC, Jonathan M Davis wrote: That being said, I think that it's a given that we need to make breaking changes at least occasionally. The question is more how big they can be and how we go about it. Some changes would clearly be far too large to be worth it, whereas others clearly pay for themselves. The harder question is the stuff in between. ... - Jonathan M Davis Personally. I think the D1..D2 transistion was great idea. I think D2..D3 should follow the same principle. i.e restrict breaking changes to major versions. People are always able to stay on the major branch that they need - there are no forced upgrades here - you choose which major branch works for you. The source code is all there for you, to do as you please. This is the only way to evolve - otherwise D will just become another convoluted piece of %3@f!, like C++. On the otherhand, I wish programming languages would just stop changing so often. The constant release cycles is just crazy! That's a sure sign that something is not right. And who wants to program in a langauge that is not right?? That's why I still like, still use, and typically still prefer .. C. Nobody dares change it ;-)
Re: forcing tabs in regex
On Wednesday, 28 February 2018 at 01:06:30 UTC, dark777 wrote:
Regex validates years bisexto and not bisextos in format:
const std::regex
pattern(R"(^(?:(?:(0?[1-9]|1\d|2[0-8])([-/.])(0?[1-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec|[Ff]eb)|(29|30)([-/.])(0?[13-9]|1[0-2]|[Jj](?:an|u[nl])|[Mm]a[ry]|[Aa](?:pr|ug)|[Ss]ep|[Oo]ct|[Nn]ov|[Dd]ec)|(31)([-/.])(0?[13578]|1[02]|[Jj]an|[Mm]a[ry]|[Jj]ul|[Aa]ug|[Oo]ct|[Dd]ec))(?:\2|\5|\8)(0{2,3}[1-9]|0{1,2}[1-9]\d|0?[1-9]\d{2}|[1-9]\d{3})|(29)([-/.])(0?2|[Ff]eb)\12(\d{1,2}(?:0[48]|[2468][048]|[13579][26])|(?:0?[48]|[13579][26]|[2468][048])00))$)");
this regex above validates the formats through backreferences.
what is this evil dark magic?
Re: C++ launched its community survey, too
On Tuesday, 27 February 2018 at 15:52:15 UTC, Andrei Alexandrescu wrote: https://isocpp.org/blog/2018/02/new-cpp-foundation-developer-survey-lite-2018-02 Andrei really, online surveys are dodgy at best. btw. Bjarne Stroustrup recently received the 2018 Charles Stark Draper Prize for Engineering - https://www.nae.edu/Activities/Projects/Awards/DraperPrize/DraperWinners/2018Draper.aspx I think that is dodgy too. Why give someone a prize for creating C++. I just don't get it. It should have gone to the Java developers - cause they deserved it. C++ is the worst thing to have ever come out of computer science! The only reason it's still with us, is because corporations are stuck with it, and force it on us all, cause it's too expensive for them to replace. I want no part of it. The answer to Q:15 => I'd go back in history and make Stroustrup a fluffy dog, or a fluffy cat or something.
Re: Documentation for any* dub package, any version
On Tuesday, 27 February 2018 at 02:57:08 UTC, Adam D. Ruppe wrote: Saturday morning, a user complained that several leading dub packages had poor documentation, if they could find it at all. That's changing, right now. Before long, packages without docs are going to suffer. This will put pressure on authors to have *something* written, and I'm providing the lowest cost for greatest benefit to help your package succeed in the market. Uhh? I don't get...why coders need to write documentation? .. it doesn't make any sense. stop this nonsense... at once!
Re: iota to array
On Tuesday, 27 February 2018 at 00:04:59 UTC, H. S. Teoh wrote: A 64-bit double can only hold about 14-15 decimal digits of precision. Anything past that, and there's a chance your "different" numbers are represented by exactly the same bits and the computer can't tell the difference. T I really miss not having a (C# like) decimal type.
Re: iota to array
On Sunday, 25 February 2018 at 14:52:19 UTC, Steven Schveighoffer wrote: 1 == 1.0, no? no. at least, not when a language forces you to think in terms of types. 1 is an int. 1.0 is a floating point. I admit, I've never printed output without using format specifiers, but still, if I say write(1.0), it should not go off and print what looks to me, like an int. Inheriting crap from C is no excuse ;-) and what's going on here btw? assert( 1 == 1.01 ); // assertion error in DMD but not in LDC assert( 1 == 1.001 ); // no assertion error?? (compiled in 64bit mode)
Re: iota to array
On Sunday, 25 February 2018 at 12:13:31 UTC, Andrea Fontana wrote: On Sunday, 25 February 2018 at 09:30:12 UTC, psychoticRabbit wrote: I would have preffered it defaulted java style ;-) System.out.println(1.0); // i.e. it prints 'what I told it to print'. System.out.println(1.0); // print 1.0 System.out.println(1.0); // print 1.0 So it doesn't print "what you told it to print" Andrea Fontana can someone please design a language that does what I tell it! please!! is that so hard?? print 1.0 does not mean go and print 1 .. it means go and print 1.0 languages are too much like people.. always thinking for themselves. I fed up! fed up I say!
Re: How do you get comfortable with Dlang.org's Forum?
On Sunday, 25 February 2018 at 01:49:05 UTC, rikki cattermole wrote: On 25/02/2018 2:31 PM, psychoticRabbit wrote: NNTP is not the future..it's the past. Good news, mailing lists will exist long after we're all dead and gone. We don't actually die, cause every atom in our body is billions of years old. Explaining that, is almost as hard as explaining why people still use NNTP.
Re: iota to array
On Sunday, 25 February 2018 at 08:46:19 UTC, rumbu wrote:
On Sunday, 25 February 2018 at 08:08:30 UTC, psychoticRabbit
wrote:
But umm what happended to the principle of least
astonishment?
writeln(1.1); (prints 1.1)
whereas..
writeln(1.0); (prints 1)
I don't get it. Cause it's 'nicer'??
Because writeln(someFloat) is equivalent to writefln("%g",
someFloat). And according to printf specification, "trailing
zeros are removed from the fractional part of the result; a
decimal point appears only if it is followed by at least one
digit"
oh. that explains it.
I would have preffered it defaulted java style ;-)
System.out.println(1.0); // i.e. it prints 'what I told it to
print'.
Re: iota to array
On Sunday, 25 February 2018 at 06:35:07 UTC, Jonathan M Davis
wrote:
It's not printing ints. It's printing doubles. It's just that
all of the doubles have nothing to the right of the decimal
point, so they don't get printed with a decimal point. If you
did something like start with 1.1, then you'd see decimal
points, because there would be data to the right of the decimal
point. The same thing happens if you do
writeln(1.0);
as opposed to something like
writeln(1.3);
thanks.
But umm what happended to the principle of least astonishment?
writeln(1.1); (prints 1.1)
whereas..
writeln(1.0); (prints 1)
I don't get it. Cause it's 'nicer'??
I ended up having to work around this..like this:
---
void printArray(T)(const ref T[] a) if (isArray!(T[]))
{
if( isFloatingPoint!T)
foreach(t; a) writefln("%.1f", t);
else
foreach(t; a) writefln("%s", t);
}
---
Re: iota to array
On Sunday, 25 February 2018 at 05:40:19 UTC, Jonathan M Davis
wrote:
int[] intArr = iota(1, 11).array();
- Jonathan M Davis
thanks!
oh man. It's so easy to do stuff in D ;-)
But this leads me to a new problem now.
When I run my code below, I get ints printed instead of doubles??
-
module test;
import std.stdio : writeln;
import std.traits : isArray;
import std.array : array;
import std.range : iota;
void main()
{
int[] intArr = iota(1, 11).array(); // 1..10
double[] doubleArr = iota(1.0, 11.0).array(); // 1.0..10.0
char[] charArr = iota('a', '{').array(); // a..z
printArray(intArr);
printArray(doubleArr); // why is it printing ints instead of
doubles??
printArray(charArr);
}
void printArray(T)(const ref T[] a) if (isArray!(T[]))
{
foreach(t; a)
writeln(t);
}
-
iota to array
Hi. Anyone know whether something like this is possible?
I've tried various conversions/casts, but no luck yet.
Essentially, I want to cast the result set of the iota to an
array, during initialisation of the variable.
no, I don't want to use 'auto'. I want an array object ;-)
--
module test;
import std.stdio;
import std.range : iota;
void main()
{
int[] intArr = iota(1, 11); // 1..10
double[] doubleArr = iota(1.0, 11.0); // 1.0..10.0
char[] charArr = iota('a', '{'); // a..z
}
-
Re: How do you get comfortable with Dlang.org's Forum?
On Saturday, 24 February 2018 at 20:29:34 UTC, Walter Bright wrote: Yeah, the immutability of NNTP posts is a feature, not a bug. but aren't git changes essentially immutable too? as long is there is a history of the changes, there is no problem with changes. I'm really only interested in the correct version of the persons intention, not some multitude of changes. It also has the effect of encouraging people to pause a moment before hitting [Send], which is definitely a good thing. yeah right. a good thing if we were robots instead of humans. NNTP is not the future..it's the past.
Re: Beta 2.079.0
On Saturday, 24 February 2018 at 07:09:05 UTC, zabruk70 wrote: i don't understand whole theread. why all import must be written on one line? curent syntax very handy and readable. you must have understood the thread, cause you summarised it pretty well ;-)
Re: Template Constraints
On Saturday, 24 February 2018 at 04:22:12 UTC, Jonathan M Davis wrote: Why is there anything dodgy going on and why would you need contracts? Contracts actually tend to go very badly with generic code, because whatever they assert has to be generic, and while that works sometimes, more often than not, it doesn't. - Jonathan M Davis what if 3.3 is passed to the template, and it explicately casts it to an int. To me, that would be dodgy - unless there was a contract, that I had accepted and agreed to, so that this not dodgy.
Re: How do you get comfortable with Dlang.org's Forum?
On Saturday, 24 February 2018 at 04:13:15 UTC, Johannes Loher wrote: There are Browser extensions gor this (e.g. https://chrome.google.com/webstore/detail/stylish-custom-themes-for/fjnbnpbmkenffdnngjfgmeleoegfcffe?hl=en) Hey. thanks for the tip. though..I just refuse to use chrome ;-) (in the 90's companies made their name for not being Microsoft. As Microsoft wanted to dominate the world. I wonder if that same situation exists now, except, now its not being Google). anyways... a quick search and I discovered something similar for firefox. so I might check that out. https://addons.mozilla.org/en-US/firefox/addon/stylish/
Re: Template Constraints
On Saturday, 24 February 2018 at 03:58:48 UTC, Jonathan M Davis wrote: Whether an implicit cast or an explicit cast makes more sense depends entirely on what the code is doing, but either way, the conversion needs to be forced inside the function, or you end up with bugs. Far too often, when someone has a template constraint that checks an implicit conversion, the function doesn't actually force the conversion, and that can do anything from resulting in some instantiations not compiling to causing subtle bugs due to the argument being used without being converted. In general, it's actually best to avoid conversions entirely with generic code and force the caller to do the conversion if a conversion is appropriate. But ultimately, what works best depends on what the code is trying to do. - Jonathan M Davis yeah it's hard to say much more without knowing what the code really wants to do..but presumably, you'd want to incorporate some contract programming in such a solution too, particulary given there's something potentially dodgy going on within such a function.
Re: Template Constraints
On Saturday, 24 February 2018 at 03:43:25 UTC, Jonathan M Davis wrote: That does not do what the OP requested at all. That tests whether T is one of byte, ubyte, short, ushort, int, uint, long, and ulong, whereas what the OP wants is to test whether T can be cast to int. - Jonathan M Davis yeah. I realised that after I had posted. I posted a more suitable response after that though (I hope), with the intention of leading the OP away from an explicit cast, towards an implicit cast.
Re: Template Constraints
On Saturday, 24 February 2018 at 03:30:45 UTC, psychoticRabbit
wrote:
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be
possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");
}
or this is probably more suitable ;-)
(should you really be using an explicity convert anyway?)
void testTemplate2(T)(T x) if (isImplicitlyConvertible!(T, int))
{
writeln(x, " is implicitly convertible to an int. yeah!");
}
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
import std.traits : isIntegral;
void testTemplate(T)(T x) if (isIntegral!T)
{
writeln(x, " is an integral. yeah!");
}
Re: Template Constraints
On Saturday, 24 February 2018 at 02:54:13 UTC, Jonathan wrote:
I am having trouble finding many useful explanations of using
template constraints beyond basic usage.
I would like to have a template constrant to enforce that a
type can be explicitly cast to another type:
void (T)(T t)
if (cast(int) T)//force `cast(int) T` to be possible
{
// Yay I know `t` can be cast to an `int`!
}
Is this possible?
I would have thought contracts would be ideal here?
https://dlang.org/spec/contracts.html
Re: Beta 2.079.0
On Friday, 23 February 2018 at 16:03:56 UTC, Aurélien Plazzotta
wrote:
Perhaps, we could use Backus-Naur notation, as it is already
widely known into formal documents all over the globe, like the
following:
import std.stdio, std.whatever{this, that}, std.somethingelse,
std.grr{wtf};
That is with curly brackets instead of square brackets like you
suggest :)
Yeah...again.. I'd prefer to not to have to think differently
about syntax, just for writing imports. That's why I'd prefer to
just think of them as arrays using D's array like syntax.
import std.stdio [writeln, write = cwrite, writefln],
std.whatever;
I'm not sufficiently motivated to do anything here anyway, as I
don't believe a case for change can really be justified - cause
how many imports can you realistically include on a single line
anyway?
The current way is just fine, and provides really good clarity
for what's going on.
But I would (and am) very, very motivated to oppose introduction
of an obscure, confusing, or foreign syntax.
The real motivator for the change, as i see it, seemed to be
related to thinking that the imports section was not really for
human consumption - which it not true at all. The second motivate
seemed to be related to saving a few keystrokes or line space.
Again, human consumption should take priority here in my view.
Anyway, the point is moot at this point - since the change is
being reversed and nobody seems motivated to push it again. Which
is just fine with me ;-)
