Do you know why Walter is currently working on this stuff? Is this an optimization? If it's an optimization, do you know why it is more important than implementing "scope" or an unpacking syntax for tuples?

https://github.com/D-Programming-Language/dmd/commit/fc4462b95307d5c31d4c0bcf830faf6686b0feae

If that's an optimization, and most people are going to use LDC or GDC in future, why is Walter working on that stuff?

Also do you know why Walter is working still on D1? Isn't D1 code going to be deleted, to have a purely D2 code on GitHub?

Currently there are 118 open pull requests:
https://github.com/D-Programming-Language/dmd/pulls

Maybe (probably) not every one of them is good, but among them there is lot of stuff I've asked in bug reports and enhancement requests, thanks to Hara and others. If 50% of the biggest pull requests of those 118 gets pulled, the D language will feel almost as a new thing.

Also, I don't agree a lot about the "fog of war" theory by Walter. I think a development plan should be discussed, written down, and then followed (and dynamically fixed, when necessary). Building a new system language has a high risk of failure, but there's no need to also shot D in the feet on purpose.

Bye,
bearophile

On Friday, 18 January 2013 at 20:21:47 UTC, bearophile wrote:
> Also, I don't agree a lot about the "fog of war" theory by Walter.

I must have missed that one, what's it about?

> I think a development plan should be discussed, written down, and then followed (and dynamically fixed, when necessary). Building a new system language has a high risk of failure, but there's no need to also shot D in the feet on purpose.
>

Yes, a plan is sorely lacking. Also the language specification can be much  better managed. For example, there's no clear plan for it, no clear revision history, discussions for improvements are made but then get lost or forgotten, etc. If it were better managed, many advantages become apparent, such as being able to link a particular release of the compiler to a specific revision of the language that the compiler supports, but that's just one benefit. The limited resources can be more focused on fixing specific parts of the compiler because that specific area was made a priority. What's the priority right now? I don't know, and that's not sending a confidence inspiring message to the people who are thinking about taking a risk and using D.

On the positive side, we have seen a recent improvement with the rolling out of a defined development and release process. Some of the details are still being sorted out, but it is a;ready huge improvement and may help kick start more of the same thing. We just need to keep working towards expanding the process to include other areas of D development.

--rt

Me and many others consider D as consistent, free and clever replacement for screwed(IMHO) C++. From that perspective the current design of D already has necessary things. I would like developers to focus on fixing issues and polishing everything rather than trying to implement something new and experimental.

The most common suggestions raises such problems as:

- the garbage collecting system (the ability to control and implement manual collectors or, at least, improve the precise and speed of the current);
- efficient and comfortable handling of dynamic libraries;
- extending standard library, because it lacks of many modules (containers, xml parser), more developed OS support and wrappers for popular libs;
- user defined operators (including support for unicode math stuff).

I'm not saying about production instruments, like IDEs, static code analyzers, debuggers.

I'm now still on 2.060 release, and I was shocked when suddenly have discovered that member visibility and access attributes just don't work! Well, 2060 release, and I can easily compile such thing:

struct MyStruct {
   private int a;
}

MyStruct ms;
ms.a = 42; //!!!
writeln(ms.a);

So, when you observe this situation, it becomes really hard to pursue fully fledged commercial development with D.

I love D and I hate C++. But I still need to code on C/C++ for food.

Anyway, cheers everybody. Hope one day to see D as leading and very efficient world-wide platform.

On 1/18/2013 2:16 PM, Andrey wrote:
> I'm now still on 2.060 release, and I was shocked when suddenly have discovered
> that member visibility and access attributes just don't work! Well, 2060
> release, and I can easily compile such thing:
>
> struct MyStruct {
>     private int a;
> }
>
> MyStruct ms;
> ms.a = 42; //!!!
> writeln(ms.a);


This is by design, not a bug. All code in a module has access to all private members in that same module. This obviates the need for the C++ "friend" declarations.

On 1/18/13 3:21 PM, bearophile wrote:
> Do you know why Walter is currently working on this stuff? Is this an
> optimization? If it's an optimization, do you know why it is more
> important than implementing "scope" or an unpacking syntax for tuples?
>
> https://github.com/D-Programming-Language/dmd/commit/fc4462b95307d5c31d4c0bcf830faf6686b0feae
>
>
> If that's an optimization, and most people are going to use LDC or GDC
> in future, why is Walter working on that stuff?
>
> Also do you know why Walter is working still on D1? Isn't D1 code going
> to be deleted, to have a purely D2 code on GitHub?
>
> Currently there are 118 open pull requests:
> https://github.com/D-Programming-Language/dmd/pulls
>
> Maybe (probably) not every one of them is good, but among them there is
> lot of stuff I've asked in bug reports and enhancement requests, thanks
> to Hara and others. If 50% of the biggest pull requests of those 118
> gets pulled, the D language will feel almost as a new thing.
>
> Also, I don't agree a lot about the "fog of war" theory by Walter. I
> think a development plan should be discussed, written down, and then
> followed (and dynamically fixed, when necessary). Building a new system
> language has a high risk of failure, but there's no need to also shot D
> in the feet on purpose.

I agree with the sentiment but let's not use oblique rhetorical questions to drive a point.

Allow me to extend again the invitation to participate to the development by contributing code. Put another way: Do you know why bearophile asks rhetorical questions instead of pushing to github?


Andrei

On Fri, Jan 18, 2013 at 05:43:16PM -0500, Andrei Alexandrescu wrote:
> On 1/18/13 3:21 PM, bearophile wrote:
[...]
> I agree with the sentiment but let's not use oblique rhetorical questions to drive a point.
> 
> Allow me to extend again the invitation to participate to the development by contributing code. Put another way: Do you know why bearophile asks rhetorical questions instead of pushing to github?
[...]

I have to say, after my initial euphoria upon discovering just how awesome D is, I did stumble across a number of very frustrating issues in the current implementation. I also found the slow rate of bug fixes rather frustrating (from my biased POV, of course -- I was looking for *my* bugs to be fixed, regardless of how many other bugs were being fixed). So I thought, I have three choices: (1) give up on D and go back to C++ (that was a pretty quick "no"), (2) post vitriol to the mailing list, increasing the likelihood of offending the devs and reducing the likelihood of my bugs getting fixed, or (3) fix the bug myself and submit a pull request to show 'em how it's done (greatly increases the likelihood of my bugs getting fixed, and faster at that).

I concluded that (3) was the most profitable approach, and that if enough others arrive at the same conclusion, we will stand a good chance of actually improving the situation. I'm a big fan of showing others how to do things better when I see something less than satisfactory.


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.

>> MyStruct ms;
>> ms.a = 42; //!!!
>> writeln(ms.a);
>
>
> This is by design, not a bug. All code in a module has access to all private members in that same module. This obviates the need for the C++ "friend" declarations.

Wikipedia states:

«In general, encapsulation is one of the 4 fundamentals of OOP (object-oriented programming). Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use.»

So how am I supposed to hide the variable inside the struct or class? I don't want anything to access it outside struct definition. And I don't see any point in giving the opportunity to access it using "friend" invitation. I'm sure "friend" explodes the basics of OOP encapsulation mechanics.

Struct is an «container» that owns its declarations and use special word for this: private. Then comes completely another data structure and can easily manipulate private members of another. Only imagine the other man from the neighbor house comes into your house and take your children without asking only because he lives on the same street.

On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
> So how am I supposed to hide the variable inside the struct or class?

Generally the D answer here is to put them in separate files. The module (file) is the main D encapsulation unit rather than the class/struct.

It isn't the same as C++ but I find it works pretty well - you often do one file per class anyway, and files are a natural unit for encapsulating too.

> I'm sure "friend" explodes the basics of OOP encapsulation mechanics.

http://www.parashift.com/c++-faq/friends-and-encap.html

If you have helper structures it can be useful to get at the private parts anyway, for example an iteration range.

On Saturday, 19 January 2013 at 00:11:03 UTC, Adam D. Ruppe wrote:
> On Saturday, 19 January 2013 at 00:04:24 UTC, Andrey wrote:
>> So how am I supposed to hide the variable inside the struct or class?
>
> Generally the D answer here is to put them in separate files. The module (file) is the main D encapsulation unit rather than the class/struct.
>
> It isn't the same as C++ but I find it works pretty well - you often do one file per class anyway, and files are a natural unit for encapsulating too.
>
>> I'm sure "friend" explodes the basics of OOP encapsulation mechanics.
>
> http://www.parashift.com/c++-faq/friends-and-encap.html
>
> If you have helper structures it can be useful to get at the private parts anyway, for example an iteration range.

Are nested classes quite more perfectly suited for this? In my containers I implement iterator interface using nested class. Then I can easily construct mycontainer.new Iterator and have (should have by theory) access to protected (not private) members. Also I will be ensured that this is a proper iterator and that it can be constructed only when I have the instantiated parent container.

And after that D forces you to restrict access not via default language construct, but via having one declaration per file. I think this is a not correct. In OOP concept you don't have such thing as a file or module. There are no files, there is ONE program with multiple data structures and hierarchies, united under one super root. Well, at least, that is how this supposed to work from the start.

«Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.» Alan Key.

> «Actually I made up the term "object-oriented", and I can tell you I did not have C++ in mind.» Alan Key.

Kay, of course. Alan Curtis Kay. Sorry for my english. :-)