Java 7 Slippage - good or bad news?

[Phil]

... discuss.

Personally I felt that Sun should be wrapping this up ASAP and then
moving on to Java 8 but hey, I'm not on the project team...

[Reinier Zwitserloot]

I get the distinct feeling from the language-side engineers here at
devoxx that java 7's slippage is not related to new language features
but to other must-have things that sun needs which aren't ready until
at least september. So, instead of twiddling their thumbs, they are
pressing on with Closures and possibly multicatch.

--Reinier Zwitserloot

[Michael]

On Nov 19, 11:57 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> I get the distinct feeling from the language-side engineers here at
> devoxx that java 7's slippage is not related to new language features
> but to other must-have things that sun needs which aren't ready until
> at least september. So, instead of twiddling their thumbs, they are
> pressing on with Closures and possibly multicatch.
>
>  --Reinier Zwitserloot

What are the 'must-have' things?

Also, is this breaking news at Devoxx? I was not able to find
anything about Java 7 slipping.

Michael

[Reinier Zwitserloot]

Officially, yes, this is the first time there's an official word that
JDK7 slipped. Practically speaking, Dick and co said in the live
javaposse episode that whenever he spoke to sun engineers recently, it
was pretty obvious they all already knew long before this
announcement.

[RichardVowles]

Other than jigsaw, there was nothing of value in JDK7. This at least
gives a glimmer of hope there will be something worthwhile in it
(productivity and interoperability wise).

[Vince O'Sullivan]

On Nov 19, 7:39 pm, RichardVowles <richard.vow...@gmail.com> wrote:
> Other than jigsaw, there was nothing of value in JDK7. This at least
> gives a glimmer of hope there will be something worthwhile in it
> (productivity and interoperability wise).

I must admit I prefer the more modern practise of delivering a sub-set
of features by the promised date and adding in the other (presumably
less important) features as they became available. But I'm open to
persuasion to the "deliver rarely, include everything" school of
thought, which has a long and well documented history.

[Casper Bang]

It's also rumored that extension methods [http://www.javac.info/
ExtensionMethods.html] might be on the table again. That would excite
me as much as closures, as a way to supplement/migrate API's, rather
than the typical ivory tower approach of assuming perfection/
completion the first go-round - which is impossible.

/Casper

[Jess Holle]

Hmmm....

I guess....

Overall, I think it is preferable to have

Collections.sort( list );

rather than

list.sort();

If 'list' does not actually provide a sort() method.  Having extension methods allow "list.sort()" [as suggested in the short example at the link provided] essentially is a lie and obfuscation to the reader of the code.

I also see no reason every operation on a class has to be a member of that class.  That's taking object orientation to an unreasonable ivory tower.

While having a quick call-site syntax to provide "list.sort()" [another proposal] makes the nature of what's going on obvious somewhere in the calling class (which is good), I guess I don't see all that much benefit -- outside the ivory tower.

--
Jess Holle

Casper Bang wrote:

--

You received this message because you are subscribed to the Google Groups "The Java Posse" group.
To post to this group, send email to java...@googlegroups.com.
To unsubscribe from this group, send email to javaposse+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/javaposse?hl=.



  

[Reinier Zwitserloot]

The reason extension methods are inevitable is because of java's rigid
adherence to backwards compatibility. So, if you have to be backwards
compatible, and interfaces like java.util.List will NEVER change (even
WITH versioning, as lists are routinely transferred across modules -
that's Mark Reinhold talking, so consider it canon). Thus, extension
methods. That's, again, Mark Reinhold (though I'm paraphrasing. I
wasn't running around devoxx with a recorder :P)

Technically it seems like a bit of a lie, practically, I really see no
problem whatsoever. "It's a lie", you say. Really? Is "list.sort();" a
lie? I don't see how it practically will ever be one. It sorts list. I
don't think the detail "sort is a method that has been virtually
looked up via the object that is being pointed at by the reference
variable named 'list'" holds much relevance here.

And, of course, it's trivial for the compiler / editor / style
checker / pretty printer / whatever to figure out what's happening and
give you a tool to tell these things apart. I would expect the IDEs to
render such a call the same way as a static method (example: In
eclipse, "sort" would be italicized).

Presumably, imports can gain a scope level and be moved to package-
info and module-info in such a way that you can configure a bunch of
static and extension imports ONCE per module, and use them everywhere
else. There's some precedent for this; in eclipse, you can configure
(IDE-wide, so that's clearly kludgey) standard static imports. In
practice, this means you can auto-complete these and if the static
import isn't already in the source file, it's added as you
autocomplete. Especially with such a feature, lists really WILL gain a
sort method. It won't be virtual, but this is mostly irrelevant to me;
whenever I am coding and I want to do something to this list, I want
to type:

"l", "i", "s", "t", ".", "ctrl+space", and pick sort out of the list.
If I can't, that sucks. Sucks way more than any concerns about magic
going on with extension imports.

[Jess Holle]

Reinier Zwitserloot wrote:

The reason extension methods are inevitable is because of java's rigid
adherence to backwards compatibility. So, if you have to be backwards
compatible, and interfaces like java.util.List will NEVER change (even
WITH versioning, as lists are routinely transferred across modules -
that's Mark Reinhold talking, so consider it canon). Thus, extension
methods. That's, again, Mark Reinhold (though I'm paraphrasing. I
wasn't running around devoxx with a recorder :P)

Technically it seems like a bit of a lie, practically, I really see no
problem whatsoever. "It's a lie", you say. Really? Is "list.sort();" a
lie? I don't see how it practically will ever be one. It sorts list. I
don't think the detail "sort is a method that has been virtually
looked up via the object that is being pointed at by the reference
variable named 'list'" holds much relevance here.
  

It's a lie in that it claims that list has a sort() method.

That's a lie.  One might wish it was true, but it's not.  Nor should every action on a List be a member function of list.

And, of course, it's trivial for the compiler / editor / style
checker / pretty printer / whatever to figure out what's happening and
give you a tool to tell these things apart. I would expect the IDEs to
render such a call the same way as a static method (example: In
eclipse, "sort" would be italicized).
  

Readability should not rely upon a fancy IDE.  I love my IDE, but the text should speak for itself.

Presumably, imports can gain a scope level and be moved to package-
info and module-info in such a way that you can configure a bunch of
static and extension imports ONCE per module, and use them everywhere
else.

That's even worse.  Then you're left wondering what the heck "sort()" is here and where the heck it came from.  Again, an IDE might come to the rescue, but one should not have to rely upon the IDE for this.  In the very worst case one should need an entire source file (without an IDE) for things to be clear (as with static imports) -- not the source for an entire module!

There's no value in the lie that sort() is a method of List.  Some ivory tower folk may think OO means every action is a method of the noun on for which it is the principal verb.  That's not realistic or reasonable.  A statically typed class should have a single set of methods -- not a hypergraph thereof.  If you want that, go with a dynamic language and meta-programming.  Other modules inevitably will add more verbs for that noun.  They shouldn't lie to everyone and say they're part of the original class.  Rather there should be utility classes that clearly and explicitly encapsulate these verbs outside the original class and clearly in the appropriate module.

In essence the drive for call site extension methods is just OO purity run amuck!

There's some precedent for this; in eclipse, you can configure
(IDE-wide, so that's clearly kludgey) standard static imports. In
practice, this means you can auto-complete these and if the static
import isn't already in the source file, it's added as you
autocomplete. Especially with such a feature, lists really WILL gain a
sort method. It won't be virtual, but this is mostly irrelevant to me;
whenever I am coding and I want to do something to this list, I want
to type:

"l", "i", "s", "t", ".", "ctrl+space", and pick sort out of the list.
If I can't, that sucks. Sucks way more than any concerns about magic
going on with extension imports.
  

Yes.  I really, really dislike static imports in most cases.  I'll use them in preference to having my class "implement" an interface class which defines a set of constants (as this is a royal hack), but that's about it.  Local clarity is really important -- source characters are cheap.

--
Jess Holle

[Reinier Zwitserloot]

inline responses...

On Nov 20, 5:48 pm, Jess Holle <je...@ptc.com> wrote:

> It's a lie in that it claims that list has a sort() method.

There is no such claim. dot instead gains an extra possible meaning
(pass ref to extension method).

> Readability should not rely upon a fancy IDE.  I love my IDE, but the
> text should speak for itself.

Why? No, seriously, why? It's almost 2010. Perhaps the dumb terminal
model should no longer be held as sacrosanct. The code isn't utter
gobbledygook in a dumb terminal - just includes slightly more
abstraction. I don't see a fire here.

>
> That's even worse.  Then you're left wondering what the heck "sort()" is
> here and where the heck it came from.

Just like x.foo() is a mystery if you don't know the type of x / don't
know what x's type is? Code without context is meaningless. Extension
methods don't change the equation.

 Again, an IDE might come to the

>

> There's no value in the lie that sort() is a method of List.  Some ivory
> tower folk may think OO means every action is a method of the noun on
> for which it is the principal verb.

You ignored my practical reason for this: auto-complete.

> [sky will fall down, all hope is lost, go use dynamic language grandstanding omitted]

There's no arguing with doomsayers.

> Yes.  I really, really dislike static imports in /most /cases.  I'll use

> them in preference to having my class "implement" an interface class
> which defines a set of constants (as this is a royal hack), but that's
> about it.  Local clarity is really important -- source characters are cheap.

Static import beats new keywords.


-- Reinier Zwitserloot

[Jess Holle]

Reinier Zwitserloot wrote:

inline responses...

On Nov 20, 5:48 pm, Jess Holle <je...@ptc.com> wrote:
  

It's a lie in that it claims that list has a sort() method.
    

There is no such claim. dot instead gains an extra possible meaning
(pass ref to extension method).
  

That's just ambiguous and confusing rather than a lie then.

Readability should not rely upon a fancy IDE.  I love my IDE, but the
text should speak for itself.
    

Why? No, seriously, why? It's almost 2010. Perhaps the dumb terminal
model should no longer be held as sacrosanct. The code isn't utter
gobbledygook in a dumb terminal - just includes slightly more
abstraction. I don't see a fire here.
  

When dealing with large number of modules, some of them large and needing to simply review and understand code having to toss entire modules around or load them up from source control is a real issue.

That's even worse.  Then you're left wondering what the heck "sort()" is
here and where the heck it came from.
    

Just like x.foo() is a mystery if you don't know the type of x / don't
know what x's type is? Code without context is meaningless. Extension
methods don't change the equation.
  

The polymorphism is well established and understood here.  Extension points add another unfettered dimension here.

 Again, an IDE might come to the
  

There's no value in the lie that sort() is a method of List.  Some ivory
tower folk may think OO means every action is a method of the noun on
for which it is the principal verb.
    

You ignored my practical reason for this: auto-complete.
  

Auto-complete could simply put a separator in the drop down and suggest static methods taking the given type as their first argument (excluding Object, of course).  Done.  If this is a big issue one could have an annotation hinting to IDE's that the method be associated with completion against some types.

[sky will fall down, all hope is lost, go use dynamic language grandstanding omitted]
    

There's no arguing with doomsayers.
  

Yes.  I really, really dislike static imports in /most /cases.  I'll use
them in preference to having my class "implement" an interface class
which defines a set of constants (as this is a royal hack), but that's
about it.  Local clarity is really important -- source characters are cheap.
    

Static import beats new keywords.
  

Yes, it's not the syntax that's the issue here -- it's what the syntax *does* that's the issue.  It leads to a lot of developer confusion when onne has what appear to be method calls against "this" throughout the code that are nothing of the sort, for instance.

--
Jess Holle

[Casper Bang]

Nobody sees value in having a small and tight core, which can be
decorated by importing features/aspects from a 3'rd part, 4'th part
etc? It can work really well. Can it be abused? Certainly, just like
anything else. Static imports are nice, but less powerful and composes
really bad with one another.

/Casper

[Fabrizio Giudici]

Casper Bang wrote:
> Nobody sees value in having a small and tight core, which can be
> decorated by importing features/aspects from a 3'rd part, 4'th part
> etc? It can work really well.

It's very valuable and my preferred way of designing things. Generally
speaking, my preferred way to see that is:

myObject.lookup(Extension.class).doSomething();

In context:

list.lookup(Sorter.class).sort();
list.lookup(MyGreatAndFastSorter.class).sort();

Just regular OOP constructs and no lies.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people
Fabrizio...@tidalwave.it

[RichardVowles]

Beat your agile drum all you like, if there are no features
worthwhile, people won't bother with it. Perfect example: JDK6. The
world does not need another JDK6.

Now back to Jess's hilarious arguments. Can't say I've laughed so hard
in ages!

[Fabrizio Giudici]

RichardVowles wrote:
> Beat your agile drum all you like, if there are no features
> worthwhile, people won't bother with it. Perfect example: JDK6. The
> world does not need another JDK6.
>

So, why a relevant part of the world is using JDK6 in your opinion? BTW,
another large part is still using 1.4 in spite of 5 being full of
features, because they're kept back by legacy, not for free choice.

[Vince O'Sullivan]

On Nov 20, 8:55 pm, RichardVowles <richard.vow...@gmail.com> wrote:
> Beat your agile drum all you like, if there are no features
> worthwhile, people won't bother with it. Perfect example: JDK6. The
> world does not need another JDK6.

I'm not sure I follow that argument. If the other features aren't
worth while, why save them up for a 'big bang' release - why not
release them as and when they are ready?

On the other hand, If the other features are worth while, why save
them up for a 'big bang' release - why not release them as and when
they are ready?

[Reinier Zwitserloot]

One-liners, Inline...

On Nov 20, 7:32 pm, Jess Holle <je...@ptc.com> wrote:
> > There is no such claim. dot instead gains an extra possible meaning
> > (pass ref to extension method).
>
> That's just ambiguous and confusing rather than a lie then.

dot already means a thousand things. Now it means 1001 things. Sky
will remain firmly set in the heavens.

> > Why? No, seriously, why? It's almost 2010. Perhaps the dumb terminal
> > model should no longer be held as sacrosanct. The code isn't utter
> > gobbledygook in a dumb terminal - just includes slightly more
> > abstraction. I don't see a fire here.
>
> When dealing with large number of modules, some of them large and
> needing to simply review and understand code having to toss entire
> modules around or load them up from source control is a real issue.

I don't understand. Are you trying to argue that huge source bases are
slow to open in an IDE? You're betting against future performance
improvements? That would be unwise.

>
> The polymorphism is well established and understood here.  Extension
> points add another unfettered dimension here.

polymorphism is understood? That's quite a laugh. Extension points are
quite a bit simpler than polymorphism. Much more statically linkable.

>
> Yes, it's not the syntax that's the issue here -- it's what the syntax
> *does* that's the issue.  It leads to a lot of developer confusion when
> onne has what appear to be method calls against "this" throughout the
> code that are nothing of the sort, for instance.

Possibly he can bang some rocks together and make a rudimentary knife.
Tools can trace an extension call with 100% accuracy every time. This
entire line of reasoning presupposes that a *programmer* avoids
*software* like the plague. The cognitive dissonance is staggering.

Casper: I think most of us like extension points in one form or
another, and we're just getting excited about painting our bikeshed an
yellowish mauve, or possibly goldenrod. Programmers will be
programmers. It's in our genes.

Fabrizio: Your syntax is even more convoluted than Collections.sort,
includes even more code primitives, and ends up containing a lot of
boilerplate. The notion that "Sorter.class" is going to help me
understand "list.sort();" more is a bit strange, isn't it? JDK7 is
trying to get rid of repeating ourselves (diamond operator, joy!) and
now you're putting it right back again. The notion that sort() is
being provided by Sorter is in your extension imports, which are...
somewhere folded away out of sight, there mostly for your IDE, and,
where needed, for your own inspection. It shouldn't be there when
you're just trying to grok your code.

[Fabrizio Giudici]

Reinier Zwitserloot wrote:
>
> Fabrizio: Your syntax is even more convoluted than Collections.sort,
> includes even more code primitives, and ends up containing a lot of
> boilerplate. The notion that "Sorter.class" is going to help me
>

Frankly, I don't give much to syntax, which is mostly hype to me; I
prefer a good design :-) With that syntax I can extend the functionality
at will (e.g. list.lookup(Decimator.class).decimate(4)) and I can inject
new features dynamically, in a OSGi or NetBeans Platform environment.
Much more value than a static method or an extension point.

> understand "list.sort();" more is a bit strange, isn't it? JDK7 is
> trying to get rid of repeating ourselves (diamond operator, joy!) and
>

As I just shown, there are only only sorters in the world, but an
unlimited number of classes that can do more than one thing, and
possibly getting arguments.

> now you're putting it right back again. The notion that sort() is
> being provided by Sorter is in your extension imports, which are...
> somewhere folded away out of sight, there mostly for your IDE, and,
> where needed, for your own inspection. It shouldn't be there when
> you're just trying to grok your code.
>

[Reinier Zwitserloot]

On Nov 21, 7:41 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
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);


Both examples are:

1) Unwieldy (in the sense that, when you see it, you get the distinct
feeling that you want your editor to fold some of the extraneous stuff
away so you can get on with reading your source).

2) Explicitly referencing source, which is an advantage of sorts,
though not enough of an improvement over implicit reference to warrant
the eyesore.

3) Complicate auto-complete and other 'Uh, how did this API work
again?' help.

> With that syntax I can extend the functionality at will

Perhaps you do not understand how extension methods work? The *USE
SITE* is where the extensions are defined, so, if you have a custom
sort algorithm that you prefer, you can write:

import my.customcode.CoolSorter.sort extends java.util.List;

instead of importing it from Collections and you'll get your
particular flavour of sorting instead. The choices of either the core
JDK, or the author of java.util.Collections, or the author of
java.util.List, cannot force anything particular on you. In the rare
case you want to mix sort flavours inside the same source file, you'll
have to forego extension methods and go back to
ProviderClass.methodName(object); instead of object.methodName(); -
but as, at this point, the implementation source is clearly no longer
a meaningless detail, this would be a good thing. In your proposed
syntax, it's always there, even in the vast majority of cases where
it's trivial boilerplate junking up your source.

> "I prefer good design"

And I prefer music that sounds good. Also, art that looks nice. I like
food that tastes good too. Knock it off.

--Reinier Zwitserloot

[Mark Derricutt]

I was thinking earlier about how extension methods could be used to
implement mix-in like functionality, but I've not seen anyone mention
such a use before, the current examples tend to show adding say
.sort() onto the List class you've imported, but say you had a
list(MarksCollection col):

import com.foo.MySorter.list;

public class MarksCollection implements java.util.List {

public void someMethod() {
sort();
}
}

here, the sort() method was imported and (the implicit this.
reference) is the instance being extended. I could see this being
VERY handy. Has anyone else ever thought of extension methods as a
form of mixin?

--
Pull me down under...

[Fabrizio Giudici]

Reinier Zwitserloot wrote:

On Nov 21, 7:41 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
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);
  

Apart from the fact that the discussion started with a advocating the extensions precisely to avoid this use of static methods, there's a huge difference that I've just explained in the previous post: in your example you have a single Decimator which applies to all the lists; in my example each list can have its own Decimator implementation according to some rules.

Both examples are:

1) Unwieldy (in the sense that, when you see it, you get the distinct
feeling that you want your editor to fold some of the extraneous stuff
away so you can get on with reading your source).

2) Explicitly referencing source, which is an advantage of sorts,
though not enough of an improvement over implicit reference to warrant
the eyesore.

3) Complicate auto-complete and other 'Uh, how did this API work
again?' help.

  

With that syntax I can extend the functionality at will
    

Perhaps you do not understand how extension methods work? The *USE
SITE* is where the extensions are defined, so, if you have a custom
sort algorithm that you prefer, you can write:

import my.customcode.CoolSorter.sort extends java.util.List;

instead of importing it from Collections and you'll get your
particular flavour of sorting instead. The choices of either the core
JDK, or the author of java.util.Collections, or the author of
java.util.List, cannot force anything particular on you. In the rare
  

Reiner, but I'm repeating this for the n-time :-) your example is *static*: once you have compiled that code, it's carved in the stone. My code can dynamically pick an implementation at runtime, searching for a provider. Clearly, the list and sort/decimator examples aren't the proper use case for that, as I don't see the need for such a high dynamicity in a sorter, but I suppose we are using them just as a placeholder for generic use cases.

case you want to mix sort flavours inside the same source file, you'll
have to forego extension methods and go back to
ProviderClass.methodName(object); instead of object.methodName();

ProviderClass is *static*. :-)

 -
but as, at this point, the implementation source is clearly no longer
a meaningless detail, this would be a good thing. In your proposed
syntax, it's always there, even in the vast majority of cases where
it's trivial boilerplate junking up your source.

  

"I prefer good design"
    

And I prefer music that sounds good. Also, art that looks nice. I like
food that tastes good too. Knock it off.
  

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.

[Fabrizio Giudici]

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 a better real-world example which is not List, I've at last managed in finishing another blog post that I had in draft since some time, and explains what I mean:

http://weblogs.java.net/blog/fabriziogiudici/archive/2009/11/22/when-rdf-store-meets-netbeans-lookup


So, just to keep the focus on our discussion, would it be possible to make the same things with extenders?

[Jan Goyvaerts]

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 with Adobe Flex.

But anyhow, I'm glad with what I heard @ Devoxx. JDK7 was covered
quite well by knowledgeable people. And if it takes some more time,
that's the way it will be.

[Reinier Zwitserloot]

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


Your entirely dynamic solution concept is available now in java, just
stick that 'lookup' method on something. However, to make the
boilerplate go away, you'd need mixins/traits. I take it you're a fan
of those, then? Something we can agree on, at least.

On Nov 22, 4:44 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> 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 a better real-world example which is not List, I've at last
> managed in finishing another blog post that I had in draft since some
> time, and explains what I mean:
>

> http://weblogs.java.net/blog/fabriziogiudici/archive/2009/11/22/when-...

>
> So, just to keep the focus on our discussion, would it be possible to
> make the same things with extenders?
>
> --
> Fabrizio Giudici - Java Architect, Project Manager
> Tidalwave s.a.s. - "We make Java work. Everywhere."
> weblogs.java.net/blog/fabriziogiudici -www.tidalwave.it/people

> Fabrizio.Giud...@tidalwave.it

[Casper Bang]

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 explore capabilities. Let me throw you an
analogy here, would you rather deal with a bean which exposes it's
members via properties or which is a Map?

/Casper

On Nov 20, 8:57 pm, Fabrizio Giudici <fabrizio.giud...@tidalwave.it>
wrote:

> Fabrizio.Giud...@tidalwave.it

[Fabrizio Giudici]

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
> the IDE to poke around and explore capabilities. Let me throw you an
> analogy here, would you rather deal with a bean which exposes it's
> members via properties or which is a Map?
>

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 rather than language features discovered that most of the
problems can be solved with techniques that have been around for
decades, etc.... your analogy is rather unfortunate, since thanks to
generics the Lookup idiom can take advantage of IDE autocompletion. :-)
Quoting Tim:

"A Lookup may be a magic bag-o-stuff, but it's a type-safe magic
bag-o-stuff - I want all the help the compiler can give me!); Lookup is
nicer in that you have type-safety - if I call Map.get ("foo"), I have
no idea what I will get back - the compiler cannot help me; if I call
Lookup.lookup (MyObject.class), I know I'm getting back instances of
MyObject."

But I find that many discussions here get too subjective and anecdotic:
it's much better to talk with code. I'm blogging about these patterns /
idioms and I should have completed the series in a few weeks (depending
on my job load). They are focused by some concrete code from a concrete
application. It will demonstrate what can be done with this approach and
what cannot. I could challenge others to show how they would design the
same thing (*). That sounds as the good way to discuss these topics.

(*) Of course I'm absolutely not saying that I'm doing the best possible
design (it would be laughable!). It's not a challenge with prizes. Also,
good design is contextual and what is valuable for one could be not so
valuable for others. But lots of useful discussions could arise.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/people

Fabrizio...@tidalwave.it

[Casper Bang]

> 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 rather than language features discovered that most of the
> problems can be solved with techniques that have been around for
> decades, etc.... your analogy is rather unfortunate, since thanks to
> generics the Lookup idiom can take advantage of IDE autocompletion. :-)

It's true that generics really comes to its right here. But the core
problem remains, how does one know what to query for? You are
essentially using dynamic has-a relationships on everything, which can
never be statically explored (is-a). Extensions methods are a way of
adding additional functionality to an existing class without
subclassing it or having access to the source code. It should be
obvious, that I am mostly concerned with what help I can get while
coding, putting my trust in the type system - liking the fact that I
don't have to ask an object about what it can do and checking for null
all over.

> But I find that many discussions here get too subjective and anecdotic:
> it's much better to talk with code. I'm blogging about these patterns /
> idioms and I should have completed the series in a few weeks (depending
> on my job load). They are focused by some concrete code from a concrete
> application. It will demonstrate what can be done with this approach and
> what cannot. I could challenge others to show how they would design the
> same thing (*). That sounds as the good way to discuss these topics.

It's not that I don't see the power in the lookup pattern, I just
question whether it's worth the trouble outside of extremely flexible
and long-lived architectures (i.e. NetBeans). Should we make EVERY
Object in Java extend Lookup? The beauty of extension methods is that
you gain the power to evolve (statically), by injecting domain
specific utilities through the import scope. Image what Joda-time
could do to a gazillion code-bases all using their own buddy
DateUtils.

I don't know Bob Martin's opinion on this, but considering what he has
written in Code Complete about "Using Third-Party Code" and "Exploring
and Learning Boundaries" I'm not convinced he would favor a dynamic
lookup over extension methods.

/Casper

[Fabrizio Giudici]

Casper Bang wrote:
> It's not that I don't see the power in the lookup pattern, I just
> question whether it's worth the trouble outside of extremely flexible
> and long-lived architectures (i.e. NetBeans). Should we make EVERY
> Object in Java extend Lookup? The beauty of extension methods is that
> you gain the power to evolve (statically), by injecting domain
> specific utilities through the import scope. Image what Joda-time
> could do to a gazillion code-bases all using their own buddy
> DateUtils.
>

It's a matter of trade-offs, as usual. That's why I say that everything
should be put in context. Trying to simplify, there are two extrema:
those who think of reusable code, and those who think of maximum
efficiency in the current project. OOP started with the first goal, then
the second gained importance with the rise of XP and agile methods, and
people focuse OOP more on evolutionary capabilities of a single project
than reusing parts in many projects.

So far, reuse in the wider sense has been a (at least partially) failed
promise, to tell the truth. But I see that OSGi is bringing another wave
of reuse enthusiasm. Will it work? I really don't know, but I think it's
worth while to try.

BTW, I've stressed the bound between dinamicity and reuse, but actually
dinamicity also leads to more modular stuff, which can help with the
evolutionary maintenance of a project.

So, back to our discussion, I'm arguing that lookup-based and related
stuff is a better design for many respects. Sure, it could be
over-engineering and not convenient from an economic point of view
(actually, looking at my bank account I can do everything but tell
people how to get rich writing software). You mention a trade-off about
the fact that I have to know what to lookup that implies a highly
code-base style of designing, if I have to explore an API almost
exclusively by means of IDE autocompletion. I imply that one should read
a minimum of documentation (you have some points here since most people
don't RTFM). Still, a trade off can be found, as I could describe the
most common things to look up in the lookup javadoc, so with a few more
key hits in the IDE you can see them. I have to try this, actually.

> I don't know Bob Martin's opinion on this, but considering what he has
> written in Code Complete about "Using Third-Party Code" and "Exploring
> and Learning Boundaries" I'm not convinced he would favor a dynamic
> lookup over extension methods.
>

I'm not saying that he favours dynamic code. I'm saying that lookup is a
way to apply SOLID principles. To avoid any misunderstanding, I'll cite
SOLID without referencing Martin in future.


Thanks for this. This discussion is very interesting to me.