Re: [Corelinux-public] reviving the naming discussion

[Dan G. <goh...@mr...>]

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...