Re: Securing type extensions

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

On Thu, 16 Sep 2010 13:52:36 +0200, Georg Bauhaus wrote:

> On 16.09.10 09:47, Dmitry A. Kazakov wrote:
> 
>>> Certainly, and a "plan" suffices as an example, if you agree
>>> that perfect technical specifications of what (again, just for the
>>> sake of an example) a type writer expects an extension writer to
>>> do are not always possible. (Which I understand you do.)
>> 
>> That is not the type writer.
> 
> 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.

> What technical factors of a language's type extension mechanism
> will likely make X and Y be more confident that nothing will
> go wrong?

None, not needed, impossible anyway.

>>> The issue is related to trust, and to type extension, and it is an
>>> existing challenge.
>>> Call it poor design on the part of Python framework writers, if that
>>> is what it seems to be.   But since the framework exists as a foundation
>>> for real software, it does affect multi-party work. We can't always
>>> control the parent types, and must see if we can find it trustworthy.
>> 
>> and the point is? 
> 
> The point is to fathom the dark waters of software development
> from multiple components, of possibly closed source:
> Is there anything in Ada that acts like a flash light when
> compared to more dynamic languages?

Separation of interface and implementation. Strong, static, manifested
typing. Static analysis. Least assumption design principle.

> Facilities of Ada that makes
> one feel more secure when extending a type?

Classes consistently mapped onto types.

> (You remember the story often told about Roman bridge builders
> having to stand under their new bridge on opening day. Just to
> illustrate trust.)

Huh, it is the pedestrians to stay under the bridge. For the most recent
example see:
http://www.wired.com/threatlevel/2010/09/first-sale-doctrine/

>> The way you described it, trust has no physical meaning.
> 
> When you sign a contract with your name, then this is quite physical.

If only signatures could make programs working...

> When you pay, or don't pay, this is easily measured.

Measured what? Do you trust Microsoft?

>> It is a
>> psychological phenomenon, not a subject of CS and SW engineering.
> 
> Psychology, politics, ambition and money are undoubtably parts of
> SW engineering, steering the decisions. They are essential to
> engineering in general.

As a framework they are. That does not make them engineering.

> This famous rocket did not have an O-ring suitable for the range of
> temperatures, they say, and then it exploded.  There had been some
> protest before the parts were composed to form the rocket. An example
> showing that engineering is not just about technical formulas.

Which was a perfect example of the opposite - of how engineering was
defeated by trust. They trusted in that the rocket would not explode.
People used to trust in silly things. Engineers are those who do not trust.

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