Re: Keywords and Namesapces
- Posted by mattlewis (admin) Oct 03, 2011
- 40810 views
I had some explanation before about the need for namespaces in version 4.
I was looking at the total number of functions in Euphoria version 4, and it is about 570 functions under several namespaces.
In wxEuphoria there are 1600 functions under one namespace. If wxEuphoria with over 1600 functions can have only one namespace, why can't the non-GUI euphoria with 570 function be under one namespace?
I think that wxEuphoria should ideally be split up (originally, it was!). In fact, I started doing this at one point. There are several issues with doing so:
- Backwards compatibility
- Lots of work
Currently, it's fairly simple to use wxEuphoria. There's a single include file. There are a few drawbacks, too. It takes a little longer to parse and load, since it always loads everything. Also, the naming convention can be cumbersome. Since the library that's being wrapped (wxWidgets) is object oriented, you can have lots of methods with the same name in different classes. wxEuphoria has to disambiguate them "the C way," which is to say, by making the names bigger to include the type of object or something.
Euphoria doesn't have classes like C++ does, but we do have namespaces, and it would be relatively easy to separate the wxEuphoria wrappers this way, so that you could have lots of set_text routines that could be easily disambiguated via namespaces.
The namespace route is the way we decided to go with the euphoria standard library. From before 4.0, there were some routines that already used a prefix (e.g., the old database.e, now std/eds.e that uses the db_ prefix). You'll note that there are some routines in the std library that have the same names. We'd have to update these with the prefixes.
But this leads to another issue. As new libraries are written, we'd likely have additional collisions. Now you'd end up with some routines that were prefixed, and some that weren't. This, IMHO, would be very confusing. Ultimately, we decided that new development would use the namespace approach, as it is relatively clean and extensible.
The standard library is a lot bigger than it used to be. The namespaces help make it a lot more manageable.
Matt
