Prev: Construction of large object
Next: Free Session Tonight on Example Driven Development w Fit - London
From: alexandre_paterson on 21 Oct 2007 00:46
Hi c.o.,

are there a set of fundamental properties a language
needs absolutely to be an "OOP language" ?

Can we say that an "OOP language" is a language that
allows to do OO programming (say from a nice OOD)
without having the limitations of the language turning the
program into an inextricable mess ?

dynamic typing ?
static typing ?
strongly typed or not?
closures?
multiple (interface?) inheritance?
support in the language for DbC?
pointcuts?
thread support?
awareness of the 'nil' concept?

What would be the "properties" of an OO language ?

Once it comes to translating an OO design into
a program that actually does something in the
real-world [TM], are there pratical choices other
than third-generation languages ?

Btw, I'm in my mid-thirties and, no, this is not
homework ;)

Alex

From: Dmitry A. Kazakov on 21 Oct 2007 04:08
On Sat, 20 Oct 2007 21:46:26 -0700, alexandre_paterson(a)yahoo.fr wrote:

> are there a set of fundamental properties a language
> needs absolutely to be an "OOP language" ?

A type system with sets of types and objects of the closures of.
(polymorphic objects)

> Can we say that an "OOP language" is a language that
> allows to do OO programming (say from a nice OOD)
> without having the limitations of the language turning the
> program into an inextricable mess ?
>
> dynamic typing ?
No, it is compiler's impotence.

> static typing ?
Yes

> strongly typed or not?
Strongly

> closures?
Downward only

> multiple (interface?) inheritance?
Both, and interface inheritance from concrete types.

> support in the language for DbC?
Yes

> pointcuts?
?

> thread support?
Concurrency support you mean. Yes, integrated in the types system.
(difficult to do)

> awareness of the 'nil' concept?
No

+
1. Multiple dispatch (difficult to do)
2. No redispatch
3. Contracted exception model
4. Abstract interfaces of primitive containers (records and arrays)
5. Abstract interface of referential types (AKA pointers)
6. Supertyping
7. Resolved parallel types hierarchies problem (difficult to do)
8. Classes and inheritance for all types

> What would be the "properties" of an OO language ?
>
> Once it comes to translating an OO design into
> a program that actually does something in the
> real-world [TM], are there pratical choices other
> than third-generation languages ?

1. Consistency
2. Safety
3. Regularity
4. Static analysis
5. A much smaller language with almost no built-in types
6. OO design at the language level
(intermediate languages ruin design and maintenance process, we should
return to sanity)

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: S Perryman on 21 Oct 2007 06:41
Dmitry A. Kazakov wrote:

> On Sat, 20 Oct 2007 21:46:26 -0700, alexandre_paterson(a)yahoo.fr wrote:

>>Can we say that an "OOP language" is a language that
>>allows to do OO programming (say from a nice OOD)
>>without having the limitations of the language turning the
>>program into an inextricable mess ?

>>dynamic typing ?

> No, it is compiler's impotence.

Nothing wrong with dynamic type checking.

Of course I by "dynamic" I mean a type system that executes at runtime
and finds errors at the *exact point* that a static type checker does
(which is *not* the "message not understood" errors of weakly-typed
prog langs) .


>>static typing ?

> Yes

>>strongly typed or not?

> Strongly

Strong typing.
The ability to turn on/off static checking on demand (as with Lisp envs
etc) .


>>multiple (interface?) inheritance?

> Both, and interface inheritance from concrete types.

Break from the Simula model : inherit from X != substitutable for X.


>>support in the language for DbC?

> Yes

Support for the definition of correctness artifacts.
And an env that can make them available to other tools (DbC
generators, proof systems etc) .


>>pointcuts?

That is aspect-oriented programming.


>>thread support?

> Concurrency support you mean. Yes, integrated in the types system.
> (difficult to do)

Where possible, I prefer orthogonality.
Minimal support in prog langs should be given to allow differing schemes
(the "select" , Eiffel SCOOP etc) to be easily implementable.


> +
> 1. Multiple dispatch (difficult to do)

Provide it as best one can (correctness, efficiency etc) .


> 2. No redispatch

The ability to decide the level of dispatch for various type families
(none, single, multiple) .


> 5. Abstract interface of referential types (AKA pointers)

Such as Simulas' "ref(X)" type ??


> 6. Supertyping

Liskov/Wing subtype as the std model.
The ability to explicitly declare deviations to the type system (to
allow the 9x% substitutable types to be used when an L/W -
100% - definition does not) .


+

The ability to refer to objects as typed tuple instances, to allow
relational algebra to be used.


Regards,
Steven Perryman
From: Dmitry A. Kazakov on 21 Oct 2007 08:49
On Sun, 21 Oct 2007 11:41:39 +0100, S Perryman wrote:

> Dmitry A. Kazakov wrote:
>
>> On Sat, 20 Oct 2007 21:46:26 -0700, alexandre_paterson(a)yahoo.fr wrote:
>
>>>dynamic typing ?
>
>> No, it is compiler's impotence.
>
> Nothing wrong with dynamic type checking.

As I see it, the language should separate types and subtypes, hence types
and constraints checking. I strongly believe that there is no place for
dynamic type checks, as all of them can be performed statically.
Constraints can be checked dynamically. [Downcasting is a
constraint/subtype conformance check.]

[ It is a question of definition, IMO. I tend to name statically checkable
groups of things as types. So if non-static then untyped. (:-)) ]

>>>strongly typed or not?
>
>> Strongly
>
> Strong typing.
> The ability to turn on/off static checking on demand (as with Lisp envs
> etc) .

In my view there would be no need in that if the language allowed to
create/denote a corresponding class of types. I.e. instead of brutally
turning checks off, we would simply satisfy them.

>>>multiple (interface?) inheritance?
>
>> Both, and interface inheritance from concrete types.
>
> Break from the Simula model : inherit from X != substitutable for X.

Conditional substitutability.

>> Concurrency support you mean. Yes, integrated in the types system.
>> (difficult to do)
>
> Where possible, I prefer orthogonality.
> Minimal support in prog langs should be given to allow differing schemes
> (the "select" , Eiffel SCOOP etc) to be easily implementable.

It was attempted in Ada and that made the language too complex. I think
that an orthogonality in the end would be incompatible with DbC. This is a
big issue, as multi-core architectures and distributed systems have
arrived.

>> 5. Abstract interface of referential types (AKA pointers)
>
> Such as Simulas' "ref(X)" type ??

So that the semantics of referencing and dereferencing could be defined by
the user and contracted. And with interface inheritance and supertyping, a
reference could be made a full equivalent (substitutable) to its target.

[ + Delegation support ]

> +
>
> The ability to refer to objects as typed tuple instances, to allow
> relational algebra to be used.

Yes, but that could be automatically covered by abstract record interfaces.
Tuple is just a record.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: H. S. Lahman on 21 Oct 2007 11:06
Responding to Alexandre_paterso...

> are there a set of fundamental properties a language
> needs absolutely to be an "OOP language" ?

Not really. An OOPL provides tactical implementation of an OOA/D
solution in a particular computing environment. It needs whatever
features developers feel will make that implementation easier.
Presumably it would be convenient if the OOPL had syntactic features
that mapped close to 1:1 to OOA/D concepts and abstractions. However,
that is not strictly necessary (e.g., full code generators for UML OOA
models routinely target straight C for performance reasons).

> Can we say that an "OOP language" is a language that
> allows to do OO programming (say from a nice OOD)
> without having the limitations of the language turning the
> program into an inextricable mess ?

3GLs by their very nature have to make compromises with the hardware
computational models. For example...

>
> dynamic typing ?
> static typing ?
> strongly typed or not?

Type systems are artifacts of the 3GL level of abstraction and don't
exist in OOA/D (other than as knowledge attribute ADTs). Thus dynamic
vs. static typing becomes a comfort issue for the OOP developer.

OTOH, strong typing is generally regarded as useful for any programming
language. One of my favorite quotes is by a fellow named Lahovsky who
was one of the designers of the BLISS language, which is essentially
untyped, "When I program in BLISS I feel that I am in complete control
of the machine. But when I program in Pascal, my programs tend to work
the first time."

> closures?

Depends on how one defines 'closure'. Thus the OO paradigm employs
entirely different mechanisms to achieve closures than FPLs.

> multiple (interface?) inheritance?

Both interface and multiple inheritance are probably desirable features
because they map nicely to OOA/D generalization and polymorphic
dispatch. But multiple inheritance is an example of an OOPL syntactic
feature that can be badly abused.

> support in the language for DbC?

This would be nice for any 3GL. Note, though, that DbC goes well beyond
the sort of diagnostic support provided by Effel-like assertions. Design
level DbC is actually supported much better methodologically at the
OOA/D level where one can use an asynchronous model for behavior
communications.

> pointcuts?

Sure. Whatever works.

> thread support?

This is not an OO issue. The hardware computational models are
inherently synchronous and serial so one always has to bootstrap
asynchronous and concurrent behavior in software (or firmware). Whether
one provides the bootstrap infrastructure in the OS or a 3GL really
doesn't matter very much.

> awareness of the 'nil' concept?

Which one? B-)

>
> What would be the "properties" of an OO language ?
>
> Once it comes to translating an OO design into
> a program that actually does something in the
> real-world [TM], are there pratical choices other
> than third-generation languages ?

When I started out ('57) there were no linkers or loaders and 3GLs were
academic curiosities; BAL was the silver bullet that would solve the
software crisis. However, the computing space is inherently
deterministic because it is based on mathematical models. So automation
has advanced steadily since because optimization in the computing space
is an engineering problem that does not require scientific breakthroughs.

So it was inevitable that 4GLs would evolve where translation tools
would automate the computing environment and problems could be solved in
terms of customer domains rather than computing domains. That first
happened in isolated niches like electronics test (e.g., the C/ATLAS
standard allows direct compilation of requirements specifications) and
RAD IDEs (e.g., Access and Delphi where CRUD/USER processing can be
highly abstracted in terms of forms and the RDM).

However, the computing space is vast and complex so optimization for
general computing is a daunting engineering problem. Though 4GLs and
supporting translation tools were available in the early '80s, they did
not provide competitive optimization until the late '90s. OMG has also
provided badly needed standardization with UML and MDA starting in the
late '90s. But the tools are now there and major players in the software
industry are climbing all over each other to establish market position
by buying up the old translation vendors.

So to answer your question, it is really academic. The next major
paradigm shift in computing is upon us in the form of 4GLs. As I
mentioned above, full code generators don't need to target an OOPL and
since the target code does not have to be maintained, the application
developers don't care what 3GL is targeted. So the day is rapidly
approaching when the only people who will have an interest in the
question will be those writing 4GL compilers. Which comes full circle to
my original point: what they want are features that map conveniently to
the 4GL constructs.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl(a)pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info(a)pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



 |  Next  |  Last
Pages: 1 2 3
Prev: Construction of large object
Next: Free Session Tonight on Example Driven Development w Fit - London