ijuma wrote:
> On Dec 20, 2:35 am, Weiqi Gao wrote:
>> As long as you smart people are having discussions like this, us
>> enterprise developers will just wait. :)
>
> You mean that _some_ enterprise developers will wait. Just in this
> thread, Peter said that he's using it in the enterprise an
On Dec 20, 2:35 am, Weiqi Gao wrote:
> As long as you smart people are having discussions like this, us
> enterprise developers will just wait. :)
You mean that _some_ enterprise developers will wait. Just in this
thread, Peter said that he's using it in the enterprise and then
there's SAP and
As long as you smart people are having discussions like this, us
enterprise developers will just wait. :)
I have tried Scala, and felt uncomfortable with it (see
http://www.weiqigao.com/blog/2008/03/24/scala_still_uncomfortable_after_five_years.html).
I'm not disagreeing with all the princ
http://blogs.sun.com/javafx/entry/javafx_1_0_sdk_update
Now with streaming video.
Seems to work well with my quick checks. (Mac OSX)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post t
On Dec 19, 3:39 pm, Reinier Zwitserloot wrote:
>Then you've got python, ruby, groovy, haskell, lisp, lua, fan and many more to
>compete with
> haskell, lisp, lua, fan and many more to compete with. If scala is
> going to grow into something big, it either has to be so amazingly
> incredible it c
I finally got a chance to blog on how to embed a JavaFX scene in a
Swing application. Please try it out and let me know if I missed
anything.
http://blogs.sun.com/javafx/entry/how_to_use_javafx_in
Thanks,
Josh
On Dec 14, 2008, at 1:52 PM, Andres Almiray wrote:
>
> Then you'll be
the class declaration syntax.
sealed abstract class A
case class B(val foo:Int) extends A
case class CB(val foo:Int, val bar:String) extends B(foo)
case class D(val foo:Int) extends A
(The above code declares a class hierarchy of four classes each having a
constructor matching the declaration abo
Replies to everyone, specifically: Michael, Peter, Casper, Gabriel,
Jorge, and James.
MICHAEL:
I am confused about your continued insistence that 'enterprise folk'
aren't relevant to this discussion. See the name of the topic. But not
just that:
enterprise folk are also the main bastion of java
Kevin Wong wrote:
> Although I'm all about loose coupling, placing concerns and knowledge
> where they belong is also important. I this case, what does the
> HumanResources.holidays(..)
Humm, well, maybe human resoruces does this by interacting with the
person (or their records) or maybe via a c
Good stuff. I haven't actually tried it, just reading about it in
search of the perfect language.
the perfect language doesn't exist yet. But Fan seems to have the
right balance of of complexity vs pragmatism to me.
On Dec 19, 2:43 am, DJ wrote:
> Phil,
>
> Regarding your what Fan doesn't hav
On Dec 19, 4:41 am, Casper Bang wrote:
> > What doesn't it have that it should have?
>
> Generics. Quote from the designers: "Our philosophy is that generics
> are a pretty complicated solution to a fairly insignificant problem".
>
> /Casper
I could live w/o generics, but if you are going to h
Thats a good point, keep it simple. Now in languages that supports
extension methods, people would probably be contend with just
importing the HR namespace and still be able to say
.getHolidays() by having the compiler delegate to
HR.Utils.getHolidays(). That strikes me as a very pragmatic
solutio
Hello JavaPosse folks,
I've recently bought the Scala programming book because you guys did
rise my curiosity about Scala. Unfortunately I missed the 3 hour
session at Devoxx so I'm reading the book back to back as fast as I
can.
In the meantime I have a question for the experienced Scala people
Although I'm all about loose coupling, placing concerns and knowledge
where they belong is also important. I this case, what does the
HumanResources.holidays(..) method need to know to calculate
holidays? I think to make this calculation it's acceptable for
HumanResources to have access to all o
Hi there,
I think you'll have more success on us...@open-esb.dev.java.net
I don't specialize in OpenESB but know of a few.
I guess you can fire your questions to me as well.
cheers,
-Alexis (Sun)
On Fri, Dec 19, 2008 at 5:05 AM, sherod wrote:
>
> If you have, feel free to drop me a line, I'd l
Been there, done that (not only boiled myself but also a couple of
teammates with me :) )
On Dec 18, 7:20 pm, Michael Neale wrote:
> Indeed - awesome quote. Well it seems simple, until you step back and
> realise the mess you have created.
>
> On Dec 19, 5:59 am, Gabriel Claramunt
> wrote:
>
>
Casper Bang wrote:
> I agree with Kirk, one should always aim at having as few arguments as
> possible for a variety of reasons and if you think in abstractions/
> contexts it should be possible. It's fine to make up and pass DTO's
> (synthetic objects)
I guess I should explain my position at bit
> Notice I say DTO because I actually think there's a subtle but not
> insignificant difference between an object exposing behavior and a
> data structure encapsulating state - again even if Java puts both into
> the same camp. On the one hand, you can easily add new methods all
> over without ev
I agree with Kirk, one should always aim at having as few arguments as
possible for a variety of reasons and if you think in abstractions/
contexts it should be possible. It's fine to make up and pass DTO's
(synthetic objects), even if Java makes this a very ceremonial thing
to do. It also seems t
> What doesn't it have that it should have?
Generics. Quote from the designers: "Our philosophy is that generics
are a pretty complicated solution to a fairly insignificant problem".
/Casper
--~--~-~--~~~---~--~~
You received this message because you are subscribe
Phil,
Regarding your what Fan doesn't have list:
* It has default param values in method signatures
* Null check operator is done using elvis operator, so for your
example it will be a ?: 5
Another thing to consider is in Fan object reference can be declared
nullable or not, so if you declared
etzel wrote:
> Meanwhile I've read a little bit further in the book. In chapter 7
> this topic comes up again and Steve McConell says that there are
> really two camps.
>
> The one say that you should pass just the parameters needed for the
> calculation because it's more loosely coupled, easier t
Meanwhile I've read a little bit further in the book. In chapter 7
this topic comes up again and Steve McConell says that there are
really two camps.
The one say that you should pass just the parameters needed for the
calculation because it's more loosely coupled, easier to read and that
passing
23 matches
Mail list logo
