Still hope for first-class properties
Casper Bang
7 will or won't contain a language change for properties, and for a
real effort to occur to unify the various different JSRs currently
running in the beans/properties arena."
The words of Stephen Colebourne in his latest blog entry, reflecting
over the settling of Beans Binding and Remi Forax' push for real
properties. The # syntax might take some getting used to, but I'll
take that any day over multilined verbosity. I say that Sun should
listen up. What do you think?
/Casper
Joe Nuxoll (Java Posse)
Joe Nuxoll (Java Posse)
On Sep 27, 6:00 pm, Casper Bang <c...@brunata.dk> wrote:
Alexey Zinger
I think real properties are good... mmmkay.
On Sep 27, 6:00 pm, Casper Bang wrote:
> "What this really demonstrates is the need for Sun to declare if Java
> 7 will or won't contain a language change for properties, and for a
> real effort to occur to unify the various different JSRs currently
> running in the beans/properties arena."
>
> The words of Stephen Colebourne in his latest blog entry, reflecting
> over the settling of Beans Binding and Remi Forax' push for real
> properties. The # syntax might take some getting used to, but I'll
> take that any day over multilined verbosity. I say that Sun should
> listen up. What do you think?
>
> /Casper
Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more!
Nick Hanley
wrote:
> I think real properties are good... mmmkay.
I agree 100%. I love Java, but I would have to say that the component
model of Delphi with real properties and events kind of trumps Java's
bean weirdness. Makes me wonder what the programming world would be
like had Sun grabbed Anders way back when. I don't mean to disparage
any of the engineers at sun - Java is a fantastic language, and nobody
can argue that java is not a smashing success. Still, it seems odd to
me that such a valuable innovation didn't really make it into Java
right at the start.
Nick
Mark Derricutt
Casper Bang
Ah, a classic. Well why don't we all just write raw bytecode, those
nasty Java abstractions don't really give us anything we can't do
there. I take it you were also against getting Enum in Java, since it
gave you nothing that various pseudo-enum patterns couldn't provide?
As to the exception talk, it seems evident if you look across the
board, that they do more harm than good. Something that unclear about
its merits, should probably not be in the language in the first place
- especially since tools really have no problem detecting these things
for you. Of course, if you are a fan of writing raw byte code, there
is no such thing as checked exceptions in the first place.
> Still, it seems odd to
> me that such a valuable innovation didn't really make it into Java
> right at the start.
Agreed. Anders Hejlsberg actually added it to the Microsoft VM. Sun
could've jumped on the wagon there, but chose to pout and scream "Java
Is MINE" regardless of how great the idea was. From the the point of
view of a Swing developers anno 2007, that's was tough luck. It
could've lifed Java out of the broken bean hell with adapters and
generated locked code, and into a world of components catering much
better to design goals such as loose coupling and encapsulation.
/Casper
Christian Catchpole
generics.... if you hadn't guessed, I'm being sarcastic. Adding a
feature to the JVM which causes temporary pain has got to be better
than using a work around which will be with us forever.
Kevin Wong
https://bean-properties.dev.java.net/ (mentioned in thread
http://groups.google.com/group/javaposse/browse_thread/thread/800fd874d9366df2)
negates the need for language level properties?
Alexey Zinger
>
> > They don't give us anything we can't do now!
>
> Ah, a classic. Well why don't we all just write raw bytecode, those
> nasty Java abstractions don't really give us anything we can't do
> there. I take it you were also against getting Enum in Java, since it
> gave you nothing that various pseudo-enum patterns couldn't provide?
> As to the exception talk, it seems evident if you look across the
> board, that they do more harm than good. Something that unclear about
> its merits, should probably not be in the language in the first place
> - especially since tools really have no problem detecting these things
> for you. Of course, if you are a fan of writing raw byte code, there
> is no such thing as checked exceptions in the first place.
I was of course being somewhat sarcastic in my initial comment. That said, I
did spend a good amount of time coding C# and using the .NET properties
mechanism. I must say, I did not come across anything that stared me in the
face as being a clear advantage. I wrote and used my own properties,
components, interfaces, and so on. Never had that sort of epiphany. On the
contrary, at times I had to refer to the properties implementation to see if it
was a property or a field. Maybe I wasn't doing it "right". Maybe I didn't
come across the thing that made it clear what the properties advantage is.
What do properties mean to you?
As far as enums, I'm pretty much in favor of them. They can certainly be used
at the language level to make clear use of restricted value sets. Like I said,
I'm not clearly seeing such an advantage in the case of language-level
properties as opposed to the bean-spec accessor methods.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Pinpoint customers who are looking for what you sell.
http://searchmarketing.yahoo.com/
Jeremy Ross
yesterday. The only concrete benefit we came up with for .NET-style
P&Es is that the observable implementation comes for free in the .NET
framework. Other than that, it seems to be a "what you're used to"
thing.
Just speculation.. I've never built tools, but I wouldn't think that
language level P&Es would do much to help tooling either.
> 1992 Kawasaki EX500http://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://wcollage.sourceforge.net
Casper Bang
> language level P&Es would do much to help tooling either.
I'd say you would be wrong there. The amount of adaptors needed to
build a moderate complex application is just über verbosity. So is the
BeanInfo madness needed to describe a component, few actually take the
time to do this. And the get/set/is naming patterns paired with
introspection needed to "realize" you're dealing with a property. And
the very manual string based firePropertyChange you have to remember
to fire yourself, but yet can only rely on firing if it actually
changes the current value (so forget about using setX in a constructor
to set up your initial states).
/Casper
Jess Holle
From the bean user's perspective I'm not entirely convinced a language change is necessary. If a language change allows better optimization at the JVM level in the short to mid term, then it is worth considering. Otherwise I'd fall back to improved APIs rather than language additions.
--
Jess Holle
Joshua Marinacci
csar
source). The only think I am still reluctant to add is event firing. I
am afraid that this will create a big mess when not used correctly
(and as for each individual abuse always a good reason can be named,
the misuse will florish). This might not be a problem on a UI where
the interactions of properties are somehow limited, but what about
server object properties? How to handle infinite event loops? Also the
program flow becomes quite obfuscated (I did several years of 4GL
programming)
My Properties are called Items BTW and they now how to validate
themselves and provide metadata renders - I don't know if something in
the language can give me the flexibility I need, but perhaps it would
make Items more efficient.
Carsten
PS: Anyone how proposes syntax extensions that use "
Joe Nuxoll (Java Posse)
Sun back in 2005. There is a link in this blog posting that overviews
the details.
http://blogs.sun.com/joe/entry/java_properties_and_events
Note that this proposal is for both language level properties *and*
events - which I feel are both critical for real component-oriented
software design. Today we're still building class libraries, which is
very passe'.
- Joe
Nick Hanley
Introspection and pattern by convention is simply no substitute for
first class published properties. Writing visual and non-visual
components that plugged into the pallete in Delphi just felt kind of
cleaner than doing the same with NetBeans. I don't claim to be an uber-
programmer, and I have never written an IDE, but I feel strongly that
tools like NetBeans would benefit from the inclusion of properties in
the java language - not to mention the users. Is there a huge problem
with source or binary compatability if properties were added to Java?
P.S. I miss the 'with' keyword too...
Nick Hanley
On Sep 29, 1:22 pm, "Joe Nuxoll (Java Posse)" <jnux...@gmail.com>
wrote:
> > PS: Anyone how proposes syntax extensions that use "- Hide quoted text -
>
> - Show quoted text -
Alexey Zinger
need. I think all we're missing is a spec and maybe a tiny bit of boilerplate
code. Those of us in the Java world involved in web app development are
already doing component-based deployment. That's all a war file spec is. And
it's built right on top of the jar file spec. So why not take that approach
and genericize it a bit. I feel like an effective component framework could be
based on META-INF/* descriptors living inside your jar. We could have this
framework right now without any language changes. But it could also be
integrated into class loaders more tightly. Don't know if that would be
desirable or not. And of course Sun's already done something very much like it
with the script engine discovery spec for
META-INF/services/javax.script.ScriptEngineFactory resource.
Alexey
2001 Honda CBR600F4i (CCS)
1992 Kawasaki EX500
http://azinger.blogspot.com
http://bsheet.sourceforge.net
http://wcollage.sourceforge.net
____________________________________________________________________________________
Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.
http://farechase.yahoo.com/
Casper Bang
dark side) but I find that this little entertaining video explains why
we would want native properties and events fairly well:
http://video.google.com/videoplay?docid=-317659265568822821
In Java, it is insanely easy to be a codehead.
/Casper
On Sep 30, 2:00 am, Alexey Zinger <inline_f...@yahoo.com> wrote:
> The whole component library thing feels like we've already got all the tools we
> need. I think all we're missing is a spec and maybe a tiny bit of boilerplate
> code. Those of us in the Java world involved in web app development are
> already doing component-based deployment. That's all a war file spec is. And
> it's built right on top of the jar file spec. So why not take that approach
> and genericize it a bit. I feel like an effective component framework could be
> based on META-INF/* descriptors living inside your jar. We could have this
> framework right now without any language changes. But it could also be
> integrated into class loaders more tightly. Don't know if that would be
> desirable or not. And of course Sun's already done something very much like it
> with the script engine discovery spec for
> META-INF/services/javax.script.ScriptEngineFactory resource.
>
> 1992 Kawasaki EX500http://azinger.blogspot.comhttp://bsheet.sourceforge.nethttp://wcollage.sourceforge.net