Re: Writing an Operating System in Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Wed, 13 Jan 2010 14:50:50 -0800 (PST), Shark8 wrote:

>>> If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005
>>> interfaces handle that pretty well.
>>
>> There shall be no interfaces at all. Ada 95 had everything needed, i.e.
>> abstract types. Introducing interfaces in Ada 2005 was a huge mistake.
> 
> Why do you say that?

Because there should be a honest MI and no interfaces. 

> I see them as just being a contract for functions/
> procedures that some object must provide, and in that sense there is
> no reason why an actual object-class cannot agree to one or more of
> these 'contracts'. One nice thing Delphi did was to allow an interface
> to be implemented by a field of the class, they called this "interface
> delegation" and looked something like this:
> Type TExample = Class(TObject, IDelegated)
>   private
>    DelegationField : TSomeDelegatedObject;
>   public
>    property Delagator : TSomeDelegatedObject read DelegationField
> write DelegationField implements IDelegated;
> end; //Example

You do not need explicitly named contracts in a language like Ada. The
contract of a type is the type itself. Ada has type declarations, public
and private. Everything visible related to the type is the contract of.
Period.

> I suppose you could call it 'subcontracting'.

There should be plain interface inheritance instead.

If you wanted the type S to implement the interface of the type T *without*
inheriting the implementation of T, you should be able to tell just so. 

Rather than *in advance* trying to declare all possible interfaces. It is
awful and leads to an explosion of meaningless declarations like:

   type T_Interface is interface ... ; -- Just in case we would need it!
   procedure Foo (X : T_Interface) is abstract;
   type T is new T_Interface with ...; -- No we starting to work
   overriding procedure Foo (X : T);

That is a mess and a maintenance disaster.

>>> If the drive is a dictionary, the entries are the particular files/
>>> directories/objects thereon, but it is pretty useless to give someone
>>> a dictionary in a language they can't read.
>>
>> No, it only means that the object called dictionary is supported and other
>> objects called articles are not. The same error was made by the relational
>> data bases, they understand the structure of relations (relational
>> algebra), but do not do the elements of the tuples.
> 
> I think we have a failure-to-communicate here. I agree that relational
> algebra [blindly] works on tuples w/o knowing about the contents...
> that is in a sort of abstract fashion.
> 
> If we use metaphor/allegory for the data-system [hard-drive, FS, data]
> would you agree that it could be likened to the following?
> The hard-drive is like unto a library containing books.
> The books of that library are like unto the data/files.
> The FS is like unto the indexing system (alphabetically by title,
> alphabetically by author, dewy-decimal, etc) coupled with the
> methodology for storing the 'books' (are they in boxes, on shelves, in
> a pile, etc).
> 
> Can we both agree on this?

Sure. Translated to OO: FS is a specialized persistent container library.

>>>> Without MI, MD, tagged tasks, there is no chance to get
>>>> it right.
>>
>>
>>> If MD is multiple dispatch then we're talking about something that
>>> simply explodes combinatorically-speaking: Say we have a multi-
>>> dispatch procedure with two dispatching parameters [Letter and
>>> Number], ok? Now, if we have two versions of each of those in the
>>> classes we get something like:
>>> (A,1)
>>> (A,2)
>>> (B,1)
>>> (B,2)
>>
>> Yes. Let you have printer devices and shapes. This is a classical example
>> of MD. Yes, it explodes. That is the law of nature. There is nothing to do
>> about it, with MD support or without it, you have these combinations, you
>> have to handle them. MD does not solve this, it merely provides an
>> infrastructure helping you to solve this. No more, no less.
> 
> Ah, I think I was confusing the problem with that infrastructure
> then...
> 
> But that does remind me, I was thinking it would be good to have
> PostScript as the display for the OS, unifying the visual display that
> way it would eliminate the need for printer drivers (assuming they're
> postscript printers) as well as providing a true WYSIWYG for print-
> preview (MS's print preview can be a bit... inaccurate), right?

Right, but in an OO system you would barely need PostScript. I doubt
anybody would like to program in PostScript, so what is left? Poor as a
data carrier, unusable for humans. Doesn't it remind something? XML? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de