www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Adding Modules to C in 10 Lines of Code

reply Walter Bright <newshound2 digitalmars.com> writes:
https://nwcpp.org/

An online presentation.

Monday at 7PM PST.
Apr 17 2022
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 4/17/22 13:12, Walter Bright wrote:

 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.


(My earlier post disappeared.)

April 20 is Wednesday.

Ali
Apr 17 2022
parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2022 5:40 PM, Ali Çehreli wrote:

 On 4/17/22 13:12, Walter Bright wrote:

 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.


 
 (My earlier post disappeared.)
 
 April 20 is Wednesday.
 
 Ali


Gak! My bad. You're right.
Apr 17 2022
prev sibling next sibling parent user1234 <user1234 12.de> writes:
On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:

 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.


I thought to that when you made this, a few weeks ago, for 
importC: "that's 10 lines because module system is already backed 
by D system of scopes, symbol lookups(, etc.)"

For a pure C compiler, it would be more like 200 lines, right ?
Apr 19 2022
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:

 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.


Will there be a recording available?
Apr 19 2022
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Tuesday, 19 April 2022 at 12:41:18 UTC, jmh530 wrote:

 On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:

 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.


 Will there be a recording available?


Talks from past NWCPP meetups are on their YouTube channel here:

https://www.youtube.com/user/NWCPP/videos

I assume this one will be there, too.
Apr 19 2022
parent jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 19 April 2022 at 12:46:16 UTC, Mike Parker wrote:

 [snip]

 Talks from past NWCPP meetups are on their YouTube channel here:

 https://www.youtube.com/user/NWCPP/videos

 I assume this one will be there, too.


Thanks.
Apr 19 2022
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 4/19/2022 5:41 AM, jmh530 wrote:

 Will there be a recording available?


Yes. NWCPP routinely posts the video a few days later.
Apr 19 2022
prev sibling parent ezneh <petitv.isat gmail.com> writes:
On Tuesday, 19 April 2022 at 12:41:18 UTC, jmh530 wrote:

 On Sunday, 17 April 2022 at 20:12:38 UTC, Walter Bright wrote:

 https://nwcpp.org/

 An online presentation.

 Monday at 7PM PST.


 Will there be a recording available?


Here it is: https://www.youtube.com/watch?v=2ImfbGm0fls
Apr 22 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/17/2022 1:12 PM, Walter Bright wrote:

 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.


Slides:

https://nwcpp.org/talks/2022/modules_in_c.pdf

Video:

https://www.youtube.com/watch?v=2ImfbGm0fls
Apr 22 2022
next sibling parent Matheus <matheus gmail.com> writes:
Invidious instances:

https://invidious.flokinet.to/watch?v=2ImfbGm0fls
https://invidious.namazso.eu/watch?v=2ImfbGm0fls
https://vid.puffyan.us/watch?v=2ImfbGm0fls
https://inv.riverside.rocks/watch?v=2ImfbGm0fls
https://invidious.weblibre.org/watch?v=2ImfbGm0fls
https://yt.artemislena.eu/watch?v=2ImfbGm0fls
https://invidious.osi.kr/watch?v=2ImfbGm0fls

And much more: https://redirect.invidious.io/watch?v=2ImfbGm0fls

Matheus.
Apr 22 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:

 On 4/17/2022 1:12 PM, Walter Bright wrote:

 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.


 Slides:

 https://nwcpp.org/talks/2022/modules_in_c.pdf

 Video:

 https://www.youtube.com/watch?v=2ImfbGm0fls


Here is the answer to the 2 questions you posed in your 
presentation:
(1) why nobody has done this in 40 years?
(2) what went on with C++ for 20 years?

It's simple.

Rational choice theory tell us, that the reward of the action 
must outweigh the costs incurred.
May 02 2022
next sibling parent Jack <jckj33 gmail.com> writes:
On Tuesday, 3 May 2022 at 01:54:16 UTC, forkit wrote:

 On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:

 On 4/17/2022 1:12 PM, Walter Bright wrote:

 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.


 Slides:

 https://nwcpp.org/talks/2022/modules_in_c.pdf

 Video:

 https://www.youtube.com/watch?v=2ImfbGm0fls


 Here is the answer to the 2 questions you posed in your 
 presentation:
 (1) why nobody has done this in 40 years?
 (2) what went on with C++ for 20 years?

 It's simple.

 Rational choice theory tell us, that the reward of the action 
 must outweigh the costs incurred.


I don't quite get it, did you mean the C import isn't worth the 
cost?
May 27 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 3 May 2022 at 01:54:16 UTC, forkit wrote:

 On Friday, 22 April 2022 at 19:54:13 UTC, Walter Bright wrote:

 On 4/17/2022 1:12 PM, Walter Bright wrote:

 https://nwcpp.org/
 
 An online presentation.
 
 Monday at 7PM PST.


 Slides:

 https://nwcpp.org/talks/2022/modules_in_c.pdf

 Video:

 https://www.youtube.com/watch?v=2ImfbGm0fls


 Here is the answer to the 2 questions you posed in your 
 presentation:
 (1) why nobody has done this in 40 years?
 (2) what went on with C++ for 20 years?

 It's simple.

 Rational choice theory tell us, that the reward of the action 
 must outweigh the costs incurred.


Stepstone did it for Objective-C with #import, and Apple with 
module maps for C and Objective-C, the modules design that 
preceeded C++ modules on clang.

Then we have those failed attempts at fixing C like SafeC.

And if we count research work, Bjarne Stroustoup and Gabriel dos 
Reis, did it back when they were teaching in Texas university, 
here is the 2009 paper,

"A Principled, Complete, and Efficient Representation of C++"

https://www.stroustrup.com/gdr-bs-macis09.pdf

Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 
years ago, by serializing C++ code into database representation, 
both failed due to high hardware requirements for late 80's/early 
90's PCs.

Lucid Energize Demo in 1993

https://www.youtube.com/watch?v=pQQTScuApWk

Its database system, Cadillac,

"Foundation for a C++ Programming Environment"

https://dreamsongs.com/Files/Energize.pdf

Visual Age for C++ v4,

http://www.edm2.com/0704/vacpp4/vacpp4.html


 The build environment is totally different from traditional 
 compilers. The concept of header files and source code files is 
 obsolete. VAC++ utilizes a global approach to definitions and 
 implementations. That is, once a definition is processed it 
 stays in memory for the duration of the build. To maintain 
 compatibility, header files can still be #included. This new 
 approach to handling source code is disorienting at first and 
 will make migrating existing code to the compiler somewhat 
 difficult. Errors pertaining to objects being defined more than 
 once will likely occur while migrating. Often these errors are 
 incorrect. The work around is to remove the #include line in 
 the source file that contains the offending “redefinition”.


https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y#v=onepage&q&f=false

Additionally the way pre-compiled headers work on C++ Builder and 
Visual C++, versus the UNIX way, meant that on Windows the reward 
of the action did not outweigh the costs incurred, and ironically 
Visual C++ is the one leading the C++ modules support anyway, 
thanks to Gabriel dos Reis being part of the team, and pinging 
back on those 2009 learnings.
May 29 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 5/29/2022 11:13 PM, Paulo Pinto wrote:

 Stepstone did it for Objective-C with #import,


Not the same as C doing the importing of C code.


 and Apple with module maps for C 
 and Objective-C, the modules design that preceeded C++ modules on clang.
 
 Then we have those failed attempts at fixing C like SafeC.
 
 And if we count research work, Bjarne Stroustoup and Gabriel dos Reis, did it 
 back when they were teaching in Texas university, here is the 2009 paper,
 
 "A Principled, Complete, and Efficient Representation of C++"
 
 https://www.stroustrup.com/gdr-bs-macis09.pdf


Going around the horn, really doing it the hard way. Besides, writing a paper
is 
not the same thing as implementing a working system. There were many proposals 
about adding modules to C, they just all went nowhere.



 Both Visual Age for C++ v0.4 and Lucid's Energize C++ did 40 years ago, by 
 serializing C++ code into database representation, both failed due to high 
 hardware requirements for late 80's/early 90's PCs.


Yee gods, doing it with a database representation is certainly going around the 
horn.

Note that neither D nor ImportC rely on some database or symbol table file.



 Lucid Energize Demo in 1993
 
 https://www.youtube.com/watch?v=pQQTScuApWk
 
 Its database system, Cadillac,
 
 "Foundation for a C++ Programming Environment"
 
 https://dreamsongs.com/Files/Energize.pdf
 
 Visual Age for C++ v4,
 
 http://www.edm2.com/0704/vacpp4/vacpp4.html
 

 The build environment is totally different from traditional compilers. The 
 concept of header files and source code files is obsolete. VAC++ utilizes a 
 global approach to definitions and implementations. That is, once a definition 
 is processed it stays in memory for the duration of the build. To maintain 
 compatibility, header files can still be #included. This new approach to 
 handling source code is disorienting at first and will make migrating existing 
 code to the compiler somewhat difficult. Errors pertaining to objects being 
 defined more than once will likely occur while migrating. Often these errors 
 are incorrect. The work around is to remove the #include line in the source 
 file that contains the offending “redefinition”.


 
 https://books.google.de/books?id=ZwHxz0UaB54C&pg=PA206&redir_esc=y
v=onepage&q&f=false 
 
 
 Additionally the way pre-compiled headers work on C++ Builder and Visual C++, 
 versus the UNIX way, meant that on Windows the reward of the action did not 
 outweigh the costs incurred, and ironically Visual C++ is the one leading the 
 C++ modules support anyway, thanks to Gabriel dos Reis being part of the team, 
 and pinging back on those 2009 learnings.


Precompiled headers for C and C++ were certainly a module-like system (I know 
because I wrote one), but they are horrific kludges.
Jun 04 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:

 On 5/29/2022 11:13 PM, Paulo Pinto wrote:

 [...]


 Not the same as C doing the importing of C code.


 [...]


 Going around the horn, really doing it the hard way. Besides, 
 writing a paper is not the same thing as implementing a working 
 system. There were many proposals about adding modules to C, 
 they just all went nowhere.



 [...]


 Yee gods, doing it with a database representation is certainly 
 going around the horn.

 Note that neither D nor ImportC rely on some database or symbol 
 table file.



 [...]


 Precompiled headers for C and C++ were certainly a module-like 
 system (I know because I wrote one), but they are horrific 
 kludges.


I guess going around the horn is a synonym for lets pretend there 
wasn't prior art and keep arguing D did it first, as usual.
Jun 04 2022
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2022 5:29 AM, Paulo Pinto wrote:

 I guess going around the horn is a synonym for lets pretend there wasn't prior 
 art and keep arguing D did it first, as usual.


Writing a paper is not doing it first.
Jun 04 2022
next sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:

 On 6/4/2022 5:29 AM, Paulo Pinto wrote:

 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.


 Writing a paper is not doing it first.


That paper had a real implementation to follow along, while Lucid 
and IBM products were real things one could buy.
Jun 04 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/4/2022 10:54 PM, Paulo Pinto wrote:

 That paper had a real implementation to follow along,


I didn't see it.


 while Lucid and IBM 
 products were real things one could buy.


That are *C* compilers doing imports for *C* code?

What C compilers have imports:

gcc - nope
clang - nope
VC - nope
Digital Mars C - nope
C Standard - nope

ImportC - yes!
Jun 05 2022
parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:

 On 6/4/2022 10:54 PM, Paulo Pinto wrote:

 That paper had a real implementation to follow along,


 I didn't see it.


 while Lucid and IBM products were real things one could buy.


 That are *C* compilers doing imports for *C* code?

 What C compilers have imports:

 gcc - nope
 clang - nope
 VC - nope
 Digital Mars C - nope
 C Standard - nope

 ImportC - yes!


https://clang.llvm.org/docs/Modules.html

And I am out of this thread.
Jun 05 2022
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote:

 https://clang.llvm.org/docs/Modules.html

 And I am out of this thread.


Yes, Objective-C has added modules to C since forever… Just 
rename your .c file to .m

I guess that would be the first.
Jun 06 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 11:02:32 UTC, Ola Fosheim Grøstad wrote:

 Yes, Objective-C has added modules to C since forever… Just 
 rename your .c file to .m

 I guess that would be the first.


Or maybe not… you still use .h, so it depends on the 
implementation. Pointless discussion really.
Jun 06 2022
prev sibling next sibling parent reply Daniel N <no public.email> writes:
On Monday, 6 June 2022 at 05:49:55 UTC, Paulo Pinto wrote:

 On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:

 On 6/4/2022 10:54 PM, Paulo Pinto wrote:

 That paper had a real implementation to follow along,


 I didn't see it.


 while Lucid and IBM products were real things one could buy.


 That are *C* compilers doing imports for *C* code?

 What C compilers have imports:

 gcc - nope
 clang - nope
 VC - nope
 Digital Mars C - nope
 C Standard - nope

 ImportC - yes!


 https://clang.llvm.org/docs/Modules.html

 And I am out of this thread.


https://clang.llvm.org/docs/Modules.html#objective-c-import-declaration

"At present, there is no C or C++ syntax for import declarations. 
Clang will track the modules proposal in the C++ committee. See 
the section Includes as imports to see how modules get imported 
today."

So Object-C can import C, but *C* cannot import *C*.

Walter added __import support in *.c, clang could have done the 
same but they *didn't*, they were also probably just 10 lines 
away from the goal.
Jun 06 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 11:23:44 UTC, Daniel N wrote:

 So Object-C can import C, but *C* cannot import *C*.


Objective-C is a proper superset of C AFAIK.
Jun 06 2022
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2022 10:49 PM, Paulo Pinto wrote:

 On Sunday, 5 June 2022 at 22:41:14 UTC, Walter Bright wrote:

 That are *C* compilers doing imports for *C* code?


 https://clang.llvm.org/docs/Modules.html
 
 And I am out of this thread.


I had thought that was just for ObjectiveC. It seems it does work for C, though 
the user has to create "module map" files:

"To actually see any benefits from modules, one first has to introduce module 
maps for the underlying C standard library and the libraries and headers on 
which it depends. The section Modularizing a Platform describes the steps one 
must take to write these module maps."
Jun 07 2022
prev sibling parent reply mee6 <mee6 lookat.me> writes:
On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:

 On 6/4/2022 5:29 AM, Paulo Pinto wrote:

 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.


 Writing a paper is not doing it first.


Why do you care so much about being "first"? Would you not have 
implemented and made a presentation about it if you didn't think 
it was the first implementation?
Jun 05 2022
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 6/5/2022 7:26 AM, mee6 wrote:

 On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:

 On 6/4/2022 5:29 AM, Paulo Pinto wrote:

 I guess going around the horn is a synonym for lets pretend there wasn't 
 prior art and keep arguing D did it first, as usual.


 Writing a paper is not doing it first.


 
 Why do you care so much about being "first"? Would you not have implemented
and 
 made a presentation about it if you didn't think it was the first
implementation?


Because it's fun to be first!
Jun 05 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:


 Because it's fun to be first!


Yes, `'d'` is always independent.
For example, `'d'` is the `first one` without `class 
encapsulation`.
Jun 05 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:


 Because it's fun to be first!


 Yes, `'d'` is always independent.


[C++'s 
moudle](https://www.oschina.net/news/198583/c-plus-plus-23-to-introduce-module-support)

`D`, hurry up and get nervous.
Jun 05 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 6 June 2022 at 01:05:38 UTC, zjh wrote:

 On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:


 Because it's fun to be first!


 Yes, `'d'` is always independent.


 [C++'s 
 moudle](https://www.oschina.net/news/198583/c-plus-plus-23-to-introduce-module-support)

 `D`, hurry up and get nervous.


C++ has had modules for a while, but only Microsoft has a fully 
compliant implementation:

https://en.cppreference.com/w/cpp/language/modules
https://en.cppreference.com/w/cpp/compiler_support/20

Give it a year to be fully usable across compilers.
Jun 06 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:

 On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:


 Because it's fun to be first!


 Yes, `'d'` is always independent.
 For example, `'d'` is the `first one` without `class 
 encapsulation`.


To be fair, the encapsulation of a class can be encapsulated 
within a module, but not in a class (as one might reasonably 
expect, if they come from any other main stream language that 
uses a class type).

This implies (to me at least) that D does not consider a class to 
be a real type, like other main stream languages do.

Some new languages have even gone out of there way to get rid of 
the class type completely! At least D hasn't gone that far.. yet. 
I suspect there are many in the D community that would welcome 
that ;-)

Even an int type gets better recognition 'as a type', in D.

But yes, as far as i know, D is the first to do this - i.e. turn 
the class into a pseudo type, that cannot have encapsulation 
unless it is put into a super type (the module), all by its self 
(with no friends).

 private could change that.

D could be the first indeed, for turning a pseudo class type, 
back into an first class type.

C'mon D. Be the first!
Jun 05 2022
next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:


 Some new languages have even gone out of there way to get rid 
 of the class type completely! At least D hasn't gone that far.. 
 yet. I suspect there are many in the D community that would 
 welcome that ;-)



I don't know many other languages,I am not used to them.
`Rust` seems no class. These people are too radical.
Jun 05 2022
next sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 03:28:07 UTC, zjh wrote:


 `Rust` seems no class. These people are too radical.



It is easy to `make mistakes` if you take big `changes`.
Jun 05 2022
prev sibling parent reply forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 03:28:07 UTC, zjh wrote:

 On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:


 Some new languages have even gone out of there way to get rid 
 of the class type completely! At least D hasn't gone that 
 far.. yet. I suspect there are many in the D community that 
 would welcome that ;-)



 I don't know many other languages,I am not used to them.
 `Rust` seems no class. These people are too radical.


Rust did not set out to be a multi-paradigm language.

For Rust, I suspect they got of rid of the class, because they 
were setting out to be a high-performace, systems-level, 
programming language, and so decided that the class abstraction 
had to go. Ok. Fair enough.

D likes to think of itself as a high-performace, systems-level, 
programming language, as well, but it also claims to be a 
multi-paradigm language.

I have no doubt that many in the D community would also love to 
remove the class abstraction from the langauge, completely, and 
then they could force people into thinking 'the D way'.

I guess they want us to be grateful, that they have provided us 
with a pseudo class type. How nice of them.

The addidtion of a little character,  , to word private, could 
change this:

 private // Compiler says: oh. so you really want private to mean 
private? ok. I'll do it for you. no problem.

But I think even that is asking too much of the D community ;-)
Jun 05 2022
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 6/5/22 22:01, forkit wrote:


 I have no doubt that many in the D community would also love to remove
 the class abstraction from the langauge, completely, and then they could
 force people into thinking 'the D way'.


I must accept that "you have no doubt" but that claim is baseless.


 I guess they want us to be grateful, that they have provided us with a
 pseudo class type. How nice of them.


Now, that is trolling.

Ali
Jun 05 2022
next sibling parent forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 05:48:14 UTC, Ali Çehreli wrote:

 Now, that is trolling.

 Ali


Well, I could argue, correctly, that trolling is when someone 
picks only part of your argument, and uses only that part to 
support their own agenda - which is to destroy your argument by 
making it out to be something it is not.
Jun 05 2022
prev sibling parent forkit <forkit gmail.com> writes:
On Monday, 6 June 2022 at 05:48:14 UTC, Ali Çehreli wrote:

 Now, that is trolling.

 Ali


juvenalian satire, perhaps. I'd accept that.

But trolling? Really?
Jun 05 2022
prev sibling parent zjh <fqbqrr 163.com> writes:
On Monday, 6 June 2022 at 05:01:27 UTC, forkit wrote:


 The addidtion of a little character,  , to word private, could 
 change this:

  private // Compiler says: oh. so you really want private to 
 mean private? ok. I'll do it for you. no problem.


You need a `DIP`.
Jun 05 2022
prev sibling next sibling parent claptrap <clap trap.com> writes:
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:

 On Monday, 6 June 2022 at 00:19:16 UTC, zjh wrote:

 On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:


 But yes, as far as i know, D is the first to do this - i.e. 
 turn the class into a pseudo type, that cannot have 
 encapsulation unless it is put into a super type (the module), 
 all by its self (with no friends).



Delphi / Object Pascal had the same visibility as D, private only 
meant private to the module.
Jun 06 2022
prev sibling parent Dom Disc <dominikus scherkl.de> writes:
On Monday, 6 June 2022 at 03:17:34 UTC, forkit wrote:

 cannot have encapsulation unless it is put into a super type
 (the module), all by its self (with no friends).


It can have friends - they just need to be in the same file 
(module).
And a class without its friend is really only half a type - 
that's why it is better to think of the module as the new type - 
which contains both the interface and all interna (friends and 
sub-classes and  system parts that should not be visible from the 
outside).

That's what a file is for in general: to collect things that 
belong together and should be seen as a single object. It makes 
no sense to put other unrelated classes or functions into the 
same file. Especially not in a large project (which is the only 
case where encapsulation makes sense at all).
Jun 06 2022
prev sibling parent mee6 <mee6 lookat.me> writes:
On Sunday, 5 June 2022 at 22:41:41 UTC, Walter Bright wrote:

 On 6/5/2022 7:26 AM, mee6 wrote:

 On Saturday, 4 June 2022 at 19:26:27 UTC, Walter Bright wrote:

 On 6/4/2022 5:29 AM, Paulo Pinto wrote:

 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.


 Writing a paper is not doing it first.


 
 Why do you care so much about being "first"? Would you not 
 have implemented and made a presentation about it if you 
 didn't think it was the first implementation?


 Because it's fun to be first!


How's it fun to be first? Why is it that what other people are 
doing, with no connection to you, reduces the 'fun' you have? Are 
you having fun trying to dismiss every implementation of modules 
in C so you can be "first"?
Jun 08 2022
prev sibling parent reply claptrap <clap trap.com> writes:
On Saturday, 4 June 2022 at 12:29:59 UTC, Paulo Pinto wrote:

 On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:

 On 5/29/2022 11:13 PM, Paulo Pinto wrote:


 Precompiled headers for C and C++ were certainly a module-like 
 system (I know because I wrote one), but they are horrific 
 kludges.


 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.


Yikes whats up with you man? You need a hug?
Jun 04 2022
parent Paulo Pinto <pjmlp progtools.org> writes:
On Sunday, 5 June 2022 at 04:42:44 UTC, claptrap wrote:

 On Saturday, 4 June 2022 at 12:29:59 UTC, Paulo Pinto wrote:

 On Saturday, 4 June 2022 at 07:40:36 UTC, Walter Bright wrote:

 On 5/29/2022 11:13 PM, Paulo Pinto wrote:


 Precompiled headers for C and C++ were certainly a 
 module-like system (I know because I wrote one), but they are 
 horrific kludges.


 I guess going around the horn is a synonym for lets pretend 
 there wasn't prior art and keep arguing D did it first, as 
 usual.


 Yikes whats up with you man? You need a hug?


Nah, fed up with "D did it first, other languages keep copying 
us" meme.

Don't worry, I refrain myself in the future.
Jun 04 2022