Skip to main content

Re: AbstractQuantity's class

  • From: Otávio Gonçalves de Santana < >
  • To:
  • Subject: Re: AbstractQuantity's class
  • Date: Wed, 17 Sep 2014 05:57:01 -0300

Yes, you are right.
I put together with the fix in convert.
https://github.com/unitsofmeasurement/unit-impl-se/pull/28


On Wed, Sep 17, 2014 at 5:47 AM, Werner Keil 
< >
 wrote:

> A perfect example would be GenericServlet:
> http://tomcat.apache.org/tomcat-7.0-doc/servletapi/javax/servlet/GenericServlet.html
>
> Most actual servlets may derive from HttpServlet, but there are protocols
> or use cases other than that, which is why both exist.
> Not sure if we could add (abstract) base classes into the API (or SPI;-)
> without being too platform specific or blowing up the single JAR beyond
> reasonable size..?
> Am 17.09.2014 10:34 schrieb "Werner Keil" 
> < >:
>
> That makes less sense, see JScience and other implementations;-)
>>
>> Math and Science, but also other real life usage of them requires being
>> open to new, potentially unknown data types.
>> Complex Numbers, etc. you get such things in GnuMath already.
>> They have no use for concrete limited classes, especially after cropped
>> to just 2, but they need an abstract base class to avoid overhead and
>> possible inconsistencies of boilerplate code;-)
>> Am 17.09.2014 10:24 schrieb "Otávio Gonçalves de Santana" <
>>:
>>
>>> If I hide the AbstractQuantity and expose the implementations?
>>>
>>> On Wed, Sep 17, 2014 at 5:14 AM, Werner Keil 
>>> < >
>>> wrote:
>>>
>>>> Removing of() may work, but I believe a (visible) abstract base class
>>>> (see Measure in ICU4J or similar ones in Android based frameworks like
>>>> OpenXC) is necessary. Similar to the likes of AbstractMap or AbstractList
>>>> in Collections API they provide a common ground for different concrete
>>>> classes used by hundreds of different libraries not just in the JDK or
>>>> JavaEE. It avoids a lot of unneccessary overhead and boilerplate code.
>>>> Some types defined by a random library like Health, Energy, Science,
>>>> etc. will be totally unknown to your SE factory implementation, using
>>>> specific quantity types of their own. That's why abstract base classes
>>>> provide help and guidance without forcing us or users to know every new
>>>> class (we probably needed Reflection again to try btw. if a library wants
>>>> to use factories, I hope you also don't forget about that?;-)
>>>>
>>>> I wished we could add something like it to the API level, but it seems
>>>> to platform specific when it comes to concrete types.
>>>>  Am 17.09.2014 09:24 schrieb "Otávio Gonçalves de Santana" <
>>>>  >:
>>>>
>>>> Another proposal is, remove the factory methods in AbstractQuantity,
>>>>> remove the public in the class and make it visibla just to the package, 
>>>>> and
>>>>> create the QuantityFactory:
>>>>>
>>>>> I saw some advantagens:
>>>>>
>>>>>
>>>>>    - Hide the implementations
>>>>>    - Just show the API
>>>>>    - the client don't need know the implementation
>>>>>    - Single responsability to factory - now one class will do that
>>>>>    - the AbstractQuantity follows the SOLID principle
>>>>>
>>>>>
>>>>> On Tue, Sep 16, 2014 at 3:55 AM, Werner Keil 
>>>>> < >
>>>>> wrote:
>>>>>
>>>>>> That's along the lines of similar ones in JDK or JavaMoney;-)
>>>>>> Would you avoid the of() method in concrete classes to solve Otavio's
>>>>>> Problem/question?
>>>>>>
>>>>>> As Anatole is at Hackergarten, we can probably offer him to join if
>>>>>> he wants.
>>>>>>
>>>>>> Cheers,
>>>>>> W
>>>>>> Am 16.09.2014 08:07 schrieb "Jean-Marie Dautelle" 
>>>>>> <
>>>>>> >:
>>>>>>
>>>>>> Hello,
>>>>>>> Quantities would not extends any class, its purpose is to provide
>>>>>>> static factory method. Starting with Java 8, interface may have static
>>>>>>> factory (but Java 8 it is not your target).
>>>>>>> I would stay away from static factory method, except to get the
>>>>>>> "quantity factory" (cf. unit of measurement 6.x api):
>>>>>>>     MyQuantityFactory.getInstance().newQuantity("10 m");
>>>>>>> Cheers,
>>>>>>> JM
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 16, 2014 at 12:37 AM, Werner Keil 
>>>>>>> <
>>>>>>> > wrote:
>>>>>>>
>>>>>>>> Sorry but it is not the answer to the question you askd, there is
>>>>>>>> no practice (see JSR 354) like MonetaryAmounts.of() or 
>>>>>>>> Collections.of().
>>>>>>>>
>>>>>>>> Those are merely facade methods, a Quantities extends
>>>>>>>> AbstractQuantity makes no sense, it is just wrong.
>>>>>>>> Seems we probably need Hackergarten or the community to ask them
>>>>>>>> for the right name. It certainly is not Quantities based on all 
>>>>>>>> other APIs.
>>>>>>>>
>>>>>>>> Beside, if we start putting such facades like Quantities into the
>>>>>>>> RI, where does that leave the SPI elements or how wold it use them?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, Sep 16, 2014 at 12:28 AM, Werner Keil <
>>>>>>>>  >
>>>>>>>>  wrote:
>>>>>>>>
>>>>>>>>> What exactly should "Quantities" be, a facade like
>>>>>>>>> "MonetaryAmounts", etc. from JavaMoney??
>>>>>>>>>
>>>>>>>>> If it was to replace BaseQuantity, that is not a name for a
>>>>>>>>> concrete class I'm afraid. The TemporalAmount used in JSR 310 is 
>>>>>>>>> actually a
>>>>>>>>> TemporalAmounts (since it represents more than a single amount) but 
>>>>>>>>> if we
>>>>>>>>> had
>>>>>>>>> Quantities extends AbstractQuantity or
>>>>>>>>> Quantities implements Quantity??
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> java.util.Collections does not implement java.util.Collection
>>>>>>>>> either, it is merely a facade, no need for an of() there[?]
>>>>>>>>> So what you suggested would be a facade along the lines of what
>>>>>>>>> Anatole mentioned, but it cannot replace AbstractQuantity.
>>>>>>>>>
>>>>>>>>> Class.of() returns an instance of that class, so a Quantities
>>>>>>>>> facade could offer a method like
>>>>>>>>>
>>>>>>>>> Quantities.getQuantityFactory(), but it  can't extend or implement
>>>>>>>>> Quantity, nor return a Quantity as such via of().
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Werner
>>>>>>>>>
>>>>>>>>> On Mon, Sep 15, 2014 at 11:40 PM, Jean-Marie Dautelle <
>>>>>>>>>  >
>>>>>>>>>  wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>> Indeed, JScience use Amount but with a different semantics (using
>>>>>>>>>> that same name would create for me a headache due to name 
>>>>>>>>>> clashing).
>>>>>>>>>> It should be noted that Amount has to be a class (not an
>>>>>>>>>> interface) in order to provide static factory method (Java 7).
>>>>>>>>>> Usually (at least in JScience), you will have something like
>>>>>>>>>> Amount (interface) and Amounts with terminating s for the class 
>>>>>>>>>> holding
>>>>>>>>>> static factory method to produce Amount instances.
>>>>>>>>>> But since you intend to return Quantity types, I would suggest
>>>>>>>>>> using Quantities.of(100d, SI.METRE) - That would be consistent with
>>>>>>>>>> standard practices.
>>>>>>>>>> Best regards,
>>>>>>>>>> Jean-Marie.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Mon, Sep 15, 2014 at 9:51 PM, Werner Keil <
>>>>>>>>>>  >
>>>>>>>>>>  wrote:
>>>>>>>>>>
>>>>>>>>>>> Dear Experts,
>>>>>>>>>>>
>>>>>>>>>>> If you don't see a conflict between a more general "Amount"
>>>>>>>>>>> class here and other types in different value-oriented APIs like 
>>>>>>>>>>> JSR 354,
>>>>>>>>>>> we may take the inspiration by the likes of JScience or ICU4J, 
>>>>>>>>>>> both using
>>>>>>>>>>> *Amount for such types.
>>>>>>>>>>>
>>>>>>>>>>> ICU4J combines it with things like "Currency" in
>>>>>>>>>>> http://icu-project.org/apiref/icu4j/com/ibm/icu/util/CurrencyAmount.html
>>>>>>>>>>> the other concrete class is even called "TimeUnitAmount", but I
>>>>>>>>>>> would not really see any of those as proper additions either.
>>>>>>>>>>>
>>>>>>>>>>> How do you intend to use the "faster" quantity sub-types,
>>>>>>>>>>> currently all returned by factory methods in AbstractQuantity?
>>>>>>>>>>> The "Amount" type like e.g. that in ICU4J (there it is named
>>>>>>>>>>> Measure, but unlike JSR 363 it does not separate between API and
>>>>>>>>>>> implementation, so everything are classes) holds a Number, so in 
>>>>>>>>>>> theory
>>>>>>>>>>> using different concrete number sub-classes would work for
>>>>>>>>>>> Amount.of(100d, SI.METRE) as opposed to
>>>>>>>>>>> Amount.of(BigDecimal.TEN, SI.METRE) could handle that all.
>>>>>>>>>>>
>>>>>>>>>>> What about alternate classes with a lower footprint, especially
>>>>>>>>>>> in SE? Actually they might matter more, but if using objects like 
>>>>>>>>>>> Double,
>>>>>>>>>>> Integer or Long worked equally well under ME, we could and should 
>>>>>>>>>>> keep that
>>>>>>>>>>> in sync, with the exception of BigDecimal/BigInteger[?]
>>>>>>>>>>>
>>>>>>>>>>> Martin, others WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Werner
>>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 15, 2014 at 9:07 PM, Otávio Gonçalves de Santana <
>>>>>>>>>>>  >
>>>>>>>>>>>  wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Amount.of() sounds good.
>>>>>>>>>>>> On Sep 15, 2014 4:04 PM, "Legrand, Karen" <
>>>>>>>>>>>>  >
>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>  -1 for QuantityAmount.  It looks very odd to have two nouns
>>>>>>>>>>>>> that are essentially synonyms together like that. I think it 
>>>>>>>>>>>>> would be much
>>>>>>>>>>>>> better to use either ‘Quantity’ or ‘Amount’ by itself.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> *From:* Leonardo Lima 
>>>>>>>>>>>>> [mailto: ]
>>>>>>>>>>>>> *Sent:* Monday, September 15, 2014 10:44 AM
>>>>>>>>>>>>> *To:* 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> *Subject:* Re: AbstractQuantity's class
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> QuantityAmount sounds redundant, doesn't it?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 14, 2014 at 9:03 PM, Otávio Gonçalves de Santana <
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Actually I would like to work this and in Lambda expressions.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could be QuantityAmount then?
>>>>>>>>>>>>>
>>>>>>>>>>>>> anyone?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 14, 2014 at 6:06 PM, Werner Keil <
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Since we drop the .org domain soon, I would not call that UOMo
>>>>>>>>>>>>> (the Eclipse project certainly will keep the name, after all it 
>>>>>>>>>>>>> also
>>>>>>>>>>>>> support UCUM which has another .org domain, too)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Why would Quantities get an of() method? What would be
>>>>>>>>>>>>> imaginable is some sort of factory/facade in RI or SE, but 
>>>>>>>>>>>>> except a
>>>>>>>>>>>>> getInstance(Length.class) similar to the current 
>>>>>>>>>>>>> QuantityFactory class
>>>>>>>>>>>>> (it's a singleton returning exactly one instance here, see MEEP 
>>>>>>>>>>>>> or CLDC8,
>>>>>>>>>>>>> they also use both of() and getInstance() for each purpose, 
>>>>>>>>>>>>> just like Josh
>>>>>>>>>>>>> Bloch explained) there is nothing to be of() in this case.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> QuantityAmount sounds like a good alternative of these, let's
>>>>>>>>>>>>> see at JavaOne, probably in Hackergarten what's best.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 14, 2014 at 9:01 PM, Otávio Gonçalves de Santana <
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I am not referring if the classe be or not be abstract or
>>>>>>>>>>>>> design, but just the name, I am talking about the nomenclature.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Could be a good name:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - UOMO.of(...)
>>>>>>>>>>>>>
>>>>>>>>>>>>>  another one is:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - Quantities.of(...)
>>>>>>>>>>>>>
>>>>>>>>>>>>>  or the classic:
>>>>>>>>>>>>>
>>>>>>>>>>>>>    - QuantityAmount.of(...)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 14, 2014 at 2:51 PM, Werner Keil <
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry, no more Measurable, please
>>>>>>>>>>>>>
>>>>>>>>>>>>> We've been there once.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> You bet Spring was probably created a while ago and may not
>>>>>>>>>>>>> follow all patterns we may see now
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Something else e.g. QuantityAmount<Q extends Quantity> extends
>>>>>>>>>>>>> AbstractQuantity<Q> is worth considering, like in UOMo.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> And the subsequent of() methods may be on such a concrete
>>>>>>>>>>>>> class.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If you look at let's say the Collections API, it shows a
>>>>>>>>>>>>> similar pattern of
>>>>>>>>>>>>>
>>>>>>>>>>>>> Interface > AbstractBaseClass > ConcreteClass.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This "author" may not have done everything consistently there,
>>>>>>>>>>>>> see EnumSet, but other than that it is still a better piece of 
>>>>>>>>>>>>> API than
>>>>>>>>>>>>> let's say 310 with hundreds of methods on final classes that 
>>>>>>>>>>>>> are largely
>>>>>>>>>>>>> incompatible and a TemporalAmount which actually should be 
>>>>>>>>>>>>> called
>>>>>>>>>>>>> TemporalAmounts, TemporalAmountCollection or whatever
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 14, 2014 at 8:32 AM, Werner Keil <
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sorry but we had that confusion with JSR 275, so ONE
>>>>>>>>>>>>> Measurement is enough, we must not have Measure implements 
>>>>>>>>>>>>> Measurement,
>>>>>>>>>>>>> that would just be a mess.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> JScience called that "Amount", but you see a lot of very
>>>>>>>>>>>>> popular projects (SpringFramework) doing exactly the same. 
>>>>>>>>>>>>> There are
>>>>>>>>>>>>> Abstract*.valueOf() or similar constructions.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Werner
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>   Werner Keil | JCP Executive Committee Member, JSR 363 Co
>>>>>>>>>>>>> Spec Lead | Eclipse UOMo Lead, Babel Language Champion |
>>>>>>>>>>>>> Apache Committer | Java Godfather
>>>>>>>>>>>>>
>>>>>>>>>>>>> Twitter @wernerkeil | @UnitAPI | @JSR354 | #EclipseUOMo | 
>>>>>>>>>>>>> #Java_Social
>>>>>>>>>>>>> | #DevOps
>>>>>>>>>>>>>
>>>>>>>>>>>>> Skype werner.keil | Google+ gplus.to/wernerkeil
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * JavaZone 2014: 9-11 Sep 2014, Oslo, Norway. Werner Keil, JCP
>>>>>>>>>>>>> EC Member, JSR 363 Spec Lead will present "JSR 363 - The
>>>>>>>>>>>>> Answer to Life Science and the Internet of Everything"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * JavaOne 2014: Sep 30, San Francisco, USA, Werner Keil, JCP
>>>>>>>>>>>>> EC Member, JSR 354 EG Member will host "Java and Digital 
>>>>>>>>>>>>> Currencies, Friend
>>>>>>>>>>>>> or FOE"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * JMaghreb 3.0: 4-6 Nov 2014, Casablanca, Morocco. Werner
>>>>>>>>>>>>> Keil, JCP EC Member, JSR 363 Spec Lead, DevOps Guy will present
>>>>>>>>>>>>> "Triple-E' class DevOps", "JSR 363"
>>>>>>>>>>>>>
>>>>>>>>>>>>> * ApacheCon Europe: 17 Nov 2014, Budapest, Hungary. Werner
>>>>>>>>>>>>> Keil, JCP EC Member, Apache DeviceMap Committer will present 
>>>>>>>>>>>>> "Apache
>>>>>>>>>>>>> DeviceMap"
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> * Mobile Developer Conference kompakt: 18 Nov 2014, Hamburg,
>>>>>>>>>>>>> Germany. Werner Keil, JCP EC Member, Apache DeviceMap Committer 
>>>>>>>>>>>>> will
>>>>>>>>>>>>> present "Apache DeviceMap" (GER)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Sun, Sep 14, 2014 at 12:29 PM, Otávio Gonçalves de Santana <
>>>>>>>>>>>>>  >
>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Guys.
>>>>>>>>>>>>>
>>>>>>>>>>>>> How is going?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I believe we have a possible problem with nomeclature in
>>>>>>>>>>>>>  AbstractQuantity's class, looking this example:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Quantity<Length> metre = AbstractQuantity.of(10, SI.METRE);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Quantity<Length> foot =  metre.to(US.FOOT);
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> IMHO, Abstract* is not a good name to a factory, maybe just
>>>>>>>>>>>>> Measure, so will:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Quantity<Length> metre = Meansure.of(10, SI.METRE);
>>>>>>>>>>>>>
>>>>>>>>>>>>> Quantity<Length> foot =  metre.to(US.FOOT);
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYF?
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>>>>>>
>>>>>>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>>>>>>
>>>>>>>>>>>>> site:     *http://about.me/otaviojava
>>>>>>>>>>>>> <http://about.me/otaviojava>*
>>>>>>>>>>>>>
>>>>>>>>>>>>> 55 (11) 98255-3513
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>>>>>>
>>>>>>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>>>>>>
>>>>>>>>>>>>> site:     *http://about.me/otaviojava
>>>>>>>>>>>>> <http://about.me/otaviojava>*
>>>>>>>>>>>>>
>>>>>>>>>>>>> 55 (11) 98255-3513
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>>>>>>
>>>>>>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>>>>>>
>>>>>>>>>>>>> site:     *http://about.me/otaviojava
>>>>>>>>>>>>> <http://about.me/otaviojava>*
>>>>>>>>>>>>>
>>>>>>>>>>>>> 55 (11) 98255-3513
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>>
>>>>>>>>>>>>> Otávio Gonçalves de Santana
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>>>>>>>>>>
>>>>>>>>>>>>> twitter: http://twitter.com/otaviojava
>>>>>>>>>>>>>
>>>>>>>>>>>>> site:     *http://about.me/otaviojava
>>>>>>>>>>>>> <http://about.me/otaviojava>*
>>>>>>>>>>>>>
>>>>>>>>>>>>> 55 (11) 98255-3513
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> It is not the strongest of the species that survives, nor the
>>>>>>>>>> most intelligent. It is the one that is most adaptable to change. -
>>>>>>>>>> Darwin's Origin of Species (digest)
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> It is not the strongest of the species that survives, nor the most
>>>>>>> intelligent. It is the one that is most adaptable to change. - 
>>>>>>> Darwin's
>>>>>>> Origin of Species (digest)
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Otávio Gonçalves de Santana
>>>>>
>>>>> blog:     http://otaviosantana.blogspot.com.br/
>>>>> twitter: http://twitter.com/otaviojava
>>>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>>>> 55 (11) 98255-3513
>>>>>
>>>>>
>>>
>>>
>>> --
>>> Otávio Gonçalves de Santana
>>>
>>> blog:     http://otaviosantana.blogspot.com.br/
>>> twitter: http://twitter.com/otaviojava
>>> site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
>>> 55 (11) 98255-3513
>>>
>>>


-- 
Otávio Gonçalves de Santana

blog:     http://otaviosantana.blogspot.com.br/
twitter: http://twitter.com/otaviojava
site:     *http://about.me/otaviojava ;<http://about.me/otaviojava>*
55 (11) 98255-3513

GIF image

GIF image

GIF image

GIF image

GIF image



Re: AbstractQuantity's class

(continued)

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Werner Keil 09/15/2014

Re: AbstractQuantity's class

Jean-Marie Dautelle 09/16/2014

Re: AbstractQuantity's class

Werner Keil 09/16/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014

Re: AbstractQuantity's class

Werner Keil 09/17/2014

Re: AbstractQuantity's class

Otávio Gonçalves de Santana 09/17/2014
 
 
Close
loading
Please Confirm
Close