OpenEuphoria

2. Re: Euphoria vs. other programming languages

• Posted by Fendaril Mar 04, 2009
• 1609 views

Lua is a scripting language and last I heard could not create stand-alone executables. Ohand take you bullcrap trolling "critiscism" somewhere else. If you do not like euphoria go away.

4. Re: Euphoria vs. other programming languages

• Posted by Fendaril Mar 04, 2009
• 1611 views

Its obviously negative.

6. Re: Euphoria vs. other programming languages

• Posted by Critic Mar 04, 2009
• 1601 views

I was too harsh. But apart from that, the documentation needs to be updated IMHO. Concentrate on the GUI tools that you have developed. And mention the comercial projects on your website. You need better marketing.

Other examples:

This is misleading at best. It is almost lying. It only refers to C and C is still more efficient than EU even though the hardware has changed.

I guess Smalltalk and LISP have better GC's than EU right now. Again, this is misleading, out-of-date and unconvincing. Please emphasize EU's real advantages rather than these misleading "facts".

8. Re: Euphoria vs. other programming languages

• Posted by Critic Mar 04, 2009
• 1622 views

srlua seems to build executables for Lua.

10. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 04, 2009
• 1610 views

I think you have an overly simple view of what 'efficient' means. Most higher level languages claim (rightly so) to be more efficient with programmer time, which at this point is typically more expensive than machine time. So your comment regarding hardware change is exactly why this point is relevant. Overall efficiency is often improved by using higher level languages. Of course, the trade off needs to be evaluated for each application.

Is your guess based on anything, or just random? You don't offer any reasons to back it up.

I can't quickly find any details on Smalltalk garbage collection, but this criticism does seem to apply to at least some forms of Lisp. Is your comment based on some other implementation?

These criticisms of GC should definitely be aimed at things like Java or Microsoft's CLR/Mono. Java does allocate large chunks of memory up front. Both of these also do periodic garbage collection, which can cause pauses in the execution. So you're correct that it could be more up to date.

Of course, being convincing is something that's entirely in the eye of the beholder. Clearly, you're not, which is Ok. Fortunately for you, there are other options available.

Matt

12. Re: Euphoria vs. other programming languages

• Posted by Critic Mar 04, 2009
• 1647 views

As if EU's doc is backed up... But anyway: http://www.lispworks.com/products/myths_and_legends.html Lispworks has a generational GC. I think Visualworks (Smalltalk) has something similar.

Quite true, at least for Java (I don't know about CLR). But it is a bit like saying "EU fragments memory, because it has no copying GC".

14. Re: Euphoria vs. other programming languages

• Posted by ghaberek (admin) Mar 04, 2009
• 1630 views

I want to address this statement in particular. The point of EDS is that it is, as the document states, flexible and simple. At its core, EDS is nothing more than an efficient way to store Euphoria objects on disk. Other languages may offer this functionality, but hardly without the grace and simplicity (and low-level compression) of EDS (I'm thinking of Python's "pickling").

What's wrong with binary search? It's rather fast on small data sets, and is proportionally faster as data sets grow than many other search methods (especially linear search). Larger database systems like MySQL use B-trees, which are better fit for large sets of (seemingly) unorganized data (which is what MySQL is aimed at, anyway). EDS always stores data in sorted order, so binary search works great for what we need.

-Greg

16. Re: Euphoria vs. other programming languages

• Posted by jeremy (admin) Mar 04, 2009
• 1604 views

Actually, I have used Python extensively. What I was refering to is the use of a compiler for Lua, then the use of valgrind for C. Anyway, you have not answered Derek's question really. Why did you write a message like this? Was it to antagonize or to offer criticism of the documents or ??? That would help us in addressing your concerns, if that is your end goal and not turn this thread into a mud slinging contest.

Jeremy

18. Re: Euphoria vs. other programming languages

• Posted by Critic Mar 04, 2009
• 1603 views

Ah, that explains a lot. Ok.

Well, it's simple enough for me:

import pickle 
 
pickle.dump({"key": "value", "key2": "value2"}, open("mydata.dat", "wb+")) 
value = pickle.load(open("mydata.dat", "rb")) 

20. Re: Euphoria vs. other programming languages

• Posted by Critic Mar 04, 2009
• 1606 views

Go ahead.

22. Re: Euphoria vs. other programming languages

• Posted by ghaberek (admin) Mar 04, 2009
• 1621 views

import pickle 
 
pickle.dump({"key": "value", "key2": "value2"}, open("mydata.dat", "wb+")) 
value = pickle.load(open("mydata.dat", "rb")) 

Already I can see an advantage of EDS over pickle: EDS has tables, which allow me to separate my data into a more logical structure. I suppose a clever arrangement of lists may yield a similar result.

And how do you fetch only "key" or "key2" from the file? What if you've got one hundred keys? or ten thousand keys? or one million keys? Do you have to load the whole file back into memory at once then write it all back to disk if you only want to update one key? That seems rather... slow.

-Greg

24. Re: Euphoria vs. other programming languages

• Posted by DerekParnell (admin) Mar 04, 2009
• 1604 views

Correct. That's why I'm not arguing with. It would also be more constructive to provide us with what you think it should say as well as what is wrong with the current words. I understand though that this might not be possible in all cases. I too have come across things in which I know to be wrong but I don't know how to fix it. But in any case, I'm sure that you, being a wordsmith, will be able to help us correct the information provided so far. I look forward to your contributions.

26. Re: Euphoria vs. other programming languages

• Posted by Critic Mar 04, 2009
• 1597 views

Come on, I told you what's wrong with them and what to emphazise instead. If you don't agree and I have not convinced you why should I contribute? So that you can give a tit-for-tat response?

And who thinks I am the right person to praise EU, anyway?

28. Re: Euphoria vs. other programming languages

• Posted by jimcbrown (admin) Mar 05, 2009
• 1574 views

Hi Kat.

30. Re: Euphoria vs. other programming languages

• Posted by euphoric (admin) Mar 05, 2009
• 1580 views

Nice work Tom!

32. Re: Euphoria vs. other programming languages

• Posted by CChris Mar 06, 2009
• 1609 views

I do.

It is simply not true that other conventional languages "wish to have" meaningful error messages.

Sure, it all depends what you include in "conventional languages". This would deserve at least a footnote. In the two I use more, and the one which I use at work, meaningful error messages are fairly standard. (Pascal, Eiffel and SAS).

As for the "elegant design"... of course, it is a question of taste. No clear way to determine or set the visibility of a symbol? No PBR? Forward references that make maintainance as difficult as in C? Those are at least three reasons for which I definitely disagree with this statement. Not to mention those 30-bit integers which make interfacing with other languages such a pleasure.

You should add, so as not to mislead newcomers: "A language without a programming IDE". Visual Euphoria (from the archive) is a first step towards that, but obviously falls short of an useful IDE.

CChris

34. Re: Euphoria vs. other programming languages

• Posted by Mike Mar 06, 2009
• 1591 views

@ Tom - great work!

36. Re: Euphoria vs. other programming languages

• Posted by ChrisB (moderator) Mar 07, 2009
• 1513 views

So, Judith's IDE, isn't slick enough?

Chris

38. Re: Euphoria vs. other programming languages

• Posted by CChris Mar 08, 2009
• 1483 views

It is a designing IDE, not a programming IDE. You can't use it for non win32lib-based apps. It doesn't tell you where symbols are defined, how the inclusion tree (now graph) looks like, doesn't provide any routine management, doesn't provide code templates, doesn't provie autocompletion or other routine argument tips, etc etc etc

You may say that advanced text editors do provide many of those features. That is true. But, for instance, none that I know abou can properly highlight instances of variables with an user defined type - just one tiny example.

CChris

40. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 08, 2009
• 1473 views

Please substantiate this claim.

While the global scope still exists, it's use is discouraged, and would probably have been removed completely, except for legacy code.

Matt

42. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 09, 2009
• 1473 views

A previously parsed symbol...from somewhere. Could be anywhere, maybe without any reference to that file, or anything remotely like it. Granted, this is still possible (and is why I mentioned global scope), but less likely, and should at least give the coder a warning in 4.0.

As opposed to wondering which files were included and were filling up the global namespace? At least there is a chain of public includes.

I really can't understand what your point is in bringing this up. Are you concerned at determining who can see a particular symbol from the perspective of that symbol? As you mentioned, everyone can see a global symbol. That's a very blunt instrument, and has consequences that make it a lot less useful than it originally sounds.

I guess you're interested in some sort of external packaging mechanism again. I know that you love to add maintenance points, but I've had enough of config files that affect code behavior with java and its endless xml files. Even there, the trend seems to be away from that, and towards code annotations, which at least are done right where the code is.

I've used Win32Lib with 4.0. So have others. Perhaps the example isn't as obvious as you think.

Since you've yet to give any reasons why it's more difficult in 4.0 to determine scope and to find where symbols are defined than with 3.1, yes, I would like to hear more.

Matt

44. Re: Euphoria vs. other programming languages

• Posted by jeremy (admin) Mar 10, 2009
• 1446 views

CChris,

IMHO, your claims are incorrect. The new system is much better, much cleaner, much easier to understand what is going on period. We've been over this a thousand times and if I recall, out of over 15 votes, you are the only person who has expressed a distaste for the new public/include system. Everyone else is on the other side. Not that majority always is better, but it may mean something. The only feasable thing that could be done to make it better would be to remove the global keyword, but this has serious consequences for legacy code, which is why it remains.

Jeremy

46. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 10, 2009
• 1449 views

CChris, in your own [preferred!] coding style, you had files that used variables in files that you never included in any way, shape or form, but required the file that included them to have defined the file. I seriously don't understand how you can claim to be interested in maintainability.

The point of a public symbol was for a library to expose its API this way, but still retain the ability to share other symbols amongst its files without exposing those by using the export scope. So you would assume that any source file that has included the library would be able to see all of the public symbols in that library. This seems extremely simple to me.

As an application author, your concern is that you're using the library in question. And it's very easy to do that by putting include the_library.e in the source file. As the library author, you know that any source file that includes your library will be able to see your public symbols.

If you're relying on globals simply being in the same folder, then you still have to worry about inclusion order (in 3.1).

I agree, you are unable to comprehend it.

Yes, I left out the parsed before issue. But this is an important point, so thanks for bringing my attention to it. Strange order of inclusion issues can easily trip you up in 3.1, causing global symbols you were counting on not to be available. In 4.0, it's less important, though it opens some possibility of symbol clashes, which, BTW are easily resolvable, unlike the order of inclusion issues in 3.1.

In fact, in 4.0 you do not need to add an include statement to see the globals elsewhere. Please understand the topic before you fly off the handle.

1. Please enlighten us as to a better forward reference design. I know that your proposal was discussed on the developers list, but the broader audience of the EuForum has not had the opportunity to review it.
2. The re-usability of code is not reduced at all. You can still use this paradigm as before, using global symbols. It's still a broken way of doing things. You can get the same effect by exposing an API for the users of your library to use. This would be like requiring win32lib users to make their event handlers global, and to have win32lib call them directly.

Huh? He found some bugs in the implementation. Most of his findings have been fixed (still working on one). As I said, I've used win32lib with 4.0, and it works just fine. Please leave the FUD somewhere else.

CChris, I have read them. So have others. We've all called BS. If you have anything new to say, then I'd be interested to hear it, but not your same, discredited arguments.

Matt

48. Re: Euphoria vs. other programming languages

• Posted by RStowasser Mar 10, 2009
• 1462 views
• Last edited Mar 11, 2009

Hi Chris,

actually I do not quite understand you. I once wrote to you that this quarrel is academic and that there are more ways to reach a goal. Many ways lead to Rome. If I report a problem then because I use Eu 4.0, because it is alpha, because I do not find a workaround for myself and because I trust into the development team. If I had your knowledge and your capabilities I would try to offer a solution myself. Really.

Btw I would not insist on full compatibility between Eu 4.0 and 3.1.1 applications. Other languages do this neither with their versions. To port programs from 3.1.1 to 4.0 you have to change some keywords anyway. (label, entry, continue, switch, break). I will not use global with Eu 4.0. And to be honest I would deprecate the use of global in Eu4.0 at all. Using the public and export keywords seem to be the better strategy to test and maintain separate modules / libraries. I do run my include files with exw/exwc to see if there are error messages. And although I like IDE and Win32lib they are also good examples in my opinion that they could be improved in Eu 4.0 only by using public and export. This would lead to a different structure of the include files, but I think this would also help to test and maintain the individual modules more effectively.

Roland

50. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 11, 2009
• 1462 views

This is exactly what we're doing: providing superior alternatives to using global scope. You still haven't figured it out, as evidenced by your comments. Why would removing global be silly (aside from legacy concerns)?

Matt

52. Re: Euphoria vs. other programming languages

• Posted by Fendaril Mar 11, 2009
• 1386 views

You always give up.

54. Re: Euphoria vs. other programming languages

• Posted by CChris Mar 12, 2009
• 1470 views

Inclusion of libraries happens usually at the top of the main file, because they are used almost from that point on, specially if they require some initialization.

For subfiles, ie files you include so as to split up your own code into moe manageable chnks, I don't think this is so clear cut. It is clearer to declare a variable or a file close to the point it is used.

This happens to me on a daily basis. ;) Luckily I have grep ... and ls ...

Not true.

file1.e includes file2.e file2.e includes file3.e file3.e includes file4.e

Identifier x is defined as public in file4.e . Where is it seen from? You have to follow th chain of public inclusions to guess whether it is visible in file1.e or not.

global was more straightforward, as you need only grep or similar utility. Some symbols must have less broad a scope, of course, but public is clearly not a good answer to the issue.

Not true again.

If you expand the visibility of some symbol in a deeply nested file, by adding another public qualifier to an include statement, you change the visibility of all symbols in that file. Not really the desired effect sometimes.

Problem not solved, since redefining other global symbols - from instance from the standard library - was just as common as redefinng builtins.

Yes, they are. Declare before use had been one of the strength of the language.

Note that I only agree to "forward references are bad in general". With proper restrictions, they are handy but yet not too harmful. And forward referencing is obviously needed, if only to remove the need for cyclic inclusions.

We have different faiths it seems. In large programs, this is very unpractical.

Not always and not in an easy to trace manner, see above.

56. Re: Euphoria vs. other programming languages

• Posted by CChris Mar 12, 2009
• 1378 views

I did, but ayatollah Matt & Jeremy said there was nothing to discuss. [/quote RStowasser] Btw I would not insist on full compatibility between Eu 4.0 and 3.1.1 applications. [/quote] Most Eu coders are happy to have had time to write code that eventually works. When the compatibility breakage goes beyond cosmetic changes like variable names, it is quite unreasonable to ask them to rewrite, as the code organisation itself may be affected. The coder base is simply not large enough for the luxury you suggest. Perl could do it, not Eu.

As I said, a 10 minute nearly automated change process is acceptable, I think. You cannot get past it anyway, or not easily. Changing the semantics of the language is a completely different story.

Why deprecate global? It has very legitimate uses. But alternative schemes should be provided so that it becomes useful only for special cases, just like goto.

I'll soon (in the next 6 hours I guess) post an alternate scheme. It ensures modularization, keeps the declare befor use paradigm, and keeps global unchanged - but in check. Its being unchecked has been indeed a prolem, which public attempted to solve, but with too bad collateral damage. Note that I am not directing much criticism towards export. export is fragile because a change in source system geometry will break it, but it is handy often enough to be kept, I think.

CChris

58. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 12, 2009
• 1349 views

Chris, we discussed this a lot. We discussed it until everyone but you agreed.

Well, this is mainly what we have in the case of euphoria 4.0. You keep mentioning things that structurally break most 3.1 code. There are a few cases where this might be true due to reliance on global symbols and parsing order, I believe they are quite rare, and easily fixed.

You're a long way from convincing anyone who has knowledge of 4.0 that we're all going to have to do major overhauls of our code due to the change to scoping and forward referencing. The new standard library will perhaps be the most difficult part, and even that shouldn't be too difficult.

Please stop trying to propagate ignorance.

The global scope could possibly bail you out like goto. Though I'm not sure it's even that useful. It does allow some dangerous coding practices, so it certainly allows the shooting of one's foot like goto does.

Matt

60. Re: Euphoria vs. other programming languages

• Posted by CChris Mar 12, 2009
• 1370 views

Not true. What I describe is NOT a library, but rather a plugin, optional component, removable component, call it as you like. It is NOT the black box that a third party library ideally is.

When a subfile defines an API, there is nothing wrong with that. Your example shows your utter lack of grasping the subject, since it concerns a totally different issue.

Even though you have my text right in front of your eyes, you make it say something completely different. I'm used to it, you've done it over and nauseatingly over before.

Saying something which is blatantly different from an easily available truth, for the some purpose of pretending to be right, i indeed lying. This doesn't eclude the fact that you may be lying to tyourself as well, I quite believe it actually. The two don't cancel out.

which prevents reusing the subfiles with a parent of a different name, unless you edit them. Good job.

Usually, cyclic dependenes arise because of only a few identifiers, less than a handful. In that case, an import <identifier> directive will indeed include the file, but (temporarily) hiding any unneeded public symbol. Parser won't choke on chicken and egg issues, and you still have mention of the file being relied upon. Much better conveying of the intent of the coder. [quote mattlewis]

One of the major benefits of the current design of forward referencing is that if you put include some_file.e in your code, then you can be assured that all symbols from some_file.e are available to the current file, without having to worry about dependency cycles. [/qote] and with terrible overhead, and multiplying the points to look at when the included library changes. Good job.

That's why an import directive is useful for - more on this later.

62. Re: Euphoria vs. other programming languages

• Posted by CChris Mar 12, 2009
• 1363 views

So, if x was in file3.e and was then moved to file4.e, you want to review all your code? You'll understand that O don't quite agree to this being good for maintainance.

In a nutshell, it is not very useful, and has been overadvertised as solving isssues it doesn't.

You claim that a problem is soved by emphasizing that a possibly small part was solved.

Nope, you may get it when I post my alternate system. This was delayed because of the frum being down or a few hours recently.

Agreed

What is "the API file"? Exposed identifiers may be defined in any subunit of the library, and which file it is might change without notice.

LLet me rebutt this with a single example. In win32lib, the getDC() function, which is used extensively, is defined in w32resources.ew, which win32lib.ew includes. Now, don't expect anything to work if you just include that file.

A good code breaker for no benefit, you mean.

CChris

64. Re: Euphoria vs. other programming languages

• Posted by DerekParnell (admin) Mar 12, 2009
• 1309 views

Christian,
how is inflamatory language going to help you or anyone else here?

This discussion about include file philosophy comes down to a difference of opinion. You have a specific opinion about what constitutes good programming practice and the current development team has a different opinion. As you well know, before you left the team, discussions amongst us all went on for what seemed like months about this issue. A number of ideas were tried out and what we have now is, IMO, the best outcome of all those discussions and experiments. Sure, I still think we could have done it a bit differently, but not all my suggestions were endorsed by the group as a whole. I got over it.

The language still has global so you are free to continue using your coding style in your libraries. And in just the same way, the development team has standardized on an include file coding style which has been demonstrated in the new standard library. No one is trying to force you to use a particular coding style in your own code.

My take on how we got to the new position is based on what problems we were trying to solve. They included ...

• How do we avoid name clashes with symbols that are exposed from a module (file)?
• How do we help code readers understand file inter-dependancies?
• How do we enable coders to group together related routines?

In v3 Euphoria, there is only one way to expose a symbol - use the global scope attribute. This meant that the probability of clashes between independantly written libraries is high. Further more, in some cases (include topologies), the only way to resolve a clash was to edit the source code of a third-party library. This 'resolution' could break at any time whenever a new release of that edited library was made, which of course was out of one's control.

Because the global scope is pervasive, one can include a file, say "A.E" that can include any number of other files, which in turn can include any number of still further files, etc, etc, etc... And a global symbol at the deepest nesting level can still be used in your application. On the surface, this seems like a handy time saver. You are not obliged to know in which particular file that symbol has been declared in. In fact, you'd probably have to use a 'grep' like tool to find it. This technique also means that you are not necessarily aware of your application's dependancy on the file that actually declares that global symbol.

In v4, we decided to make a simple rule to help us be aware of which files a given file was dependant on: If a file needs to use a symbol that has been declared in a standard library file, then it must explicitly include that standard library file.

To enable this rule to work, we came up with the public scope attribute. This is used instead of global to expose a symbol. The difference is that is only exposes the symbol to files that explicitly include it and no further up the include tree. This means that if "A" includes "B", and "B" includes "C", then "A" cannot see the public symbols declared inside "C". Of course, "A" can see "B"'s public symbols and "B" can see "C"'s public symbols.

This however gave as a new situation. When a library is huge, it is often broken into smaller sub-library files for maintenance/management reasons. Conceptually though, these sub-files are still part of a single library. It can be thought of as a multi-file library. But if an application includes the top-level library file (eg. win32lib) and that library file actually includes sub-library files in which public symbols are declared (intended for the application to use) it means that the application can't see them. This is a situation in which we need to propagate the exposed symbols from one level below a file to one level above the file. In other words, public symbols declared in a file that is included by win32lib, need to be made visible to the application that include win32lib.

This is achieved by having win32lib do a public include of its sub-library files. This is totally transparent to the application because conceptually, win32lib is the library file in which the exposed API is declared. So, from the point of view of the application, it needs to use a symbol from the win32lib library so it explicitly includes win32lib. This gives the application writer a consistant approach and frees the library writer to manage the multi-file library without breaking applications.

Having a multi-file library should make it easier for the library writer to organize the placement of routines so that related routines are near each other. This is a maintenance time-saver. However, in v3 Euphoria, this was not always possible due to the idea that code could only refer to other symbols that were 'above'. This meant that the physical placement of routines overrode the logical placement of routines. In large libraries, this could lead to situations were related routines are in different files, or widely separated in the same file. It also meant that a change to one routine's code might also mean you need to relocate that routine to get it to work again. The net result is the fragmentation of your library, which doesn't help readers or maintenance coding. The other technique to overcome this limitation is to use the routine_id() concept, but this comes with a performance overhead.

In v4, the limitation of where routines are placed has been lifted. One is no longer constrained to an artificial physical layout of code in order to get routines to 'see' each other. Instead, one can now group together related pieces of code.

Not all name clashes are resolved with public though. If two included files both declare the same exposed symbol name, your application needs a way to tell Euphoria which one you are referencing. This is done using the namespace concept. Each included file can have a namespace associated with it. This is just a name that you give to the file so you can qualify references to exposed symbols from that file. For example...

include foo.e as A 
include bar.e as B 
 
if A:func() = B:func() then ... 

In this case, both foo.e and bar.e declare an exposed symbol called 'func'. For Euphoria to know which 'func' you mean to use, you need to tell it via the namespace id. In this example, the namespace we gave to foo.e is 'A', and to bar.e is 'B'.

Actually, if the library writer has been on the ball, they would have given their files default namespaces and documented them of course too. For example ...

-- foo.e -- 
namespace foo 
 
public function func()  
   ... 
end function 
----- 

-- bar.e -- 
namespace bar 
 
public function func()  
   ... 
end function 
----- 

Then the application could have been written ...

include foo.e 
include bar.e 
 
if foo:func() = bar:func() then ... 

Note that these are default namespaces. You can still override them by using the "as" clause, if you want to.

66. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 12, 2009
• 1391 views

No, I understand what you're doing. I'm saying you're doing it wrong. It's generally called dependency injection or possibly inversion of control.

Yes, I am explicitly saying don't do this. It is really bad practice. There is a better way to get the same effect. See the links I provided above. I'll repeat: You're doing it wrong.

Yes, something like that could work. But again, it's fragile. You've added another point of maintenance that may need to be changed. The intent of the coder is perfectly conveyed by standard include directives, even though you don't believe in them.

I'm not sure what you're referring to, but the best I can figure is the overhead in the parser. When files have properly declared their dependencies, it's not too bad. And well worth the effort for the application or library developer.

Yes, it was a good job.

Matt

68. Re: Euphoria vs. other programming languages

• Posted by mattlewis (admin) Mar 12, 2009
• 1341 views

I don't know who 'O' is, but presumably there was a good reason for moving it that made sense. In that case, yes, I would expect you to do this, or at least try running the code to see who can't see it. Are you suggesting that you often move things around in files without thinking of the consequences?

If you think of your files as semi-independent modules, this all makes sense. If you simply see them as a way to keep any one file from growing too large, then you probably have bigger problems maintaining your software.

I disagree. It solves precisely the issues it was meant to solve. And by that I mean it gives authors of multi-file libraries the flexibility to share some symbols only amongst the library itself, and to share other symbols within and without the library, all without polluting the global namespace.

What problems do you believe are being over advertised?

The API file would be considered as the main file in a library. Win32Lib.ew, for instance. In other words, whatever file your documentation tells users to include. So long as that file uses public include with any library files with publicly scoped symbols, the end user doesn't have to care about which sub file actually defines the symbol.

Why would we? Is that file documented? To my knowledge, users are told to include win32lib.ew. This example doesn't rebut anything, but shows that you should use a library the way the author intended, or you're on your own, and some things probably won't work.

Most code won't even break due to these changes. And there is plenty of benefit, even if you can't comprehend it.

Matt