www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Focus

reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jan 18 2013
next sibling parent reply "Rob T" <alanb ucora.com> writes:
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
Jan 18 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 18 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2013 4:55 PM, Andrey wrote:
 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.

This all falls apart once you decide you need "friend" access.
Jan 18 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/18/2013 6:50 PM, Andrey wrote:
 And for that reason we have a simple helper "friend" in C++.

C++ friends are quite complex and are a giant pain. D's method of everything in a module being implicitly a friend has been working very well for 10 years now.
Jan 18 2013
prev sibling next sibling parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.01.2013 03:50, schrieb Andrey:
 This all falls apart once you decide you need "friend" access.

I haven't seen such situations yet. According to OOP concept they must be very rare, so I tend to consider them more of architecture and logic mistake (and C++ is one big architecture and logic frankenstein).

In .NET languages this is internal access. In JVM languages, package default access. So there is a need for such features. -- Paulo
Jan 19 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-19 03:50, Andrey wrote:

 I haven't seen such situations yet. According to OOP concept they must
 be very rare, so I tend to consider them more of architecture and logic
 mistake (and C++ is one big architecture and logic frankenstein).

In theory and according to the OOP concept they might not be needed but when it comes to actually implement a OO concept it can turn out to be handy to have. That is, accessing a private member in the same module. -- /Jacob Carlborg
Jan 19 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.01.2013 16:26, schrieb Jacob Carlborg:
 On 2013-01-19 03:50, Andrey wrote:

 I haven't seen such situations yet. According to OOP concept they must
 be very rare, so I tend to consider them more of architecture and logic
 mistake (and C++ is one big architecture and logic frankenstein).

In theory and according to the OOP concept they might not be needed but when it comes to actually implement a OO concept it can turn out to be handy to have. That is, accessing a private member in the same module.

I do use it a lot when doing unit tests that check for side effects in the private data (JVM/.NET) of objects.
Jan 19 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 9:41 AM, Andrej Mitrovic wrote:
 On 1/21/13, deadalnix<deadalnix gmail.com>  wrote:
 Package have nothing to do with the private discussion that take
 place here.

It's completely relevant.

FWIW I think they are distinct issues. Andrei
Jan 21 2013
prev sibling next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/19/2013 01:04 AM, Andrey wrote:
 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.»

Even if this definition was accurate, note that it does not state what "unauthorized" means. Languages that implement OOP can (and do) vary in this aspect. Also, it goes on like: «So the public methods like getter and setter access it and the other classes call these methods for accessing.» Obviously the author of that sentence had no idea what encapsulation is about!
 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.

No it does not. "friend" attempts to work around the inexpressiveness of accessibility modifiers.
 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.

The module is the house, not the street. "Encapsulation" is sometimes applied (or pseudo-applied) at a way too small scale by programmers who do not understand it. It is not magic.
Jan 18 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 2:35 AM, Maxim Fomin wrote:
 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?

 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.

http://yosefk.com/c++fqa/friend.html#fqa-14.2

I think that's a rather poor piece. Andrei
Jan 19 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 8:21 AM, Maxim Fomin wrote:
 How much chances does this program have?
 ----------mylib.di--------
 class A
 {
 public int i;
 }

 void foo(A a);
 ---------mylib.d---------
 class A
 {
 public int i;
 private int ii;
 }

Looks like an ODR violation, but oddly there's nothing stopping us from making this work. It's a good idea to pursue. Andrei
Jan 19 2013
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 9:23 AM, Maxim Fomin wrote:
 On Saturday, 19 January 2013 at 13:57:02 UTC, Andrei Alexandrescu wrote:
 On 1/19/13 8:21 AM, Maxim Fomin wrote:
 How much chances does this program have?

from making this work. It's a good idea to pursue. Andrei

Unfortunately, this will never work in general. That code runs because private member was placed after public and because _d_new_class got "right" Typeinfo (compiled from mylib, not from main). If a private member is placed before a public one, than this will lead to troubles because dmd just generates (wrong) offsets from base pointer. What I wanted to say is that in D private members should be included in declaration in general case (sometimes the opposite may work by chance) which partly defeats encapsulation. For example, if you make changes in class which affects order of private members, you have to recompile all code which uses that class. That is a poor encapsulation.

I knew where you were driving. These are well-known tradeoffs. More robust modularity could be achieved at the expense of good layout. I was saying it would be interesting if we could allow better hiding in select cases (like the one in the example). Andrei
Jan 19 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:
 On 1/19/13 8:21 AM, Maxim Fomin wrote:
 How much chances does this program have?
 ----------mylib.di--------
 class A
 {
 public int i;
 }

 void foo(A a);
 ---------mylib.d---------
 class A
 {
 public int i;
 private int ii;
 }

Looks like an ODR violation, but oddly there's nothing stopping us from making this work. It's a good idea to pursue.

It can only work if the user is very well aware of how classes are laid out, avoids things that depend on the instance size, etc.
Jan 19 2013
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/19/13 1:36 PM, Walter Bright wrote:
 On 1/19/2013 5:57 AM, Andrei Alexandrescu wrote:
 On 1/19/13 8:21 AM, Maxim Fomin wrote:
 How much chances does this program have?
 ----------mylib.di--------
 class A
 {
 public int i;
 }

 void foo(A a);
 ---------mylib.d---------
 class A
 {
 public int i;
 private int ii;
 }

Looks like an ODR violation, but oddly there's nothing stopping us from making this work. It's a good idea to pursue.

It can only work if the user is very well aware of how classes are laid out, avoids things that depend on the instance size, etc.

Well I'm thinking of scenarios in which the implementation file imports and verifies the incomplete declaration file. Andrei
Jan 19 2013
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/21/13 7:49 AM, eles wrote:
 Why make access protection dependent of how the source code is spread
 into files?

For the simple reason that files are the de facto unit of encapsulation for viewing and editing. Andrei
Jan 21 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
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.
Jan 18 2013
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Jan 18 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 18 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
 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.
Jan 18 2013
prev sibling next sibling parent "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jan 18 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
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.
Jan 18 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
 «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. :-)
Jan 18 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
 This all falls apart once you decide you need "friend" access.

I haven't seen such situations yet. According to OOP concept they must be very rare, so I tend to consider them more of architecture and logic mistake (and C++ is one big architecture and logic frankenstein). Once again, in D you have active nested classes that can automatically reference parent and this allows very nice and accurate compositions. So the need for separate small supporting class is eliminated, because it integrates into its parent. Moreover, you preserve very well the "program with interface" idiom. For example, you have a List container and a Array container. Then you have general iterator interface. interface iIterator {...} class List { class Iterator : iIterator {specific implementation} } class Array { class Iterator : iIterator {another specific implementation} } And then you can switch between two containers easily preserving the rest of code: List.new Iterator <-> Array.new Iterator; Of course, you can make this work by having two different factory functions returning proper iterator implementation for class. class List { iIterator constructIterator() { return new ListIterator(this); } } But this is artificial, speculative, not language feature. Compiler still can't figure out any bond shared between classes. And for that reason we have a simple helper "friend" in C++. D understands the hierarchy, but for unknown reason refuses to take full advantage of this feature. And we could use it to establish concrete and specific links instead of outer module wrapper container. Well, I don't want to force any changes. Just trying to better understand D. This became off-topic.
Jan 18 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 19 January 2013 at 03:40:35 UTC, Walter Bright wrote:
 On 1/18/2013 6:50 PM, Andrey wrote:
 And for that reason we have a simple helper "friend" in C++.

C++ friends are quite complex and are a giant pain. D's method of everything in a module being implicitly a friend has been working very well for 10 years now.

That is also the way to go IMO. The usual definition of encapsulation is way too much object centric. In many language, you'll find out that a class == a module (or pretty much in practice). This don't fit at all multi-paradigm, where D does pretty well.
Jan 18 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
 That is also the way to go IMO.

 snip

This isn't directed at you, or any other poster for that matter (I am to technically inept to figure out how to post to the thread other than using the 'reply' feature)... Anyway, just wanted to say that this thread got off topic in an awful hurry.
Jan 18 2013
prev sibling next sibling parent "Craig Dillabaugh" <cdillaba cg.scs.carleton.ca> writes:
 snip

 Anyway, just wanted to say that this thread got off topic in an
 awful hurry.

It sort of funny that the thread started off with a complaint about Walters lack of focus and quickly got off topic. Maybe lack of focus is a common attribute of people interested in D. I suggested that D be renamed the ADD language.
Jan 18 2013
prev sibling next sibling parent Miles Stoudenmire <miles.stoudenmire gmail.com> writes:
Here is a helpful discussion on stack overflow about whether friend in
C++ breaks encapsulation:
http://stackoverflow.com/questions/1093618/how-does-the-friend-keyword-class-function-break-encapsulation-in-c

Also an article on encapsulation by Scott Meyers:
http://www.drdobbs.com/cpp/how-non-member-functions-improve-encapsu/184401197

Basically I think the consensus is that encapsulation != everything is
private. Also I like Meyer's point that encapsulation is a means, not
an end.



On 18 January 2013 20:11, Craig Dillabaugh <cdillaba cg.scs.carleton.ca> wrote:
 snip


 Anyway, just wanted to say that this thread got off topic in an
 awful hurry.

It sort of funny that the thread started off with a complaint about Walters lack of focus and quickly got off topic. Maybe lack of focus is a common attribute of people interested in D. I suggested that D be renamed the ADD language.

-- -=Miles Stoudenmire=- miles.stoudenmire gmail.com estouden uci.edu http://itensor.org/miles/
Jan 18 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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?

 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.

http://yosefk.com/c++fqa/friend.html#fqa-14.2 Unfortunately this applies to D in some kind of speaking.
Jan 18 2013
prev sibling next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Saturday, 19 January 2013 at 02:50:35 UTC, Andrey wrote:
 This all falls apart once you decide you need "friend" access.

I haven't seen such situations yet. According to OOP concept they must be very rare, so I tend to consider them more of architecture and logic mistake (and C++ is one big architecture and logic frankenstein).

Sorry for being a little harsh, but there's a big warning sign on the Overview page of this site: Who D is Not For: Language purists. D is a practical language, and each feature of it is evaluated in that light, rather than by an ideal. All of this stuff about pure (or true) OOP concept, when you just don't need such hacks as "friend" is good on paper. But most of the time it's very expensive to stick with such kind of purity rigorously. Or even is just a completely bad idea. Consider algorithms for data structures being members in true-OO vs. STL/D-ranges approach or everything is a function with no side-effects in "pure" functional languages.
Jan 19 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

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

Those questions aren't fully rhetorical because I don't know those answers and I'd like to know. I don't know why Walter thinks removing bit intrisics is more urgent than working on designing/implementing "scope" or similar things, I don't know why D1 development isn't discontinued yet (and I don't know why the pull requests are merged according to a mostly LIFO pattern), and so on.
 Allow me to extend again the invitation to participate to the 
 development by contributing code.

Given the many factors in this equation, I think my time is better spent elsewhere, teaching D to people in Real Life, showing D solutions to people in sites (like: reddit.com/r/dailyprogrammer/ ), writing D examples/tutorials in various sites, etc, because there's no point in creating a language that no one knows about. This page shows many missing D programs, I invite people here to fill some of those blanks: http://rosettacode.org/wiki/Reports:Tasks_not_implemented_in_D Bye, bearophile
Jan 19 2013
prev sibling next sibling parent reply Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
[=E2=80=A6]
 If that's an optimization, and most people are going to use LDC=20
 or GDC in future, why is Walter working on that stuff?

Working on a separate backend is fine if that is what people want to do. I think though that unless D sits on GCC or LLVM it will get no traction. D has been going for 10 years now and is still a tiny niche language that large organization don't consider given C and C++. Riding on GCC and LLVM and being everywhere that gcc, g++ and clang are is a step to allowing D to be used by people not in this mailing list related community. This D development community should put effort into making GDC and LDC the primary D tools, ensuring that the latest D version is always shipped on Mac OS X (macports, brew, DMG installer,=E2=80=A6) and in every = Linux distro that has market presence =C2=AD=E2=80=93 which effectively means Deb= ian and Fedora since all distros with presence build on them =E2=80=93 as well as Windows (which bizarrely remains the major platform for software development). This is not something it has to be left to Walter to do unless D is to remain a 1-man band, in which case it will never get real traction: any toolchain which even remotely looks like a one-man band has no chance of getting real traction.
 Also do you know why Walter is working still on D1? Isn't D1 code=20
 going to be deleted, to have a purely D2 code on GitHub?

Having declared D1 dead as of 2012-12-31 and issued a final release, any and all work on D1 is counterproductive. But on the other hand Walter is not an employee of the D development team (**).
 Currently there are 118 open pull requests:
 https://github.com/D-Programming-Language/dmd/pulls
=20
 Maybe (probably) not every one of them is good, but among them=20
 there is lot of stuff I've asked in bug reports and enhancement=20
 requests, thanks to Hara and others. If 50% of the biggest pull=20
 requests of those 118 gets pulled, the D language will feel=20
 almost as a new thing.

Anyone and everyone can work on these bug reports. The problem is that D need a few people, not just one, to be paid in some way to work of the D system. Whilst all effort is basically on a volunteer basis then the project will just trundle along going nowhere. D needs some big users who put resource into development either in terms of cash to get contractors to do work, or by putting staff members onto the project for some or all of their time. Only with commitment of resource from user organizations will the project actually go anywhere.
 Also, I don't agree a lot about the "fog of war" theory by=20
 Walter. I think a development plan should be discussed, written=20
 down, and then followed (and dynamically fixed, when necessary).=20
 Building a new system language has a high risk of failure, but=20
 there's no need to also shot D in the feet on purpose.

I am not sure what this theory is but it sounds akin to "let the product be an emergent property of chaotic behaviour". It strikes me that the DConf 2013 shouldn't be just a friendly get together to share some D knowledge. This conference should be the meeting that kicks off the programme of D's ascendency into the realms of actually being used seriously. 1. It needs to be clear that D is no longer Walter's baby/toy/=E2=80=A6 th= at only he can work on. 2. There needs to be a roadmap of creating a language spec, a test suite for all the features, and a programme for any future features and how they will be implemented. 3. A marketing programme to get D known about and used. This hinges on successful projects so an objective would be to get an up to date list of products, both small and large, that rely on D and why they use D and not C, C++, Java, Scala, etc. 4. Networking to find organizations who may be able to put real resource into the D infrastructure and libraries. 5. Find a big organizational champion (*). If the D world is after DConf 2013 fundamentally the same as the D world has been before DConf 2013 then the project is going nowhere and the only recourse will be to fighting with C++, Go, Rust, Clay, etc. DConf 2013 has to be treated as a watershed moving D from the 10 year cycle of creation into the infinite cycle of use. (*) Groovy managed to use a 6 year rather than 10 cycle to real usability, but it was only when SpringSource bought G2One and started putting resource into Groovy that it really took off. With Canoo backing it and one or two USA consultancies, it rapidly became the dynamic language of choice and actual use on the JVM. The similarities between D evolution and Groovy evolution are quite interesting (**). Groovy has made the jump to organizational respectability. D needs to do the same. (**) Groovy had a development team crisis/explosion/implosion not dissimilar to the Tango/Phobos situation. But the Groovy team moved on. It seems the D situation has become history and people have moved on. The crucial difference is that the Groovy team started looking outwards from the language as much as looking at the development of the language. The D community needs to look out towards use of the language out there rather than just the language infrastructure. Vibe.d is something Twitter and G+ should be full of. Should there be effort of graphics bindings? Network bindings, etc. But what are the applications using these? That is where the real traction stems from. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 19 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 19.01.2013 14:19, schrieb Freddie Chopin:
 On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
 This D development community should put effort into making GDC and LDC
 the primary D tools

For example Go (developed since 2009) is already integrated with GCC (since 4.6.3 so for some time)... I know that it's google and stuff, but I tend to agree with this thread on general - GCC support would possibly open D for a market really hungry for a new and powerful language - embedded (microcontrollers, not smartphones with Linux). And there's no competition - just C/C++ (; 4\/3!!

Yes, but you forget that one of the GCC developers is also part of the Go developers team. -- Paulo
Jan 19 2013
prev sibling next sibling parent "Freddie Chopin" <freddie_chopin op.pl> writes:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
 This D development community should put effort into making GDC 
 and LDC
 the primary D tools

For example Go (developed since 2009) is already integrated with GCC (since 4.6.3 so for some time)... I know that it's google and stuff, but I tend to agree with this thread on general - GCC support would possibly open D for a market really hungry for a new and powerful language - embedded (microcontrollers, not smartphones with Linux). And there's no competition - just C/C++ (; 4\/3!!
Jan 19 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 19 January 2013 at 13:12:32 UTC, Andrei Alexandrescu 
wrote:
 On 1/19/13 2:35 AM, Maxim Fomin wrote:
 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?

 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.

http://yosefk.com/c++fqa/friend.html#fqa-14.2

I think that's a rather poor piece. Andrei

How much chances does this program have? ----------mylib.di-------- class A { public int i; } void foo(A a); ---------mylib.d--------- class A { public int i; private int ii; } void foo(A a) { if (a !is null) { a.ii = 2; } } ---------main.d--------- import mylib; void main() { A a = new A; a.foo(); } ------------------------ # dmd main.d -c # dmd mylib.d -c # gcc main.o mylib.o -lrt -lphobos2 -lpthread # ./a.out ?
Jan 19 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Saturday, 19 January 2013 at 13:57:02 UTC, Andrei Alexandrescu 
wrote:
 On 1/19/13 8:21 AM, Maxim Fomin wrote:
 How much chances does this program have?

us from making this work. It's a good idea to pursue. Andrei

Unfortunately, this will never work in general. That code runs because private member was placed after public and because _d_new_class got "right" Typeinfo (compiled from mylib, not from main). If a private member is placed before a public one, than this will lead to troubles because dmd just generates (wrong) offsets from base pointer. What I wanted to say is that in D private members should be included in declaration in general case (sometimes the opposite may work by chance) which partly defeats encapsulation. For example, if you make changes in class which affects order of private members, you have to recompile all code which uses that class. That is a poor encapsulation.
Jan 19 2013
prev sibling next sibling parent "Andrey" <andr-sar yandex.ru> writes:
 In theory and according to the OOP concept they might not be 
 needed but when it comes to actually implement a OO concept it 
 can turn out to be handy to have. That is, accessing a private 
 member in the same module.

Allright. But I don't see a reason why this coudln't be done with nested classes. If some class wants frequently to access parent's members, then it preferably demands constant reference to it and therefore need to be presented as inner class. Then we can better and more intelligently track the existence and cooperation of both classes. And, as it was said, there is no actual encapsulation unless you have organized runtime access checks to the memory chunk occupied by an object. Maybe the creators of D can implement this using contract programming or other things, I do not know. But this can be really a huge step towards safety. The real effect may be seen if the whole OS is written in object oriented manner, and its processes and services have the built-in hierarchical access policy. Such architecture makes possible natural cooperation between various core modules, processes and the user space. Maybe even existence in one address space without the need of slow artificial system calls. If someone wants to continue discussing OOP, then I suggest to move to another thread to stop polluting this topic. Although I think that there are enough debates around OOP in the Internet already and yet another one will not make difference.
Jan 19 2013
prev sibling next sibling parent "SomeDude" <lovelydear mailmetrash.com> writes:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
 On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
 […]
 (*) Groovy managed to use a 6 year rather than 10 cycle to real
 usability, but it was only when SpringSource bought G2One and 
 started
 putting resource into Groovy that it really took off. With 
 Canoo backing
 it and one or two USA consultancies, it rapidly became the 
 dynamic
 language of choice and actual use on the JVM.  The similarities 
 between
 D evolution and Groovy evolution are quite interesting (**). 
 Groovy has
 made the jump to organizational respectability. D needs to do 
 the same.

This opinionated piece of opinion agrees: "What about D as a replacement for C? It's not there for the same reasons as Go. It's possible that someday it will be suitable, but I'm less optimistic about it strictly from a momentum perspective, it doesn't have a big backer like Google and doesn't seem to be growing very rapidly. But perhaps it will get there someday." http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html
Jan 19 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Saturday, 19 January 2013 at 18:43:45 UTC, SomeDude wrote:
 On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder 
 wrote:
 On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
 […]
 (*) Groovy managed to use a 6 year rather than 10 cycle to real
 usability, but it was only when SpringSource bought G2One and 
 started
 putting resource into Groovy that it really took off. With 
 Canoo backing
 it and one or two USA consultancies, it rapidly became the 
 dynamic
 language of choice and actual use on the JVM.  The 
 similarities between
 D evolution and Groovy evolution are quite interesting (**). 
 Groovy has
 made the jump to organizational respectability. D needs to do 
 the same.


Yes. I remember looking at Groovy around 2000 timeframe and not giving too much consideration. Back then Jacl had much more support, and IBM was pushing Beanshell and Jacl. Funny how it turned out to be.
 This opinionated piece of opinion agrees:

 "What about D as a replacement for C?

 It's not there for the same reasons as Go. It's possible that 
 someday it will be suitable, but I'm less optimistic about it 
 strictly from a momentum perspective, it doesn't have a big 
 backer like Google and doesn't seem to be growing very rapidly. 
 But perhaps it will get there someday."

 http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html

Go might eventually succeed in replacing C, Google just needs to make Go a first class language for Android development. -- Paulo
Jan 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:
 Go might eventually succeed in replacing C, Google just needs 
 to make Go a first class language for Android development.

Go has no chance to replace C as too many low level features are missing. But yes, it can become pretty big !
Jan 21 2013
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
[=E2=80=A6]
 Yes. I remember looking at Groovy around 2000 timeframe and not=20
 giving
 too much consideration.

Just to ensure the history as determined by Google search is at least fairly reasonable, Groovy started in mid to late 2003 had a hiccup mid 2004, and really got moving in late 2004. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
 On 1/18/2013 2:16 PM, Andrey wrote:

 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.

Yes, but that is a bad choice. The simplest argument against it it is that it is a departure of C++. Yes, you've made "private" like Java (package), but that's not the first intended audience. If you cannot go back with private acting like C++ private, then at least introduce an "internal" specifier for things that truly belongs to the class only (ie: the C++ private). You could have: internal private package protected public export or private semiprivate // well? better ideas? package protected public export Why make access protection dependent of how the source code is spread into files?
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright wrote:
 On 1/18/2013 4:55 PM, Andrey wrote:
 This all falls apart once you decide you need "friend" access.

What is wrong with this POV is that the original class no longer has a word to say if she wants to be friended by someone. In C++ the class has a word to say: if it does not declare: "hey! you will be my friend!", then nobody can come there to say: "hey! I consider myself your friend (even if you don't want it), so I will mess up your internal state!"
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Saturday, 19 January 2013 at 11:52:52 UTC, Russel Winder wrote:
 On Fri, 2013-01-18 at 21:21 +0100, bearophile wrote:
 […]
 This D development community should put effort into making GDC 
 and LDC
 the primary D tools, ensuring that the latest D version is 
 always

I second that.
Jan 21 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 21 January 2013 at 10:42:17 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 08:34:49 UTC, Paulo Pinto wrote:
 Go might eventually succeed in replacing C, Google just needs 
 to make Go a first class language for Android development.

Go has no chance to replace C as too many low level features are missing. But yes, it can become pretty big !

That is debatable, as most things are possible via unsafe + syscall. Already proven in another GC enabled system languages. That the industry needs to have them shoved by their throat like in Java's case, that is another matter. -- Paulo
Jan 21 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 21 January 2013 at 12:31:16 UTC, Russel Winder wrote:
 On Mon, 2013-01-21 at 09:34 +0100, Paulo Pinto wrote:
 […]
 Yes. I remember looking at Groovy around 2000 timeframe and 
 not giving
 too much consideration.

Just to ensure the history as determined by Google search is at least fairly reasonable, Groovy started in mid to late 2003 had a hiccup mid 2004, and really got moving in late 2004.

Yeah, it might have been 2003. I have written "around 2000", because I wasn't sure when exactly. This was the time when Groovy was supposed to be made part of Java. Ok, it was JSR-241, http://www.jcp.org/en/jsr/detail?id=241 I got the date wrong by 4 years it seems. -- Paulo
Jan 21 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
 On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright 
 wrote:
 On 1/18/2013 4:55 PM, Andrey wrote:
 This all falls apart once you decide you need "friend" access.

What is wrong with this POV is that the original class no longer has a word to say if she wants to be friended by someone. In C++ the class has a word to say: if it does not declare: "hey! you will be my friend!", then nobody can come there to say: "hey! I consider myself your friend (even if you don't want it), so I will mess up your internal state!"

Only if that class is in the same module. This is being blown completely out of proportion. A few things to consider: - Lots of languages don't have access control at all, yet somehow people use them without problem. - As far as I can see, the DMD source has very few private variables, yet very few (if any) bugs are caused by people messing up other people's variables. - If you have one class per module, D is no different to C++/Java/C#.
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander wrote:
 On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
 On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright 
 wrote:
 On 1/18/2013 4:55 PM, Andrey wrote:


somehow people use them without problem.

Lots of languages do not even have classes. Lots of languages do not even have functions. Lots of languages are... assembler.
 - As far as I can see, the DMD source has very few private 
 variables, yet very few (if any) bugs are caused by people 
 messing up other people's variables.

In the beginning, C++ programs had very few bugs. Then, real coding in C++ happened. BTW, DMD (not phobos) source is C++ (https://github.com/D-Programming-Language/dmd/blob/master/src/arrayop.c), not D.
 - If you have one class per module, D is no different to 
 C++/Java/C#.

Yes... And if you define: struct var *p2=new_from_data(p1->a, p1->b, p1->c); then you have a copy constructor... Straight, isn't?
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 13:32:35 UTC, eles wrote:
 On Monday, 21 January 2013 at 13:16:03 UTC, Peter Alexander 
 wrote:
 On Monday, 21 January 2013 at 12:55:36 UTC, eles wrote:
 On Saturday, 19 January 2013 at 01:35:58 UTC, Walter Bright 
 wrote:
 On 1/18/2013 4:55 PM, Andrey wrote:



coding in C++ happened. BTW, DMD (not phobos) source is C++ (https://github.com/D-Programming-Language/dmd/blob/master/src/arrayop.c), not D.

BTW, Walter, pls take a moment and change the extension of those files from .c to .cpp.
Jan 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright wrote:
 On 1/18/2013 2:16 PM, Andrey wrote:

 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.

Yes, but that is a bad choice. The simplest argument against it it is that it is a departure of C++. Yes, you've made "private" like Java (package), but that's not the first intended audience. If you cannot go back with private acting like C++ private, then at least introduce an "internal" specifier for things that truly belongs to the class only (ie: the C++ private). You could have: internal private package protected public export or private semiprivate // well? better ideas? package protected public export Why make access protection dependent of how the source code is spread into files?

What would be the point ? You'll have the implementation and the function definition under the nose anyway as it is in the same file. If something should be private from your code, what is your code doing is the same module ?
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright 
 wrote:
 On 1/18/2013 2:16 PM, Andrey wrote:


the function definition under the nose anyway as it is in the same file. If something should be private from your code, what is your code doing is the same module ?

1. Quoting Andrey's original post (3rd on this thread): "So, when you observe this situation, it becomes really hard to pursue fully fledged commercial development with D." So, if you think that D is so string that it allows itself such ingenuities that makes C++ programmers giving it a try to scream away from D, then fine. D already has difficulties in being accepted by corporations (and I thing that lack of gcc integration is the strongest difficulty). But, now, imagine that you present D in front of a bunch of hardened C++ programmers and you have to explain those already skeptikal people that thes should not scream when they see Andrey's originally posted code. It is not also about D's own way, D still has to make some compromises to be accepted. In 10 years, it will be, maybe, the reference. IT IS NOT TODAY. 2. That file/module could be really huge. Several succesive programmers working on the same file/module could be of various expertise levels and not aware of such subtleties. Refactoring means also moving a lot of code around and you will find yourself needed to go back to that file where the code was originally defined and modify the "private" into "package" if you still want your code to compile. As a rule, during refactoring, it is a bad thing to touch (or be needed to touch) other code than the one you are messing up with, be in the same source file or no.
Jan 21 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/21/13, Peter Alexander <peter.alexander.au gmail.com> wrote:
 This is being blown completely out of proportion.

I don't think so. Consider that currently it's impossible to hide any symbols from a user if they are located in subpackages. Which means you're forced to either put everything into the same package and use the package access specifier, or put everything into the same module. The problem I have with this is it makes it impossible to separate implementation-specific modules into their subpackages without giving access of these symbols to the user. Consider that the following would make a nice folder structure for a library: lib/gui.d lib/platform/win32/gui.d lib/platform/posix/gui.d Unfortunately everything in lib/platform must be public in order for gui.d to use it, and as a consequence user-code ends up having access to these platforms-specific implementation modules. You could move everything into the lib folder and use the package access specifier. That also means class methods must have package access to prevent the user from invoking them, but this automatically makes them non-virtual. Bottom line is, the module system and access specifiers can use some improvements. Language XYZ might do something in its own way, but D is a language of its own and we should feel free to innovate.
Jan 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:
 On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright 
 wrote:
 On 1/18/2013 2:16 PM, Andrey wrote:


the function definition under the nose anyway as it is in the same file. If something should be private from your code, what is your code doing is the same module ?

1. Quoting Andrey's original post (3rd on this thread): "So, when you observe this situation, it becomes really hard to pursue fully fledged commercial development with D." So, if you think that D is so string that it allows itself such ingenuities that makes C++ programmers giving it a try to scream away from D, then fine. D already has difficulties in being accepted by corporations (and I thing that lack of gcc integration is the strongest difficulty). But, now, imagine that you present D in front of a bunch of hardened C++ programmers and you have to explain those already skeptikal people that thes should not scream when they see Andrey's originally posted code. It is not also about D's own way, D still has to make some compromises to be accepted. In 10 years, it will be, maybe, the reference. IT IS NOT TODAY.

I don't really understand the logic here. That seems very confused to me.
 2. That file/module could be really huge. Several succesive 
 programmers working on the same file/module could be of various 
 expertise levels and not aware of such subtleties. Refactoring 
 means also moving a lot of code around and you will find 
 yourself needed to go back to that file where the code was 
 originally defined and modify the "private" into "package" if 
 you still want your code to compile. As a rule, during 
 refactoring, it is a bad thing to touch (or be needed to touch) 
 other code than the one you are messing up with, be in the same 
 source file or no.

That may happen. If it happen you'll have trouble; Actually enough trouble that I'm pretty sure that this private things will not be of any priority to your eyes. And your point around refactoring is kind of moot, because if you refactor big a module into smaller one, you are, by definition refactoring that module. And the code affected by the private thing IS, by definition of private, in that module. No need to mess around with other code. Some approach have been proposed to be able to refactor a module into a package, and that is probably a much more interesting way to go, as it solve a much broader range of issues.
Jan 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:
 On 1/21/13, Peter Alexander <peter.alexander.au gmail.com> 
 wrote:
 This is being blown completely out of proportion.

I don't think so. Consider that currently it's impossible to hide any symbols from a user if they are located in subpackages. Which means you're forced to either put everything into the same package and use the package access specifier, or put everything into the same module.

Package have nothing to do with the private discussion that take place here.
 The problem I have with this is it makes it impossible to 
 separate
 implementation-specific modules into their subpackages without 
 giving
 access of these symbols to the user. Consider that the 
 following would
 make a nice folder structure for a library:

 lib/gui.d
 lib/platform/win32/gui.d
 lib/platform/posix/gui.d

 Unfortunately everything in lib/platform must be public in 
 order for
 gui.d to use it, and as a consequence user-code ends up having 
 access
 to these platforms-specific implementation modules.

Ideally, package should allow this in a way or another.
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 14:29:32 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 14:06:49 UTC, eles wrote:
 On Monday, 21 January 2013 at 13:37:21 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 12:49:47 UTC, eles wrote:
 On Friday, 18 January 2013 at 22:29:45 UTC, Walter Bright 
 wrote:
 On 1/18/2013 2:16 PM, Andrey wrote:


the function definition under the nose anyway as it is in the same file. If something should be private from your code, what is your code doing is the same module ?

1. Quoting Andrey's original post (3rd on this thread):

confused to me.

Just think about Andrey as being such C++ programmer that gave D a try and ran away. Why? Because it was puzzled to see that, despit being "private", the attribute is "public" (well, to some degree). His first thought was that D should not be used into production environment. OK? Andrey is one C++ programmer that you lose, you cannot convert him to D. Does D afford that?
Jan 21 2013
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 1/21/13, deadalnix <deadalnix gmail.com> wrote:
 Package have nothing to do with the private discussion that take
 place here.

It's completely relevant.
Jan 21 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
 Just think about Andrey as being such C++ programmer that gave 
 D a try and ran away. Why? Because it was puzzled to see that, 
 despit being "private", the attribute is "public" (well, to 
 some degree).

 His first thought was that D should not be used into production 
 environment.

 OK? Andrey is one C++ programmer that you lose, you cannot 
 convert him to D. Does D afford that?

That is completely backward. D and C++ have very different needs in terms of visibility of symbols, especially if you think about the fact that namespace introduction in C++ come after visibility qualifiers. D have a module system that make the requirement very different. Every time you change something people are used too, they get scared. Someone scared by a change they don't understand will not use D anyway. Given another behavior of private more C++ compliant, it is very likely that Andrey would have find something else to be scared of.
Jan 21 2013
prev sibling next sibling parent "eles" <eles eles.com> writes:
On Monday, 21 January 2013 at 14:46:52 UTC, deadalnix wrote:
 On Monday, 21 January 2013 at 14:34:50 UTC, eles wrote:
 Every time you change something people are used too, they get 
 scared. Someone scared by a change they don't understand will 
 not use D anyway. Given another behavior of private more C++ 
 compliant, it is very likely that Andrey would have find 
 something else to be scared of.

The point is some changes are useless, to not say they are bad. If D modified the "private", I think better decisions would have been to rename it too (ie. into "D_special_meaning_of_private") Do not forget that D still needs to attract people from the C/C++ world. If you adress to them, at least be nice to them and do not scare them from the begining. Also, C++ done *some* things right and those should be kept. At least, when correcting the bad things in C++, do not mess them more than it is necessary. For me, for example, it is puzzling to see that the "private" meaning was modified, but kept the same name. I knew that Andrey's code is legal into D, still I find it unnatural and I understand his reaction. I had the same reaction. In order to demonstrate privateness in a Hello World before of students, do I really need to go with TWO files?
Jan 21 2013
prev sibling next sibling parent "mist" <none none.none> writes:
C++ does not have UFCS. It does matter.
Jan 21 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic wrote:
 Bottom line is, the module system and access specifiers can use 
 some
 improvements. Language XYZ might do something in its own way, 
 but D is
 a language of its own and we should feel free to innovate.

Yes modules can be improved considerably and made much more practical. For example, you should be able to specify in the module what components are to be exported to a DI interface file and in what form. Currently there's no control, and everything gets dumped in the DI, then you have to hand craft it to hide implementation details. If you want D to become more popular, you have to allow for the hiding of implementation details, and you have to make it simple for the programmer to do it. We could do much better with a road map of what needs to be done with priorities set. --rt
Jan 21 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 21 January 2013 at 19:43:15 UTC, Rob T wrote:
 On Monday, 21 January 2013 at 14:26:13 UTC, Andrej Mitrovic 
 wrote:
 Bottom line is, the module system and access specifiers can 
 use some
 improvements. Language XYZ might do something in its own way, 
 but D is
 a language of its own and we should feel free to innovate.

Yes modules can be improved considerably and made much more practical. For example, you should be able to specify in the module what components are to be exported to a DI interface file and in what form. Currently there's no control, and everything gets dumped in the DI, then you have to hand craft it to hide implementation details. If you want D to become more popular, you have to allow for the hiding of implementation details, and you have to make it simple for the programmer to do it. We could do much better with a road map of what needs to be done with priorities set.

I suggesting by starting to address any unargumented proposition to "make D more popular" to Dave Null. He'll be very happy to help.
Jan 21 2013