Use Advanced Search to search the entire archive.
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




