Re: Securing type extensions

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

On Fri, 17 Sep 2010 10:45:48 +0200, Georg Bauhaus wrote:

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

class = set of types

> and "spcification"

class specification = the interface of

> and "implementation"

class instance implementation = the implementation of a type, a member of
the class

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

When you derive from the interface of a class (technically you do from the
root type) you sign up to the contract the interface describes. The
contract relationship is not between you and the class designer because you
are among its designers as well. It is not between you and the designer of
the type you derive from. He has no responsibilities for you, which is an
important advantage for a long-term developing process. The contract is
between you and someone who uses the class in his code.

interface designer <-> state passing regulation rules for car safety
You <-> car manufacturer
client <-> car driver

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

Sorry for that, but you have no choice.

>> Do *you* trust Microsoft?
> 
> The one thing that does not matter in discussing general rules
> should be one's own specific attitude.

Great, both of us do not trust them, but in our own interest they are
considered trustworthy. That sounds familiar... (:-))

> Visual Studio is *of* *course* changed in incompatible ways!

That "of course" directly follows from "trustworthiness", I bet? (:-))

> but they nevertheless buy because they trust programming with
> MS VS will still provide for a living.

No, they do because Microsoft maintains a monopoly.

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