Skip to main content

Re: AbstractQuantity's class

  • From: Werner Keil < >
  • To:
  • Subject: Re: AbstractQuantity's class
  • Date: Wed, 17 Sep 2014 10:47:47 +0200

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
>>
>>

GIF image

GIF image

GIF image

Attachment: 329.gif
Description: GIF image

Attachment: 347.gif
Description: GIF image



Re: AbstractQuantity's class

(continued)

Re: AbstractQuantity's class

Jean-Marie Dautelle 09/15/2014

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