TOPIC: Namespaces
Namespaces 3 Years, 5 Months ago
I don't now if previously discussed but I think that suneido has grown enough to support namespaces.
I faced a problem with ChooseManyControl not working because I named a function GetParent which is used there.
I understand that overloading internal stdlib functions is usefull but I think some times dangerous.

Any comment is appreciated
Re:Namespaces 3 Years, 5 Months ago
I have thought about namespaces quite a lot. I agree that it would be a good thing to have. My feeling is that the right solution would be backwards compatible (i.e. not break existing code) and would still allow you to write simple code without having to worry a lot about namespaces.

I have to admit that Suneido's C++ implementation does not use namespaces. Part of the reason for this is that when I first started Suneido 6 or 7 years ago, namespaces were not well supported. In most cases I use the "brute force" approach of "using namespace std" (although I am avoiding that in new code). My point is that I do not have a lot of personal experience with namespace systems.

As far as global names, in our main application (around 200,000 lines) we simply use a two letter prefix for each main module e.g GL_, AR_, AP_,

As far as database field names, our naming convention is to have a field name prefix that is an abbreviation of the table name e.g. arinvoices => arivc_

You can see these naming conventions at work in the Accounting download.

Regarding member name clashes - in general, inheritance is often overused. Composition is often better.

Here are some of the ways you could go about enhancing/modifying stdlib

modify it directly in stdlib - the problem with this is that you can not update to a new version of stdlib without losing your changes

copy the record to your own library and modify it there - now you can update stdlib, but if that record has been enhanced you will not get the improvements because you are using your old copy.

modify it and get the changes incorporated into stdlib - but if the changes are not compatible or not generally desirable, we may not want to include it in stdlib

make a record in your own library that inherits from the stdilb one and adds or overrides specific methods - better, but you can still run into problems with incompatible updates or with public member name clashes (private members are ok)

make a record in your library that wraps the stdlib version - for controls this generally means making a controller with the stdlib version as it's Control. This is natural when you want to add visual "decoration" but it is also useful when you just want to modify behavior. The advantage of this approach is that you do not have to worry about member name clashes. You may find that the stdlib control does not have all the low level methods you need to access it. These can be added by any of the above methods. If these methods are generic and do not change the behavior then they will generally be welcome additions to stdlib.

The other choice you have to make (except for the very first option) is whether to give your version the same name as the existing stdlib one.

The advantage of keeping the same name is that any existing code will automatically get your new version. This can be a big advantage if you have a lot of existing code, or if you want the change to be automatically used by other stdlib code.

But if your change is not compatible, then you risk "breaking" existing code. For example, if other stdlib code relies on the old behavior.

If your change is a backwards compatible enhancement then I would keep the same name. If it is an incompatible modification I would give it a new name.