Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: 4ndre4 <626401fd-4bc7-4f8f-b641-563ae0f72920@626401fd-4bc7-4f8f-b641-563ae0f72920.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: double == double
Date: Mon, 17 Oct 2016 22:46:25 +0100
Organization: A noiseless patient Spider
Lines: 37
Message-ID: <nu3gr1$8g8$2@dont-email.me>
References: <double-20161012130409@ram.dialup.fu-berlin.de> <ntledh$lfi$1@dont-email.me> <8737k0qd38.fsf@golem.phantasia.org> <87zim5es30.fsf@golem.phantasia.org> <nttf6l$nml$1@gioia.aioe.org> <ntu9de$6uj$1@dont-email.me> <ntuhmi$cdr$1@gioia.aioe.org> <ntuntn$slf$2@dont-email.me> <nu00a0$5sj$1@gioia.aioe.org> <nu00ks$edh$5@dont-email.me> <nu063a$edp$1@gioia.aioe.org> <nu075n$4cs$1@dont-email.me> <nu0bcj$nbt$1@gioia.aioe.org> <nu0dsb$kv3$3@dont-email.me> <nu0g1b$vt5$2@gioia.aioe.org> <nu0qtc$eiu$1@dont-email.me> <nu1e88$9gn$1@gioia.aioe.org> <be7ba475-196e-4269-8b6e-e4a88f8305f1@googlegroups.com> <nu30a0$j0r$1@newsreader4.netcologne.de> <nu382t$pf6$1@dont-email.me> <nu3eq2$tv6$1@newsreader4.netcologne.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 17 Oct 2016 21:46:09 -0000 (UTC)
Injection-Info: mx02.eternal-september.org; posting-host="1ea135709dba7cad19ecf1e448ead2d9"; logging-data="8712"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19eQuYfu1bf1rDJfoDtgBz1"
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
In-Reply-To: <nu3eq2$tv6$1@newsreader4.netcologne.de>
Cancel-Lock: sha1:xtDgT0yMzIvbj4K93peaehYgtFc=
Xref: csiph.com comp.lang.java.programmer:35807

On 17/10/2016 22:11, Patrick Roemer wrote:

[...]
> The claim was that the Java Math.max() implementation is an example of
> "how OO is normally implemented".

By "how OO is normally implemented" I meant having methods that act on 
data, which is exactly what happens within a class. I admit that the 
max() example was unfortunate.

The problem is where encapsulation stops. If you have a class C 
containing data D and methods M that act on those data:

C:
    D
    M(D)

within C you have the same problem: a procedural model.

This is what happens in many OO languages and it's accepted as normal.

It can also be seen as one of the many reasons a class' responsibility 
should be very limited.

I wish we were able to define "domain" types just as with databases: if 
you need a 'Money' type, you create a type based on a more primitive 
type (BCD decimal with 15 digits, of which 4 decimal, for example). At 
that point, you can declare columns of that type. The 'Money' type would 
not *contain* a BCD decimal, it would actually *be* a BCD decimal, with 
its own validation rules. In Java, instead, you'd only have a Money 
class wrapping around a BigDecimal, and handle the BigDecimal inside, 
with a procedural approach.

But I am rambling now :)

-- 
4ndre4