On Fri, Nov 20, 2009 at 7:44 PM, Kfir Shay wrote:
> one don't need a framework for doing REST, just use the Servlet api
> and implement each HTTP verb
It's true that you don't *need* it. But you'll waste a lot more time
reimplementing wheels. What about etag support, for instance? Parsing
pat
one don't need a framework for doing REST, just use the Servlet api
and implement each HTTP verb
just my .02
On Fri, Nov 20, 2009 at 2:42 PM, Casper Bang wrote:
> Take a look at Jersey (REST). It's simple and powerful, one of the few
> real good examples I know of which uses annotations rather t
> A part from the fact that there's nothing magic, that these design
> patterns are not NetBeans specific, but just based on the old SOLID
> principles by Bob Martin (e.g. the Interface Segregation Principle plus
> composition vs inheritance), that if people discussed more about these
> things rath
Casper Bang wrote:
> I don't actually see the similarities here though. I am aware of
> NetBeans extensive use of "magic bags" (I believe Tim Boudreau refers
> to this as the capability pattern), this is part of what makes it
> really hard to get stuff done with the NetBeans RCP, you can never use
I don't actually see the similarities here though. I am aware of
NetBeans extensive use of "magic bags" (I believe Tim Boudreau refers
to this as the capability pattern), this is part of what makes it
really hard to get stuff done with the NetBeans RCP, you can never use
the IDE to poke around and
Why are you talking about character-phobia?
Collections.sort(list);
contains at least one more concept compared to:
list.sort();
If you think the only gain here is saving some characters, we should
just stop right here and agree to having a fundamentally incompatible
logic concerning language d
A modularized JDK6 (backported from JDK7) would be an ideal solution.
And probably wiser too - refactoring the whole code stack AND changing
the language in one release is no small affair.
I would have liked the news of having a faster JRE soon, with a JavaFX
RAD tool. So we could compete head on
> The hallmark of a closure is that it can contain an identifier that is
> bound to a name in a lexically enclosing scope.
>
> The name "first" does not appear in the "closure", and "first" is not
> a variable that is defined in a scope that lexically encloses the
> "closure".
The closure is the m
On Nov 22, 2:45 am, Mario Fusco wrote:
> Could you please better explain why the variable first of the AdderOf
> class in my example cannot be considered a variable captured from the
> lexically enclosing scope? I am sure that I am missing something but I
> don't understand what.
The hallmark of
Fabrizio Giudici wrote:
> A design which implies that behaviour is *static* rather *dynamic* is
> a worse design (especially if this is the consequence of a phobia for
> a few characters more), and this is an objective consideration from
> OOP best practices, not a subjective one.
>
Just to have
Reinier Zwitserloot wrote:
> On Nov 21, 7:41 pm, Fabrizio Giudici
> wrote:
>
>> [I like list.lookup(Decimator.class).decimate(4);]
>>
>
> I don't really get the benefit you're seeing from:
>
> list.lookup(Decimator.class).decimate(4);
>
> compared to:
>
> Decimator.decimate(list, 4);
>
> As you are probably aware, a closure, by definition, captures
> variables from the lexically enclosing scope. Lambdaj simply does
> not. They are not, therefore, closures.
>
> I don't mean to say lambdaj isn't useful - I'm willing to suspend
> disbelief on that. They just aren't closures.
>
>
12 matches
Mail list logo
