properties a language need to permit clean OOP [OOP]

Prev: Construction of large object
Next: Free Session Tonight on Example Driven Development w Fit - London

From: topmind on 25 Oct 2007 11:49

From: S Perryman on 25 Oct 2007 12:06

topmind wrote:

> Dmitry A. Kazakov wrote:

>>On Wed, 24 Oct 2007 10:12:28 +0100, S Perryman wrote:

SK>Apart from meta-typing problem domains (if an object supports this
SK>property but not that one, do this or do that etc) , there is nothing
SK>weakly-typed langs/envs can do appreciably faster/safer than a strongly-
SK>typed equivalent.

>>Yes, but there is a lack of simple constructs to produce new types without
>>excessive [keyboard] typing. I understand why some programmers get
>>frustrated. We need better type systems.

> Or get rid of type systems. We don't need them for many domains. Lack
> of types often makes the code more compact and more self-explanatory
> in my opinion. But, this is yet another Type Fight topic where nobody
> can prove that their favorite is objectively better.

Yes I can.
Pick any part of the text labelled "SP" , and tell me what I cannot show
objectively. Here are the time-honoured CS criteria by which *everything*
can be judged :

- Correctness/safety
- Understanding
- Efficiency

Off you go then. I will be waiting ...

Regards,
Steven Perryman

From: S Perryman on 25 Oct 2007 12:33

Dmitry A. Kazakov wrote:

> On Wed, 24 Oct 2007 10:12:28 +0100, S Perryman wrote:

>>Apart from meta-typing problem domains (if an object supports this
>>property but not that one, do this or do that etc) , there is nothing
>>weakly-typed langs/envs can do appreciably faster/safer than a strongly-
>>typed equivalent.

> Yes, but there is a lack of simple constructs to produce new types without
> excessive [keyboard] typing. I understand why some programmers get
> frustrated. We need better type systems.

Type inferencing takes away a lot of the grief of manifest typing.
No explicit type name has to be defined/given. And if you want manifest
types, the type system has already defined the type (naming the type is a
cut/paste job) .

However, much more sophisticated type concepts (substitutable except for
.... etc) , more keyboard typing would be needed.

[ snip ... ]

>>The concept of reference ( "that one" as opposed to "the one which is/has
>>..." ) is an important one.

>>Consider identical siblings (twins etc) .

>>In a domain that distinguishes them by human notions such as name, failure
>>is possible due to name change by deed poll etc. Physically, they are
>>indistinguishable (ie their "values" are equal) .

>>To guarantee identity, I would need the most precise GPS coordinates
>>possible (a box bounding their physical dimensions exacrly) . And those
>>coords would have to continuously change too. :-)

>>The questions are :

>>- how much additional domain information needs to be provided to ensure
>> that the notion of identity is correctly provided

>>- what are the consequences of managing that info (the GPS example etc)

> OK, but to me this is not the concept of reference. It is rather the
> concept of a non-copyable objects.

Not quite.
There is a notion of object as 'encapsulator' of state.
Where state (as discussed) is a collection of values.

Two encapsulations can refer to the same values (as would be the case in
an underlying std FP impl) . However the references are not the same.
The real-world analogy (ie the twins) is that the encapsulations provide
identity when state is the same.

So in your terms, the encapsulation/reference is non-copyable.
But the state (values) are.

> I don't need to deal with addresses to
> achieve that. I don't even need to have them physically non-copyable.
[snip ... ]

However you do it is fine. But you must provide distinction between
identities when states are equal. Sometimes attempting to provide
additional (extra-domain) info to provide that distinction (the perpetual
GPS logging of the twins' locations etc) is too much.

> What I don't want is the language dictating me how
> I implement my identities. And reverse, if my implementation is a
> reference, for some reason unrelated to the problem space, then I should be
> able to hide that from the clients.

Agreed.

Regards,
Steven Perryman

From: Dmitry A. Kazakov on 26 Oct 2007 15:11

On Thu, 25 Oct 2007 17:33:59 +0100, S Perryman wrote:

> Dmitry A. Kazakov wrote:
>
>> On Wed, 24 Oct 2007 10:12:28 +0100, S Perryman wrote:
>
>>>Apart from meta-typing problem domains (if an object supports this
>>>property but not that one, do this or do that etc) , there is nothing
>>>weakly-typed langs/envs can do appreciably faster/safer than a strongly-
>>>typed equivalent.
>
>> Yes, but there is a lack of simple constructs to produce new types without
>> excessive [keyboard] typing. I understand why some programmers get
>> frustrated. We need better type systems.
>
> Type inferencing takes away a lot of the grief of manifest typing.

Yes, but inference shall be A) very flat, so the reader would be able to
infer *same* on the fly, B) unambiguous, C) have a source to infer from.

For these reasons I don't believe much in inference. Especially these
limitations (especially C) might in the end restrict the type in order to
allow inference.

>>>The concept of reference ( "that one" as opposed to "the one which is/has
>>>..." ) is an important one.
>
>>>Consider identical siblings (twins etc) .
>
>>>In a domain that distinguishes them by human notions such as name, failure
>>>is possible due to name change by deed poll etc. Physically, they are
>>>indistinguishable (ie their "values" are equal) .
>
>>>To guarantee identity, I would need the most precise GPS coordinates
>>>possible (a box bounding their physical dimensions exacrly) . And those
>>>coords would have to continuously change too. :-)
>
>>>The questions are :
>
>>>- how much additional domain information needs to be provided to ensure
>>> that the notion of identity is correctly provided
>
>>>- what are the consequences of managing that info (the GPS example etc)
>
>> OK, but to me this is not the concept of reference. It is rather the
>> concept of a non-copyable objects.
>
> Not quite.
> There is a notion of object as 'encapsulator' of state.
> Where state (as discussed) is a collection of values.
>
> Two encapsulations can refer to the same values (as would be the case in
> an underlying std FP impl) . However the references are not the same.
> The real-world analogy (ie the twins) is that the encapsulations provide
> identity when state is the same.
>
> So in your terms, the encapsulation/reference is non-copyable.
> But the state (values) are.

Yes, but this is only an abstraction. There always exists a level where I
can copy. Technically I create the pair (identity, value) and this can be
copied again. Whatever test one can invent to distinguish twins there is a
countermeasure: to copy atoms ("what is your name" identity), to copy the
planet ("what are the GPS coordinates") etc. There is no magic in identity,
it is a restriction we put on the model.

>> I don't need to deal with addresses to
>> achieve that. I don't even need to have them physically non-copyable.
> [snip ... ]
>
> However you do it is fine. But you must provide distinction between
> identities when states are equal.

Right. Sometimes address is a very bad identity, like in distributed
environment, or for persistent objects.

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

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