Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (athena.apache.org: domain of simone.tripodi@gmail.com
 designates 209.85.216.50 as permitted sender)
MIME-Version: 1.0
Sender: simone.tripodi@gmail.com
In-Reply-To: <4F383F03.2020402@dia.uniroma3.it>
References: <4EDC0593.5070200@dia.uniroma3.it>
	<CAHQS_ey1Fq-024w0ZLeudfpRU=sb+XxMLVY1+0MtcM_xfeH6AA@mail.gmail.com>
	<CAAqLGLPU3YaszuaAGuHpsjc5RuNoq7kED4DKJ-naXj5YxzyTKw@mail.gmail.com>
	<CAHQS_ez0C_YfGjg30bjtbewpTTPLZaqBDnZ-=SMGszOhPdthUw@mail.gmail.com>
	<CAAqLGLMJmuABvXHM-8tYLhYtONW5sJJ=rCPF_ZuFVBpZcbXEMw@mail.gmail.com>
	<CAHQS_exqJ-u+am63o4xVTXPjc037DpjGuX=_ueKnOrnmarf=hw@mail.gmail.com>
	<49628.31.191.72.0.1324659757.squirrel@email.dia.uniroma3.it>
	<CAAqLGLOpxiZ6QSCkUZKx13Fp+mXqHRs1vMFBiGp3LVtSaVy7rw@mail.gmail.com>
	<4F09D48E.6010905@dia.uniroma3.it>
	<CAAqLGLNowi9DmfyfRsOrCKMxb-J3TE-5T21gmbZ_RvydTUXh=w@mail.gmail.com>
	<4F0EBF67.7040900@dia.uniroma3.it>
	<CAAqLGLMT10=0S=cP7YPu8JPE04TbaTLrZwohivUTd13yz_YUTw@mail.gmail.com>
	<41C26625-224D-4F54-9DCE-A8695CB0FD74@gmail.com>
	<4F37EA93.6050807@dia.uniroma3.it>
	<CAAqLGLPbz2tjZOZkX54ixvs4o1j=4r0R9A1g91iU-PXGO1UC_Q@mail.gmail.com>
	<4F381F1B.1030602@dia.uniroma3.it>
	<8528DD9A-521A-4921-B935-0A8B69EB715A@gmail.com>
	<4F383F03.2020402@dia.uniroma3.it>
Date: Sun, 12 Feb 2012 23:43:40 +0100
Message-ID: 
 <CAAqLGLNVoFog7vGXrmnmX6xY789Dbhd=w+hXS0h1qaho4XnpVQ@mail.gmail.com>
Subject: Re: [Graph] On graph weight type(s)
From: Simone Tripodi <simonetripodi@apache.org>
To: Commons Developers List <dev@commons.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hola Claudio,

the patch you mentioned was something I would have asked you, before or lat=
er :P

Since we are on topic: is there any particular reason why Zero.zero()
can not be part of Semigroup interface? Or better: is there any
benefit we can get from keeping Zero and Semigroup separated?

TIA,
-Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/


On Sun, Feb 12, 2012 at 11:36 PM, Claudio Squarcella
<squarcel@dia.uniroma3.it> wrote:
> Hi,
>
>
>>> * the mapping between primitive types and their respective default
>>> =C2=A0 *Operations is known and kept somewhere (abstract class, etc);
>>> * each algorithm specifies only once the set of primitive types that
>>> =C2=A0 it accepts;
>>> * with a bit of magic (?) we combine the above to provide shortcuts to
>>> =C2=A0 the user.
>>
>> +1
>>
>> I think that a mapper can be useful.
>> we can create a default mapper between primitives and *Operations and ad=
d
>> a void API like that
>> findMaxFlow( graph ).from( a ).to( g ).applying<Algorithm>( void ).
>> we can choose the correct Operation mappimng directly on the default
>> constructor using our mapper.
>>
>> so for the primitives Integer, Double etc, the user doesn't =C2=A0have t=
o
>> specify anything.
>
>
> I thought about something similar. But I finally see two downsides:
>
> =C2=A0* we would need to use reflection for generics or some better
> =C2=A0 alternative to actually understand the generic type of weight and
> =C2=A0 map it to the appropriate *Operations,
> =C2=A0* we should throw an exception when non-primitive weights are
> =C2=A0 incorrectly passed without a handler.
>
> Now that I have a clearer picture in mind I'm almost convinced to give up=
...
>
> Anyway, expect a patch soon from me that at least incorporates suggestion=
s
> on new names for primitive implementations and variable names ;)
>
> Ciao,
>
> Claudio
>
> --
> Claudio Squarcella
> PhD student at Roma Tre University
> http://www.dia.uniroma3.it/~squarcel
> http://squarcella.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org