Re: Namespaces (was: string vs. LString)
Asger seems to want to make extensive use of namespaces and to a certain extent I can see that as being a good way to enforce the notion of ownership to the various modules. So we could have a gui namespace and an Inset namespace among others. If we then use namespaces in our code we can use namespaces from stl (which involves using different headers). Yes, I would like to use namespaces more. My feeling is that the bad things about global functions and variables does not exists anymore when you have namespaces. Suddenly, there is nothing wrong with having global functions and variables, and this change opens up some methods of coding that were previously packed away as bad coding style. With namespaces, I feel it's easier to let the code express what things are. For instance, the encoding facility is a global means of performing encoding conversions, that does not depend on any state or context. So I don't see why this feature should not just be exactly that in the code: an independent global function that does the conversion. Regarding whether we should *require* support for namespaces from the compiler or not: I have no real opinion on this. I'm sure that we can make things work without proper namespace support, and that is a good thing. The important thing is that the developers will be able to exploit the concept of namespaces, and if their compiler is up to it, get the extra safety from the compiler. I find it hard to make a list of things that we want from the compiler in advance. I'm more into the lazy style: Just code, and then take care of the problems when they appear. That's what we have been doing so far, and it seems to work pretty well. Of course, we are demanding more things from the compilers now, and it might turn out that we have to set some minimum requirements, but until we know more about the problems, it's hard to say what those are. Greets, Asger
Re: Namespaces (was: string vs. LString)
"Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan Asger seems to want to make extensive use of namespaces and to Allan a certain extent I can see that as being a good way to enforce Allan the notion of ownership to the various modules. So we could Allan have a gui namespace and an Inset namespace among others. If Allan we then use namespaces in our code we can use namespaces from Allan stl (which involves using different headers). Well, I see it as good but not necessarily required if we do not want to lock out a number of compilers... JMarc
Re: Namespaces (was: string vs. LString)
> Asger seems to want to make extensive use of namespaces and to a certain > extent I can see that as being a good way to enforce the notion of > ownership to the various modules. So we could have a gui namespace and an > Inset namespace among others. If we then use namespaces in our code we > can use namespaces from stl (which involves using different headers). Yes, I would like to use namespaces more. My feeling is that the bad things about global functions and variables does not exists anymore when you have namespaces. Suddenly, there is nothing wrong with having global functions and variables, and this change opens up some methods of coding that were previously packed away as bad coding style. With namespaces, I feel it's easier to let the code express what things are. For instance, the encoding facility is a global means of performing encoding conversions, that does not depend on any state or context. So I don't see why this feature should not just be exactly that in the code: an independent global function that does the conversion. Regarding whether we should *require* support for namespaces from the compiler or not: I have no real opinion on this. I'm sure that we can make things work without proper namespace support, and that is a good thing. The important thing is that the developers will be able to exploit the concept of namespaces, and if their compiler is up to it, get the extra safety from the compiler. I find it hard to make a list of things that we want from the compiler in advance. I'm more into the lazy style: Just code, and then take care of the problems when they appear. That's what we have been doing so far, and it seems to work pretty well. Of course, we are demanding more things from the compilers now, and it might turn out that we have to set some minimum requirements, but until we know more about the problems, it's hard to say what those are. Greets, Asger
Re: Namespaces (was: string vs. LString)
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> Asger seems to want to make extensive use of namespaces and to Allan> a certain extent I can see that as being a good way to enforce Allan> the notion of ownership to the various modules. So we could Allan> have a gui namespace and an Inset namespace among others. If Allan> we then use namespaces in our code we can use namespaces from Allan> stl (which involves using different headers). Well, I see it as good but not necessarily required if we do not want to lock out a number of compilers... JMarc
Re: Namespaces (was: string vs. LString)
"Allan" == Allan Rae [EMAIL PROTECTED] writes: Allan # We still need portability to other platforms of course but we Allan can draw a line and say "it must support namespaces" or Allan whatever else we desire. We can probably get away without Allan partial specialization of templates. Could you explain why we need those namespaces? I understand what they are in general, but we could probably live with std:: being the same as the glabal namespace, if we choose names correctly. Other than that, I agree that we should draw a line somewhere. But we should be careful to draw it at the right place. And remember that many people need to compile on the platform compilers and try to support at least the latest version of these compilers. JMarc
Re: Namespaces (was: string vs. LString)
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: Allan> # We still need portability to other platforms of course but we Allan> can draw a line and say "it must support namespaces" or Allan> whatever else we desire. We can probably get away without Allan> partial specialization of templates. Could you explain why we need those namespaces? I understand what they are in general, but we could probably live with std:: being the same as the glabal namespace, if we choose names correctly. Other than that, I agree that we should draw a line somewhere. But we should be careful to draw it at the right place. And remember that many people need to compile on the platform compilers and try to support at least the latest version of these compilers. JMarc
Namespaces (was: string vs. LString)
On 29 Mar 1999, Lars Gullik Bjønnes wrote: We need to introduce namespaces rather soon. Lgb Perhaps we should make a decision as to what compiler capabilities we require. By the time LyX-1.1 is finished and stable enough to release there will probably be another gcc released and egcs will also be better. So perhaps we should make those the standard now and forget about gcc-2.7.2 and its contemporaries and concentrate on getting better code written instead of compatability#. That would also be a benefit for me since I could avoid having to reinstall gcc-2.7.2 and just stick with the two compilers I have now instead of the old 4 compiler installation I used to have. Points: Anyone using egcs should be using the latest or latest - 1. It is experimental after all and egcs-1.0.3a has a few flaws. Namespaces are handy and extensively used in the STL so it would make sense to exploit them rather than try to work around them. Allan. (ARRae) # We still need portability to other platforms of course but we can draw a line and say "it must support namespaces" or whatever else we desire. We can probably get away without partial specialization of templates.
Namespaces (was: string vs. LString)
On 29 Mar 1999, Lars Gullik Bjønnes wrote: > We need to introduce namespaces rather soon. > Lgb Perhaps we should make a decision as to what compiler capabilities we require. By the time LyX-1.1 is finished and stable enough to release there will probably be another gcc released and egcs will also be better. So perhaps we should make those the standard now and forget about gcc-2.7.2 and its contemporaries and concentrate on getting better code written instead of compatability#. That would also be a benefit for me since I could avoid having to reinstall gcc-2.7.2 and just stick with the two compilers I have now instead of the old 4 compiler installation I used to have. Points: Anyone using egcs should be using the latest or latest - 1. It is experimental after all and egcs-1.0.3a has a few flaws. Namespaces are handy and extensively used in the STL so it would make sense to exploit them rather than try to work around them. Allan. (ARRae) # We still need portability to other platforms of course but we can draw a line and say "it must support namespaces" or whatever else we desire. We can probably get away without partial specialization of templates.
