Re: Securing type extensions

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 9/16/10 11:37 PM, Dmitry A. Kazakov wrote:
> On Thu, 16 Sep 2010 22:53:32 +0200, Georg Bauhaus wrote:
>
>> On 9/16/10 2:45 PM, Dmitry A. Kazakov wrote:
>>
>>>> Party X made a library, L, of O-O types, abstract or not.
>>>> Party Y extends a type in L, say T
>>>>
>>>> I'm talking about how X and Y can trust each other before
>>>> X licenses the library and before Y writes an extension.
>>>
>>> They need not.
>>
>> OK, each party to a legal contract may chose to not care
>> about the consequences of joining untrusted partners in software.
>
> You missed the point,

I wonder if we are moving in the same plane at all. ;-)

> there is no such relation between specification
> (class of L) and implementation (member of the class). There is one between
> a client and the provider of an implementation.

-- Toulouse:
package X.L.A is

   type T1 is tagged private;
   -- description, ops
   ...
end X.L.A;

-- Hamburg:
package X.L.B is

   type T2 is abstract tagged private;
   -- description, ops
   ...
end X.L.B;

Company representatives from Toulouse and Munich sign a legal
contract about terms and conditions for use of X.L.

-- Munich:
with X.L.A;
package Y is

    type T is new X.L.A.T1 with private;
    -- overridings
    ...
end Y;

I am trying to understand what you are referring to using "class"
and "spcification" and "implementation". (When I said something
about company representatives signing a legal contract
about software and why they feel they can trust each other to
a certain extent  ...).

Is "class of L" referring to {T1'Class, T2'Class}?

What are the clients and implementations in X.L.* and
Y, respectively?

Is there a relation of (some) trust (state of a human being)
between Munich's Y.T programmers/managers and Toulouse's X.L.A.T1
programmers/managers?



>> The purpose of signatures put under a software contract
>> is to express something related to trust and mistrust.
>> Typically, there is a sentence like "we cannot be held
>> responsible for ... the usual stuff you have in software.
>> But otherwise, ...".
>
> I see, when you sign up to a no-warranty software licensing agreement that
> generates a huge amount of trust! Not to me, I know they swindled me again.

I see no reason to sign a contract absent any kind of
obligation.

   Here's an example of trust, showing that trust is not a
binary thing (as  "trust more than" indicates):

   A thief engineer (E1) plans to rely on a few  other
thief engineers (E2, E3). They plan a technically challenging
robbery.  On site, E2 performs almost as expected, the robbery
succeeds, but E2 runs away with half of the haul when he was
supposed to carry one third.  Partial success.

  If and only if E1 and E3 can live with the result, trusting E2
was justified, whatever the concerns may have been, or will be.



> Do *you* trust Microsoft?

The one thing that does not matter in discussing general rules
should be one's own specific attitude.

Visual Studio is *of* *course* changed in incompatible ways!
You known that when you buy, you can trust they will have
made a few changes of this kind.  This is two-party business,
not one-group cooperation!  Interests will differ.

When dealing with MS products, many swear and curse, hate them,
the hatred being extended to Microsoft,
but they nevertheless buy because they trust programming with
MS VS will still provide for a living.

A good opportunity to remember the huge value of standardized
languages, and competing implementations, BTW.


>  Engineering is applying science to solving technical problems.

Which does not define engineering at all: there is no one way to "apply"
(whatever "apply" might mean) the one and only "science". Science,
a term, I think, that is defined only when engineers feel they need
to make a gesture of competence.

What we do when programming is between science and the ideal
of engineering.  Between science and engineering lies _craft_.
There is a preferred scientific method, there are scientific results,
some of them brittle, some preliminary, some rather vague,
many temporary.  Craftspeople deal with this.

If you remember the varied qualities of craftsmanship...

Which brings us back to software libraries and type extensions.

Georg