Menu
▾
▴
corelinux-public
|
From: Dan G. <goh...@mr...> - 2001-10-19 17:56:17
|
I noticed there was a thread on this list a while ago discussing the name of this project. From reading the archives, it seems that there were misunderstandings. When I first discovered CoreLinux++, I was interested in a lot of the goals of the project, but I was quickly scared off by words like this: What is not our intent? Not to be written for portability, but for exploitation of the Linux operating system enabling all that it has to offer to optimize performance. This is a very surprising position, as it is contradictory to the goals stated on the rest of the site. One of the most prominant places this exists is in the name of the project, CoreLinux++. One reason some people don't like this name is that, contrary to what good OOD prinicples would recommend, it focuses on a specific implementation detail instead of on the interface and its functionality. I realize that the developers are focusing on and developing on a certain platform, and this is fine. The project should not, however, exclude the possibility of someone else implementing various parts of the library on other platforms. Dan -- Dan Gohman goh...@mr... |
|
From: Frank V. C. <fr...@co...> - 2001-10-19 19:01:02
|
Dan, I agree with your posits, but not completely. The original idea for THIS project was to exploit a specific platform, it's api, etc. to base an advanced class library suite. the "What is not our intent" was to not get mired into endless discussions on multi-platform churn. Furthermore, on the OOD comment, by the time you are designing you have wed the artifacts of architecture and analysis to the language of choice as well as the platforms. In fact, the platforms are usually identified in the high level architectures, the patterns in analysis, the language and api in design. Should I assume you meant Architecture and OOA? Frank V. Castellucci Dan Gohman wrote: > I noticed there was a thread on this list a while ago discussing the > name of this project. From reading the archives, it seems that there > were misunderstandings. > > When I first discovered CoreLinux++, I was interested in a lot of > the goals of the project, but I was quickly scared off by words like > this: > > What is not our intent? > > Not to be written for portability, but for exploitation > of the Linux operating system enabling all that it has to offer > to optimize performance. > > This is a very surprising position, as it is contradictory to the > goals stated on the rest of the site. > > One of the most prominant places this exists is in the name of the > project, CoreLinux++. One reason some people don't like this > name is that, contrary to what good OOD prinicples would > recommend, it focuses on a specific implementation detail instead > of on the interface and its functionality. > > I realize that the developers are focusing on and developing on > a certain platform, and this is fine. The project should not, > however, exclude the possibility of someone else implementing > various parts of the library on other platforms. > > Dan > > -- > Dan Gohman > goh...@mr... > > _______________________________________________ > Corelinux-public mailing list > Cor...@li... > https://lists.sourceforge.net/lists/listinfo/corelinux-public |
|
From: Dan G. <goh...@mr...> - 2001-10-19 21:49:29
|
On Fri, Oct 19, 2001 at 03:03:58PM -0400, Frank V. Castellucci wrote: > Dan, > > I agree with your posits, but not completely. The original idea for THIS > project was to exploit a specific platform, it's api, etc. to base an > advanced class library suite. the "What is not our intent" was to not > get mired into endless discussions on multi-platform churn. It looks like there's two distinct goals here. One one hand, the CoreLinux++ web site talks about working to support GoF patterns, coding standards and conventions, the ISO 14882 standard, and framework components for supporting generic design. On the other, the site talks about writing wrappers around kernel facilities, and excluding support for any non-Linux platform so that performance can be maximized. The first of these is very useful and has a very broad scope of applicability. It also has nothing to do with any particular kernel, doesn't need kernel-specific performance tuning, and by nature shouldn't generate much multi-platform churning in any of its development phases. The second of these has a more limited scope of applicability. For many projects, supporting multiple platforms is a requirement, and if CoreLinux++, as its name and web site suggest, requires Linux, then whatever performance gains or development principles it sports won't matter. > Furthermore, on the OOD comment, by the time you are designing you have > wed the artifacts of architecture and analysis to the language of choice > as well as the platforms. In fact, the platforms are usually identified > in the high level architectures, the patterns in analysis, the language > and api in design. > > Should I assume you meant Architecture and OOA? It seems we have differing definitions of the word design. I probably did mean Architecture and OOA. Please have patience with a student from a different school :-). > > Frank V. Castellucci > > Dan Gohman wrote: > > > I noticed there was a thread on this list a while ago discussing the > > name of this project. From reading the archives, it seems that there > > were misunderstandings. > > > > When I first discovered CoreLinux++, I was interested in a lot of > > the goals of the project, but I was quickly scared off by words like > > this: > > > > What is not our intent? > > > > Not to be written for portability, but for exploitation > > of the Linux operating system enabling all that it has to offer > > to optimize performance. > > > > This is a very surprising position, as it is contradictory to the > > goals stated on the rest of the site. > > > > One of the most prominant places this exists is in the name of the > > project, CoreLinux++. One reason some people don't like this > > name is that, contrary to what good OOD prinicples would > > recommend, it focuses on a specific implementation detail instead > > of on the interface and its functionality. > > > > I realize that the developers are focusing on and developing on > > a certain platform, and this is fine. The project should not, > > however, exclude the possibility of someone else implementing > > various parts of the library on other platforms. > > > > Dan > > > > -- > > Dan Gohman > > goh...@mr... > > > > _______________________________________________ > > Corelinux-public mailing list > > Cor...@li... > > https://lists.sourceforge.net/lists/listinfo/corelinux-public > > > _______________________________________________ > Corelinux-public mailing list > Cor...@li... > https://lists.sourceforge.net/lists/listinfo/corelinux-public -- Dan Gohman goh...@mr... |
|
From: Frank V. C. <fr...@co...> - 2001-10-20 00:26:15
|
Dan Gohman wrote: >On Fri, Oct 19, 2001 at 03:03:58PM -0400, Frank V. Castellucci wrote: > >>Dan, >> >>I agree with your posits, but not completely. The original idea for THIS >>project was to exploit a specific platform, it's api, etc. to base an >>advanced class library suite. the "What is not our intent" was to not >>get mired into endless discussions on multi-platform churn. >> > >It looks like there's two distinct goals here. One one hand, the >CoreLinux++ web site talks about working to support GoF patterns, coding >standards and conventions, the ISO 14882 standard, and framework >components for supporting generic design. On the other, the site talks >about writing wrappers around kernel facilities, and excluding support >for any non-Linux platform so that performance can be maximized. > >The first of these is very useful and has a very broad scope of >applicability. It also has nothing to do with any particular kernel, >doesn't need kernel-specific performance tuning, and by nature >shouldn't generate much multi-platform churning in any of its >development phases. > With the exception of some kind of guard/monitor I agree. And the exception is based on real world experience where many a class library fails to satisfy the demands of multi-threaded activity. >The second of these has a more limited scope of applicability. For >many projects, supporting multiple platforms is a requirement, and >if CoreLinux++, as its name and web site suggest, requires Linux, then >whatever performance gains or development principles it sports won't >matter. > It won't matter on other platforms, yes. While we are here, mind telling me what moniker you would tac onto this anyway? We can put semantics aside for the moment. >>Furthermore, on the OOD comment, by the time you are designing you have >>wed the artifacts of architecture and analysis to the language of choice >>as well as the platforms. In fact, the platforms are usually identified >>in the high level architectures, the patterns in analysis, the language >>and api in design. >> >>Should I assume you meant Architecture and OOA? >> > >It seems we have differing definitions of the word design. I probably >did mean Architecture and OOA. Please have patience with a student from >a different school :-). > It was the "good OOD principles" that got me. Lets continue this, your not the first to comment on the Linux attachment, maybe I'm getting soft in my old age ;-) >>Frank V. Castellucci >> >>Dan Gohman wrote: >> >>>I noticed there was a thread on this list a while ago discussing the >>>name of this project. From reading the archives, it seems that there >>>were misunderstandings. >>> >>>When I first discovered CoreLinux++, I was interested in a lot of >>>the goals of the project, but I was quickly scared off by words like >>>this: >>> >>> What is not our intent? >>> >>> Not to be written for portability, but for exploitation >>> of the Linux operating system enabling all that it has to offer >>> to optimize performance. >>> >>>This is a very surprising position, as it is contradictory to the >>>goals stated on the rest of the site. >>> >>>One of the most prominant places this exists is in the name of the >>>project, CoreLinux++. One reason some people don't like this >>>name is that, contrary to what good OOD prinicples would >>>recommend, it focuses on a specific implementation detail instead >>>of on the interface and its functionality. >>> >>>I realize that the developers are focusing on and developing on >>>a certain platform, and this is fine. The project should not, >>>however, exclude the possibility of someone else implementing >>>various parts of the library on other platforms. >>> >>>Dan >>> >>>-- >>>Dan Gohman >>>goh...@mr... >>> >>>_______________________________________________ >>>Corelinux-public mailing list >>>Cor...@li... >>>https://lists.sourceforge.net/lists/listinfo/corelinux-public >>> >> >>_______________________________________________ >>Corelinux-public mailing list >>Cor...@li... >>https://lists.sourceforge.net/lists/listinfo/corelinux-public >> > |
|
From: Dan G. <goh...@mr...> - 2001-10-20 03:39:55
|
On Fri, Oct 19, 2001 at 08:32:18PM -0400, Frank V. Castellucci wrote: > > Dan Gohman wrote: > > > >It looks like there's two distinct goals here. One one hand, the > >CoreLinux++ web site talks about working to support GoF patterns, coding > >standards and conventions, the ISO 14882 standard, and framework > >components for supporting generic design. On the other, the site talks > >about writing wrappers around kernel facilities, and excluding support > >for any non-Linux platform so that performance can be maximized. > > > >The first of these is very useful and has a very broad scope of > >applicability. It also has nothing to do with any particular kernel, > >doesn't need kernel-specific performance tuning, and by nature > >shouldn't generate much multi-platform churning in any of its > >development phases. > > > With the exception of some kind of guard/monitor I agree. And the > exception is based on real world experience where many a class library > fails to satisfy the demands of multi-threaded activity. Are you familiar with the Boost project (www.boost.org)? The recent Boost threading library provides a relatively low-level portable threading API. It is currently implemented for pthreads and Win32 threads. This might make a good base on which to build the guard/monitor components. Regardless of how the thread-saftey is implemented, let's assume there's a sufficiently high-level interface to it. This way the user-base could easily do their own implementation for platforms that the library doesn't support. What we have then with this part is a library that is almost completely platform neutral (assuming a sufficient C++ environment, which is a fair assumption), and the small portion that is platform dependant is easily implementable on many platforms. Does it make sense to put this part in a library called CoreLinux++? I think this name, as well as the blurbs one the web site that welcome new visitors, unnecesarrily limit the user-base. > >The second of these has a more limited scope of applicability. For > >many projects, supporting multiple platforms is a requirement, and > >if CoreLinux++, as its name and web site suggest, requires Linux, then > >whatever performance gains or development principles it sports won't > >matter. > > > It won't matter on other platforms, yes. While we are here, mind telling > me what moniker you would tac onto this anyway? We can put semantics > aside for the moment. Tac onto what? I don't understand what your asking. The kernel-api wrappers part of CoreLinux++ has many competitors, in that there are many kernel-api C++ libraries. How will this part of CoreLinux++ compare? I think in order for this part of the library, given its current advertized philosophy, to be successful, it needs to convince developers that its OO design and optimized performance justify the abandonment of other platforms. This sounds like a tough task. > >>Furthermore, on the OOD comment, by the time you are designing you have > >>wed the artifacts of architecture and analysis to the language of choice > >>as well as the platforms. In fact, the platforms are usually identified > >>in the high level architectures, the patterns in analysis, the language > >>and api in design. > >> > >>Should I assume you meant Architecture and OOA? > >> > > > >It seems we have differing definitions of the word design. I probably > >did mean Architecture and OOA. Please have patience with a student from > >a different school :-). > > > It was the "good OOD principles" that got me. Lets continue this, your > not the first to comment on the Linux attachment, maybe I'm getting soft > in my old age ;-) I think we have different understandings of the words. Here's how I percieve the issue: There's very little (nothing?) that Linux does that other systems don't do, and often they do things in a similar way. If the public interfaces of a high-level library have Linux-specific details, then it seems to me to be a lack of proper abstraction, which, in my universe ;-), is a design issue (hence my comment about OOD priniciples). If I'm misusing terminology, please correct me :-). > >>Frank V. Castellucci > >> Dan -- Dan Gohman goh...@mr... |
