From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news4.google.com!news.glorb.com!border1.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!feed.cgocable.net!read1.cgocable.net.POSTED!53ab2750!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> <52fBd.42256$nV.1324414@news20.bellglobal.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <_gHBd.14666$0y4.10314@read1.cgocable.net> Date: Sat, 01 Jan 2005 19:31:56 -0500 NNTP-Posting-Host: 24.150.168.167 X-Complaints-To: abuse@cogeco.ca X-Trace: read1.cgocable.net 1104625850 24.150.168.167 (Sat, 01 Jan 2005 19:30:50 EST) NNTP-Posting-Date: Sat, 01 Jan 2005 19:30:50 EST Organization: Cogeco Cable Xref: g2news1.google.com comp.lang.ada:7382 Date: 2005-01-01T19:31:56-05:00 List-Id: Dmitry A. Kazakov wrote: > On Fri, 31 Dec 2004 11:24:40 -0500, Warren W. Gay VE3WWG wrote: >>Dmitry A. Kazakov wrote: >>>On Fri, 31 Dec 2004 06:30:51 -0500, Warren W. Gay VE3WWG wrote: >>All of the infrastructure that you talk about is built outside of >>the mk. The mk's purpose is to provide the basic needs for an OS, but >>_not_ be the OS itself. In fact, using a mk approach, application and >>OS modules conceptually run beside each other, perhaps only differing >>in the privileges they have (ports that they have rights to). > > I agree in principle, but disagree in details, in what are these basic > needs. I think that a kind of "protected object" should be provided already > by the kernel as a building block. Ok, but if your Ada RTL provides it, do you really care that much whether it is in or out of the OS? > When we know little and just start > to explore a new field of computing, we always start with 1. Then we gather > knowledge, get frustrated with "flexibility" of making errors and switch 2. This _assumes_ flexibility = errors. I don't believe this to be generally true; but I'll agree that it _can_ be. > That happens when we already know how-to. But having reached the stage 2, > we find it possible to do things we could not approach before and so open a > new field. Then again first 1, etc. ] Perhaps, but it is not always good or necessary to straight-jacket APIs. It should only be applied to curtail abuse, without limiting the programming capability. > The point is, it seems that with installation/properties/profile issue we > have reached the stage when we could start to think about 2. Sure, we can think about it, but IMO I don't think anyone has gone beyond the registry in proposed solutions yet. You say "OO will do it better", but haven't supported the "why" it will. You avoid that by not talking about "how". If I avoid answering the "how", I could propose a lot of "better" ways. >>What does "object persistence" have more than a "set of values"? How >>is an "object container" any different than a directory/subdirectories >>containing "values"? > > The difference is that the above is untyped or weakly typed. An object is > not just a value but also the methods to apply. This firstly would prevent > abuses, and secondly, we could define somewhere an abstract interface to be > implemented and so enforce proper behavior. But a persistent object is nothing more than a blob of data recorded in a file (or something acting as a container). The fact that it might have methods makes no real difference. Who provides the methods? If you have to provide them, then you make matters worse (we're back to everybody writing their own way to save and retrieve data in their own way). If you don't, then this cannot possibly anticipate your needs, unless you use something like Ada stream I/O. But you don't want to commit to "how" this is done, so it remains an unsubstantiated claim, and we cannot progress in that discussion ;-) >>But you have not proposed any solution. You keep saying that >>"I don't want to be responsible", but there is nobody/nothing >>left to fill that void. > > In OO the object is responsible to provide an implementation. But who writes the object? The kernel writer can't. How is he going to anticipate all of your configuration needs for your application and mine? You already have Ada.Streams, but so what. I don't see that as an improvement for this purpose. > A minimal > kernel should give an ability to define some system object. A pair levels > above there should be defined an abstract interface of application > persistent data. Each application that possesses such data have to > implement that interface etc. This still doesn't say "how" it is better, or "how" it will be done. Without saying "how", you could promise the moon. >>Not everything manifests itself as a diamond (obviously). If a >>hierarchy or "node network" doesn't satisfy your needs, then >>I'd like to hear just what other structure can. You can't >>just close your eyes and say "just make it happen". We don't >>enjoy that luxury! 8-> > > Node network, relational data base, tree-like structure with links, all > that are just implementations of an abstract interface of what a repository > should provide. So what? Eventually everyone has to "choose" something. > We will go no further if we will try to put the cart before > the horse. First we must define the interface, its implementation is a > minor problem. As part of any abstract discussion, you do have to eventually consider the practical aspect of "how" it will be done. Otherwise people can make all kinds of promises that can't be kept. >>So you don't want an API, and yet you want it to happen somehow. > > No, I do not want to see Read_Block and Write_Block in API. Sure, but who was proposing that? > Writing an Ada > program, I do not see LDA, STR, MOV. They are still there, somewhere > beneath in the Underwolrd, but I don't care. Of course. But when you want to know where GNAT is installed, it is very easy in Windows to lookup a registry key and get the pathname for it. If I want to know where APQ should be installed as an Ada binding, I can do another registry query and get the top level GNAT directory for bindings. Is that so complicated? Does it really need to be more complicated than that? >>Somehow, >>some piece of software/hardware/system is supposed to know what pieces >>of information are configurable elements, know how to organize it, >>know how to identify it and share it in a safe way with other processes >>and users on the same system/network? > > The answer is ADT. As long these pieces are just bytes, there will be > nothing much better than Windows/UNIX. It is time to make a technological > leap. You keep saying "just bytes". Even the windows registry is better than that, and you know that. Call it "weak typing" if you like, but you can't say it is a bad idea because it _can_ be worse. Discuss the idea on the merits of what it _can_ be. How strongly typed do you make your pathnames in your programs? Do you really define a different string type for different pathnames and file names? Most people would find a String or Unbounded_String acceptable. ... > Purely theoretically it could be C, but > practically the result will be null. Then even Ada is still unsuitable for > this, as long as there is no great type unification, which would allow to > develop user-defined protected objects, tasks, access types etc. > This should become the basic gear to build OS types. Yes of course - ie. it must support the Ada RTL, at least. > I also cannot imagine any > decent OO design of OS without MI, But the O/S has nothing to do with MI, unless it wants to sport an OO interface (which IMHO is unnecessary, at least for many APIs). > MD and interface inheritance from > concrete objects. If you force everything into an object metaphore, you make it difficult for other languages. Frankly, for the services that you get from an O/S, I don't see much point in putting an OO face on it. If you look around, you'll see a number of people are getting less fanatical about objects, and in some cases are talking "services" instead. And that is largely what the operating system provides. But if you say you must have OO interfaces, then the Ada RTL is there to let you model any way you see it. You could even write packages for this, or if you don't like the one you have write alternatives. > Alas there is no visible efforts in these directions. Practical ideas tend to get implemented (and thus become quite visible). Impractical onces either remain dreams or wait for the right opportunity. Either or both could apply, depending upon your expectations ;-) -- Warren W. Gay VE3WWG http://home.cogeco.ca/~ve3wwg