y approach.
Alexey
From: Reinier Zwitserloot
To: javaposse@googlegroups.com
Cc: Reinier Zwitserloot
Sent: Fri, February 18, 2011 11:34:55 PM
Subject: Re: [The Java Posse] using structured typing to reduce Java boilerplate
Well, sure, this comes up boatloads of times wh
I'd say lombok's approach is miles better here - at the end of the day
supertypes are public. When you extend class X then everybody else knows it
and it's part of your (public) API. I can write Pair> foo =
new Person(...) and that'll work. I can't tell from an API which supertypes
are meaningf
t the source code. When
using Lombok, the source code will be insufficient to understanding what will
happen at runtime. I think both approaches have their respective merits and
drawbacks.
Alexey
From: Reinier Zwitserloot
To: javaposse@googlegroups.com
Sent:
Well, sure, this comes up boatloads of times when talking to people that
have been sniffing the lisp glue for slightly too long. Yes, there's a sense
of elegance in being able to define an arbitrary arity stack of generics,
and you can do so using Pairs. However, pragmatically speaking, without
On Fri, Feb 18, 2011 at 7:56 PM, Reinier Zwitserloot wrote:
> My own project, but:
>
> Why the heck jump through all those hoops? Download lombok and you can just
> do this:
>
> @Data public class Person {
> private final String first, last;
> private final int age;
> }
>
> And toString, g
My own project, but:
Why the heck jump through all those hoops? Download lombok and you can just
do this:
@Data public class Person {
private final String first, last;
private final int age;
}
And toString, getters, constructor, equals/hashCode are all taken care of.
More to the point:
On Wed, Feb 16, 2011 at 7:33 PM, Fabrizio Giudici
wrote:
> I don't see how this solves my example. You're injecting prop in the
> constructor of A. In my example, prop is computed also by B. This means that
> the caller of the constructor of A must know how to compute B. It's not what
> I want to
On 02/16/2011 03:19 PM, Kevin Wright wrote:
Turtles all the way down! 'tis a good philosophy :)
Constructor injection is the way to go:
public class A {
public A(final B b) { this.b = b }
public final B b;
public final Object prop = new Object;
}
and alread
On 16 February 2011 13:03, Fabrizio Giudici
wrote:
> On 02/16/2011 01:33 PM, Ricky Clarkson wrote:
>
>> Immutable objects can have behaviour, it's just that they'll tend to
>> return new versions of themselves with a change rather than mutate
>> themselves.
>>
> Yes, indeed I was thinking of:
>
>
On 16 February 2011 12:33, Ricky Clarkson wrote:
> Immutable objects can have behaviour, it's just that they'll tend to
> return new versions of themselves with a change rather than mutate
> themselves.
>
Exactly :)
For a good example of quite how much behaviour take a look at joda-time:
http:/
On 02/16/2011 01:33 PM, Ricky Clarkson wrote:
Immutable objects can have behaviour, it's just that they'll tend to
return new versions of themselves with a change rather than mutate
themselves.
Yes, indeed I was thinking of:
public class A
{
private final B b; // injected in some way
Immutable objects can have behaviour, it's just that they'll tend to
return new versions of themselves with a change rather than mutate
themselves.
Regarding mixed mutability, I don't know the answer, but I tend in the
direction of splitting that into two objects, one that's immutable and
one that
On 02/16/2011 12:34 PM, Ricky Clarkson wrote:
If instantiating a real object is a problem (again assuming immutable
and without side-effects) then you might need to break up your objects
a bit more.
Well, it seems we're talking about simple, immutable objects. Ok. Let's
now suppose that we're ta
If instantiating a real object is a problem (again assuming immutable
and without side-effects) then you might need to break up your objects
a bit more.
I'm on the fence regarding public fields though; there are cases where
they're just more readable but then you do sometimes end up having to
swit
On 02/16/2011 12:14 PM, Ricky Clarkson wrote:
Generally, you don't need to mock immutable objects that have no side
effects, just as you wouldn't mock Math.max
If I have a test on Person that only needs first and last name I'm
forced to instantiate a real object instead of mocking it. If I later
On 02/16/2011 11:36 AM, Kevin Wright wrote:
The naming convention is also prone to misunderstanding. Head/Tail
smells a lot like a linked list, which perhaps gives the wrong
impression, and breaks down quite rapidly when considering larger
tuples. I also think that the getters could be dro
Generally, you don't need to mock immutable objects that have no side
effects, just as you wouldn't mock Math.max
On Wed, Feb 16, 2011 at 11:09 AM, Fabrizio Giudici
wrote:
> On 02/16/2011 11:36 AM, Kevin Wright wrote:
>>
>>
>> The naming convention is also prone to misunderstanding. Head/Tail sm
On 16 February 2011 10:06, Fabrizio Giudici
wrote:
> On 02/16/2011 08:06 AM, Miroslav Pokorny wrote:
>
>> Why would anyone want Person to be a Pair> ?
>>
>> I have got some questions and curiosity about this approach, but not that
> specific question. I understand that making a Person a Pair<...>
On 02/16/2011 08:06 AM, Miroslav Pokorny wrote:
Why would anyone want Person to be a Pair> ?
I have got some questions and curiosity about this approach, but not
that specific question. I understand that making a Person a Pair<...> is
just an implementation detail (ok, this brings to the discu
Why would anyone want Person to be a Pair> ?
On Wed, Feb 16, 2011 at 7:35 AM, Alexey Zinger wrote:
> Don't know how many people have rolled their own structured typing system
> in plain old Java with generics, but I've been finding myself dragging the
> same Pair class from one project to another
Don't know how many people have rolled their own structured typing system in
plain old Java with generics, but I've been finding myself dragging the same
Pair class from one project to another and using it in some new and interesting
circumstances. Here's the basic gist of it (leaving out the o
21 matches
Mail list logo
