Path: csiph.com!news.mixmin.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.xdsl-87-78-189-45.netcologne.de!not-for-mail
From: Patrick Roemer <sangamon@netcologne.de>
Newsgroups: comp.lang.java.programmer
Subject: Re: double == double
Date: Thu, 20 Oct 2016 15:01:15 +0200
Organization: news.netcologne.de
Distribution: world
Message-ID: <nuaf6r$eop$1@newsreader4.netcologne.de>
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> <nu2vv1$ikt$1@newsreader4.netcologne.de> <nu97n6$fs1$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 20 Oct 2016 13:01:15 +0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="xdsl-87-78-189-45.netcologne.de:87.78.189.45"; logging-data="15129"; mail-complaints-to="abuse@netcologne.de"
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.24) Gecko/20100411 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0
X-Mozilla-News-Host: news://news.netcologne.de
In-Reply-To: <nu97n6$fs1$1@gioia.aioe.org>
Xref: csiph.com comp.lang.java.programmer:35849

Responding to Arne Vajhøj:
> On 10/17/2016 12:58 PM, Patrick Roemer wrote:
>> Responding to Arne Vajhøj:
>>> On 10/16/2016 5:19 PM, 4ndre4 wrote:
>>>> On 16/10/2016 19:14, Arne Vajhøj wrote:
>>>>
>>>> [...]
>>>>> But that code is not using String as version
>>>>
>>>> Erm... how about this? :) I don't see how this is less OO-ish than the
>>>> previous one, but hey... okay!...:
>>>>
>>>>         List<String> versions = new ArrayList<String>();
>>>>
>>>>         versions.add("1.9.0-123");
>>>>         versions.add("1.10.0-123");
>>>>         versions.add("1.7.0-123");
>>>>         versions.add("1.7.0-123");
>>>>         versions.add("1.7.0-10");
>>>>         versions.add("1.7.0-9");
>>>>
>>>>         Collections.sort(versions, new VersionComparator());
>>>>
>>>> ...
>>>>
>>>> static class VersionComparator implements Comparator<String> {
>>>
>>>>         public int compare(String version1, String version2) {
>>>>             try {
>>>>                 ParsedVersion pv1 = parse(version1);
>>>>                 ParsedVersion pv2 = parse(version2);
>>>>                 if (pv1.equals(pv2)) return 0;
>>>>                 if (pv1.lessThan(pv2)) return -1;
>>>>                 return 1;
>>>>             } catch (InvalidVersionException e) {
>>>>                 throw new IllegalArgumentException(e);
>>>>             }
>>>>         }
>>>
>>> Having data and methods operating on the data separate is
>>> very non-OO'ish in my book.
>>
>> I don't think this describes the actual problem well. There may be
>> perfectly good, OO-compatible reasons to separate comparison logic from
>> the domain class - after all, that's why Comparator exists. For example,
>> there may be occasions when one wants to compare only based on the major
>> (major + minor,...) version parts.
> 
> The problem is not so much with the Comparator.
> 
> As you say then it is perfectly valid to have an external
> Comparator that matches the logic in the code doing the sort
> (or whatever).
> 
> The problem is with the parse code that is very much tied to the
> internal structure of the String.
> 
> Having that parse code in many different places will be a
> maintenance nightmare.
>
> And if the ParsedVersion and the parse code is made public
> and reused then we have the Version class back and there
> is little reason to use the String format except for
> input and output.

Agreed. But I wouldn't necessarily want to have the parse code in the
Version class, either. There may be different string formats from
different sources ("1.2.3.4" vs "1.2.3-004"), or there may even be other
representations than strings I want to convert from. Having just a plain
Version(int, int, int, int) constructor and offloading parsing to
dedicated classes might be a reasonable choice, and it'd still be in
line with OO principles. The main problem with the given code isn't
having methods and data separate, it's not having a Version type, and
that's not an OO specific problem.

>> But this code defies a more general programming principle: Describe your
>> concepts as dedicated types and define operations for those types.
>> Passing an opaque string around to be interpreted as a version only
>> "when needed" feels fishy to me in any paradigm.
> 
> That is very aligned with OOP.
> 
> But yes - you could do something sort of similar procedural even
> though it may start to be more like OOP in a non-OO language then.

In proper procedural, you'd have a Version record type and procedures
acting upon it. In proper functional you'd have a Version data type and
functions acting upon it. That's an overarching principle, nothing
specific to OO.

Here's a functional semantic version library, for example:

https://hackage.haskell.org/package/semver-0.3.3.1/docs/Data-SemVer.html

Using a String as a version representation would be as silly there as
anywhere else. And if you suggested to the Haskell guys that they were
emulating OO, they'd laugh you out of the room.

Best regards,
Patrick