OpenEuphoria

1. Too many namespaces

• Posted by EUWX Sep 14, 2013
• 4146 views

Forked from Re: Don't understand manual.

Having looked at the cutting up of the baseline modules (i.e. creation of Namespaces) in version 4, I can't help thinking that too many namespaces are unnecessary and probably counter productive. I am looking at the situation based on current hardware, where 16 GB CPU attached RAM is becoming the standard in desktops, USB storage is 2GB per dollar, SSD is under $100 for 128 GB and 1 TB SATA drive costs $70. Perhaps it is a requirement of the way C language handles (or cannot handle) things. I have worked for a while with the non namespace version of wxeu of Matt and see no problems or delays in execution of fairly large code.

It seems to me that an effort should be made to coalesce various independent "modules" of the baseline Euphoria and settle for 3-5 namespaces, if you must have namespaces. I know the battle of namespaces vs no namespaces must have been fought in the past; I am not attempting to restart the battle, but rather to look at the enormous hardware progress since the decision was made to go namespaces route. The only advantage I see at present of retaining the current numerous namespaces is the advent of connections to Android.

Some developers would argue that they cannot remember too many names of constants, etc., etc. This can be addressed at the .e level and .ex level with use of appropriate two letter prefixes on constants and on program name.

3. Re: Too many namespaces

• Posted by mattlewis (admin) Sep 14, 2013
• 4113 views

Namespaces aren't there for performance. They're there to prevent having to create names that are future proofed to be unique. That's pretty much impossible.

I can't see what the benefit of this would be, or how any of this relates at all to Android or anything hardware related.

The prefixes are problematic. What happens when two library authors choose the same two letters? Using namespaces is an elegant way to solve this problem. They really only need to be used when there is a conflict. But when there is a conflict, the solution is quick and easy, and you never have to touch 3^rd party code.

Matt

5. Re: Too many namespaces

• Posted by EUWX Sep 16, 2013
• 3820 views

I do not recall making any attempt at claiming better or worse runtime performance with the use of namespaces.
The concept of being able to create a variable name in my application program without worrying about the same name being already there in a pre-existing module I am going to use, is a luxury that the namespace concept denies the application programmer.

A constant declared and used in a low level (i.e. at the level of .e and now with GUI at the level of .ex) should not have to be "modified easily if the situation demands it". If an application programmer wants to modify it, he should first define (myname = includeprog:incname) and then use and modify "myname" ad lib.

However, you have missed the whole point of my argument.
There was a need in the past that the "library" with which the application programmer was working need not be all present in the final exe, and Euphoria addresses this extremely well. But look at the huge libraries and dlls people are working with now. A monolithic unalterable library of functions automatically a part of the final application is not particularly memory hogging by today's availability of memory. There is absolutely no need to discard unused functions when creating a final executable or even running Euphoria as interpreter - not from the point of memory needs nor from the point of better speed of execution. Once one understands this fundamental change in the hardware and the enormously increased speed of CPU, the need for 50 namespaces can probably be condensed to 4 or 1.

7. Re: Too many namespaces

• Posted by mattlewis (admin) Sep 16, 2013
• 3798 views

Maybe not, but that's what you wrote.

You have that backwards. Namespaces mean that you don't have to worry about naming conflicts like that, because there is an easy solution. And it's not a problem at all if you don't need to use the symbol in the library but only your local symbol.

He means the naming. Again, if two libraries decide to use the same prefix, you have no choice but to modify one of those libraries. With namespaces, you can simply choose a different namespace for your file to use to address one of the libraries and be completely clear about what's going on, both to the programmer and to euphoria. And you only have to do this in places where it is a real problem. No other code is affected or needs to be changed.

And once again, even though supposedly this isn't your point, you're tying namespaces to hardware and performance. Although, to be fair, namespaces can somewhat improve parsing performance when they are used, because we are able to bind the symbols sooner and prevent later lookups.

Nevertheless, when interpreting, nothing is discarded. The binder does discard some things. You're possibly right that the performance gains are pretty minimal now, although the performance of ARM hardware tells me otherwise. The translator discards unused things and uses this information to help optimize code. None of this relates to namespaces in any meaningful way.

I'll repeat this again. The main benefit of namespaces are for the programmer. It makes using third party code and writing libraries easier.

Matt

9. Re: Too many namespaces

• Posted by EUWX Sep 16, 2013
• 3808 views

Matt:
You have your own example you worked with for quite a while.
You used wxWidgets.
All the constants there have a prefix wx
In your version 16 of wxEuphoria, the whole .dll becomes memory resident. That means you got the file functions of wxWidgets which Euphoria already has and therefore, does not need. Yet using the dll, you are using that extra memory for a facility of wxWidgets you do not need. And there are many more facilities in wxWidgets which are duplicates of or similar to existing Euphoria facilities.
I have used comfortably your monolithic version of wxeu for GUI and not used the file functions therein, because I am using the Euphoria's "native" file functions. No problem there. Look at some other libraries; you will find that people have taken the same approach of using a relevant prefix.

In a nutshell, all I am saying is that there should not be 50 or 100 namespaces in Euphoria, but only 3-5, perhaps 8. The extra memory usage would not be a significant problem now (unlike the situation at the turn of the Century). If there are some good .e and .ex wandering around in the rapideuphoria archive, incorporate them if they are half relevant but into and within existing namespaces and reduce the number of existing namespaces at the same time.

11. Re: Too many namespaces

• Posted by EUWX Sep 16, 2013
• 3748 views

"Which do you propose to combine? How will this improve the life of a euphoria programmer?

Matt"

The following comes quickly to my mind.

A CPU has register to register instructions, Arithmetic instructions, registers/memory operations, memory/memory operations I/O, and branching.
A language has:
1. Maths,
2. I/O functions,
.... 2A. inc file functions and port addressing right up to Internet connection and networking,
.... 2B. fancy I/O to include Audio/video, etc
.... 2C. GUI because of the enormous size, to include text handling,
3. system inc. branching and OS related,
4. …. and miscellaneous.

13. Re: Too many namespaces

• Posted by LarryMiller Sep 16, 2013
• 3704 views

Prior to the introduction of namespaces Euphoria had a serious problem. Whenever a program used a third party include file there was always the possibility, and in the case of larger files, the likelyhood of a name clash. In many cases the only solution was to rename the clashing function, procedure, or other public symbol. This was tedious and error prone. Having multiple include files from different authors only compounded the problem. As an ideal a programmer should be able to treat an include file as a black box. It should never be necessary to even look at the files contents, let alone modify it.

Adding a prefix to public symbols was a viable but far from ideal solution. It greatly reduces the chances of a clash but doesn't really avoid them completely. Win32lib is a case in point. The code is littered with w32this and w32that, the only purpose being to avoid name clashes. It worked but wasn't what you would call elegant. But with Euphoria as then existed there really was no practical alternative.

Namespaces were a simple and elegant solution. Whenever there is a clash all a programmer needs to do is specify the namespace followed by the symbol name, as in "namespace:routinemame(). By default the namespace is the same as the name of the include file. If this produces a clash the programmer can override this name as necessary. Instead of trying to avoid the name clashes it provides the means of dealing with them. A programmer can use include files as they are without massaging them to avoid name clashes. An include file author can use names that fit their function instead of worrying about name clashes. Many other programming languages use similar methods.

I am not saying that namespaces are a perfect solution. In this imperfect world perfection is something that we strive for but never really achieved.

Using a namespace for each include fills the need. Having fewer namespaces would reduce the chances of a name clash but wouldn't avoid them. And at the same time it would add a few new ones.

But all of this is academic. Namespaces have existed in Euphoria 4.x for a long time and many applications rely on them as they currently exist. It would require a really compelling reason to change this now. To date no one has even come close to providing one.

15. Re: Too many namespaces

• Posted by jaygade Sep 16, 2013
• 3701 views

Namespaces themselves even predate 4.x, weren't they introduced with 3.11 or even earlier?

However, even then there were still occasional clashes.

The other piece of the puzzle, even if it is sometimes difficult to understand, is the fixes to the include mechanism as introduced in 4.x. With that, symbol clashes should be pretty rare.

17. Re: Too many namespaces

• Posted by mattlewis (admin) Sep 16, 2013
• 3691 views

I think I answered extremely clearly the questions that you wrote. I'm not sure you understand that the questions you asked or that the assertions you keep making are wrong.

What's unclear is why you believe that namespaces make things less clear.

You are a very confused person, and obviously you're only interested in saying silly things. Please stop. Your questions have been answered. If you think some part of those answers is unclear, please quote it and tell us what you think is unclear. If you're going to keep nattering on about people not coming to grip with some irrelevant aspect of computer hardware or software, then please just stop.

Matt

19. Re: Too many namespaces

• Posted by ChrisB (moderator) Sep 17, 2013
• 3638 views

Hi

Just to chip in.

So what we have so far is that namespaces avoid name clashes, make code reading easier, have very little memory overhead, make very little speed difference, and are optional. They have solved a lot of problems.

Personally, I only very rarely use them anyway (only when I have a clash)

I'm still using the global keyword for goodness sake. (don't remove it by the way!)

If you really have that much free time on your hands, copy the entire standard library into one uberfile, and rename any routines you need to. Euphoria is open source after all.

My point is not to be deliberately provocative, but just to demonstrate that Eu allows you the flexibility to do things as you want, whereas the much more used languages, in this respect, are quite a bit less flexible.

Chris

21. Re: Too many namespaces

• Posted by ArthurCrump Sep 17, 2013
• 3586 views

If you want prefixes instead of namespaces, just think of a namespace as the prefix that you want. But it has the advantage that you can often leave it off. And if a clash still occurs, you can use your own namespace. You can't do that with prefixes.

Arthur

23. Re: Too many namespaces

• Posted by petelomax Sep 17, 2013
• 3640 views

ROTFLMAO!

Have you [no offense] actually read any C plus plus code?

You mentioned wxWidgets; just because all the namespaces (erm, classes) begin with "wx" it is not quite the same as "one namespace".
(Anyone actually want to count them?)

Maybe your problem is more to do with the lack of an appropriate help/lookup?

Anyway, reminds me of this little Hello World gem (and sadly I now understand the big one at the end).

Pete

25. Re: Too many namespaces

• Posted by evanmars Sep 17, 2013
• 3566 views

--made up names, may or may not match actual items 
--I'm not a great programmer, so code may suck 
 
include WX.ex as wx 
include Banana.ex as ban 
include Cucumber.ex as cuke 
include Custard.ex as cust 
--I choose what to call my include files 
 
function new() 
     --some code to create a new 'thing' 
 return 0 
end function 
 
atom myWx, myBanana, myCuke, myCustard, myThing 
 
myWx = wx:new() 
myBanana = ban:new() 
myCuke = cuke:new() 
myCustard = cust:new() 
myThing = new() 

or

 
include WX.e 
include Banana.ex 
include Cucumber.ex 
include Custard.ex 
--designer of include files names functions as they see fit with prefixes 
 
atom myWx, myBanana, myCucumber, myThing 
 
myWx = wxNew()  --prefixes all routines with 'wx' 
myBanana = bnNew()  --prefixes all routines with 'bn' 
myCucumber = cuNew()  --prefixes all routines with 'cu' 
myCustard = cuNew()  --prefixes all routines with 'cu' 
myThing = new() 
--name clash between Cucumber and Custard files!! 
--I wish there was some major lookup table that all developers had to look at 
--to know what prefixes could be used and what routine names were already 
--used in ALL other include files so that anybody writing an include file 
--to be used by other people would know not to name their 'new()' the same as 
--somebody else's 'new()' 

27. Re: Too many namespaces

• Posted by useless_ Sep 17, 2013
• 3587 views

I have noticed that trying to escape the sexism is futile, for sure. Praps EUWX is another Ariel Castro. By another namespace, of course.

useless

29. Re: Too many namespaces

• Posted by mattlewis (admin) Sep 17, 2013
• 3568 views

It's feasible if you do not use many third party libraries. Or if you are willing to modify those third party libraries to prevent conflicts. I won't say that you're wrong to do either of those, but they are not paths that I (nor many) like to take.

Your assertion that namespaces are more cumbersome than prefixes is just silly, though. As already mentioned, there's nothing preventing you from using the same prefixes and a colon instead of an underscore. There's also nothing preventing you from using a rock to hammer nails, but don't expect the rest of us to think that you're onto something when we have a functioning air hammer.

Matt

31. Re: Too many namespaces

• Posted by mattlewis (admin) Sep 18, 2013
• 3453 views

I'm not sure how you'd hammer nails with a laser, but assuming that works, why do you continue to request that we all go back to using rocks?

Matt

33. Re: Too many namespaces

• Posted by _tom (admin) Sep 18, 2013
• 3451 views

A tiresome thread...

Dear EUWX, I am having great difficulty in decoding what you write. As a result I have to guess at what you are trying to say; in turn what you write makes no sense. Mix in some cultural differences and the discussion becomes most interesting.

One idea I guess you are making is that current hardware has 16GB RAM, tremendous speed, and can not suffer from bloated and slow software. This is not Euphoric thinking. If you look the flyer of a local retailer you will notice that 4 to 8 GB RAM is typical. Bad data leads to bad credibility.

I guess that you feel a single monolithic include connected to each application is not harmful. I made an include that contains the contents of the standard library. After compiling, the result was about a 1MB file which I consider to be bloat if it had to be part of every application. (Fortunately O[ removes unused code in an application.)

If you do not understand the namespace concept of Euphoria then there must be others. This means the documentation needs improvement.

A single include that contains commonly used modules has some value. Typing one line instead of several include statements will make it easier for novice programmers. I will explore this idea for tutorials directed at novice programmers.

A single include that contains one's personal modules also has some value; here bloat is under control since you select what is included.

It is incorrect to visualize the standard library as consisting of fifty or more namespaces. Each include file has a default namespace identifier but you do not need to know them all for most uses.

I didn't spend much time in making sure this chart is complete. Duplicated identifiers in the standard library:

List of namespaces with potential conflicts:

Depending on what you are programming, it looks feasible to package the standard library into five includes (five namespaces). From a typing viewpoint I consider wx_ and wx: as equivalent effort.

You are free to pick any identifier you want in your programming; your identifier will take precedence. You will only need to use a namespace prefix if your identifier is duplicated in the standard library.

Since O[ is an open source project with limited resources the only way one can make a case for an alternative idea is with code. A language developer and application programmer could easily create a new (alternative) standard library. Such a library would interest many O[ programmers.

_tom

35. Re: Too many namespaces

• Posted by EUWX Sep 18, 2013
• 3360 views
• Last edited Sep 19, 2013

You said over 1 mb is too big.

B00 ……………………………………………………………………. 988 kb
Elena …………………………………………………………………. 496 kb
LiveCode ……………………………………………………………..44.5 mb installer
Haskell setup ……………………………………………………….93 mb
Clojure……………………………………………………………….. .jar file over 3 mb
Netbeans Windows installer ……………………………….245 mb
Scala compiler …………………………………………………….10 mb
Java……………………………………………………………………. 30 mb
BCX …………………………………………………………………….247 kb
Freebasic ……………………………………………………………502 kb
Gambas…………………………………………………………….. 12 mb
Gentee………………………………………………………………. 2.6 mb
Purebasic………………………………………………………….. 19.5 mb
Python installer ………………………………………………… 19 mb

Almost all these products are much more used than Euphoria.