Hey,
On one of the last episode the Javaposse mentioned that glassfish v3
supports save and refresh (like you have in php and other
dynamic,scripting languages). Is this already available and did
anybody test it out yet? I played around with grails and that seemed
to work fine up to a certain poi
I agree with Jess, non-public methods and static methods (with
implementations) would be handy. Also the Scala technique of allowing
fields that are replaced by methods, hence properties, would be great,
e.g.:
interface X { // Assuming keyword interface now meant trait!
int x = 1; // Field
}
w
Good overview Brett,
Personally, being a MS fan, I have to put my hat down to Java
developers for a while now. MS saw that Java was such a good language,
but saw that there were things about the language that could have been
better. Thats what Sun sadi about C++.
Like with many evolutions of a p
I concur. Traits would be a hugely useful addition.
To make them really sing, however, one needs non-public interface
methods. For instance:
public interface Foo
{
public void doIt()
{
// default implementation logic implemented in terms of
getXInternal() and/or
For the most part, Java 5 class files contain metadata indicating much
of what the source file indicated as far as generics are concerned.
This is certainly the case for field/method/class declarations. I'm not
sure about local variable declarations, though.
That said, once one has something
My friends and I had a Halloween party. But we just like dressing up
like freaks. It's the perfect opportunity for the ladies to dress
inappropriately but with unquestionable justification. (I could have
phrased that differently, but chose to be tactful).
--~--~-~--~~~---
On Nov 4, 6:10 am, "Brett Ryan" <[EMAIL PROTECTED]> wrote:
> I don't want to assume, but are most people who couldn't care for
> events/properties server side developers? The real benefit to these
> features is with statefull code, not so much with stateless, since
> stateless code can't really li
Please please please bring on traits! I'm somewhat on the fence of rather
seeing traits than closures in java sooner than the other.
I'm finding LOTS of places in my code where traits would just make things
cleaner.
More and more I think I just want scala :)
On Wed, Nov 5, 2008 at 12:15 PM, hlo
I'm using a few widgets to track that little election thing thats
going on in the States and I would dearly love to have dragged some of
these election map widgets off my browser and onto my desktop.
Sadly they are in Flash and refuse the budge from my browser :).
Maybe that's the dragable apple
I thinks that Traits are a great idea for Java and judging by #215 the
posse, particularly Dick, like them. I wrote about them for Java 7 in:
http://www.artima.com/weblogs/viewpost.jsp?thread=220916
What do you think?
--~--~-~--~~~---~--~~
You received this messag
Here is my analysis of the situation. I could be wrong. But here
goes..
When I got my copy of Java 5 my first question was, do generics really
take the cast out of the equation? I disassembled the code to find
the cast still exists. This implies that when you compile this..
HashMap map = new
I think that, in principle, Java could be extended in interesting ways
and could take cues from other languages (including, sure, C#), but
lately I'm tending to agree with Josh Bloch that Java's complexity
budget is used up. Every change at this point seems to imply a great
risk to instability (or
On Tue, 4 Nov 2008 02:13:29 -0800 (PST), Kim Saabye Pedersen
<[EMAIL PROTECTED]> wrote:
>
> Occording to the adobe knowledge base, flash player is coming in a 64-
> bit edition in an upcoming release:
>
> "Adobe is working on Flash Player support for 64-bit platforms as part
> of our ongoing c
Occording to the adobe knowledge base, flash player is coming in a 64-
bit edition in an upcoming release:
"Adobe is working on Flash Player support for 64-bit platforms as part
of our ongoing commitment to the cross-platform compatibility of Flash
Player. We expect to provide native support for
You asked the (I suppose rhetorical) question, is Halloween celebrated
everywhere?
Well it is in Australia (grinds teeth). It is now, anyway. Never used
to be in the "olden days" (when I was growing up). However it's grown
in popularity in the last decade. It's certainly not as entrenched
here as
Weiqi Gao wrote:
> Are we done with discussing properties?
Well, it might be interesting if anyone had proposals that were more
than skin deep syntactic sugar.
I haven't seen anything that really improves substantively over what one
would have by some sprucing up of JavaBeans APIs and some
Bean
Brett Ryan wrote:
> @Weiqi
>
> Do you like using Introspector? ;) Okay it might be a tongue in cheek
> question, but I'd still much prefer being able to do
> foo.getDeclaredProperties() and have a PropertyDescriptor array
> returned without the penalty of the Introspector having to go and
> disco
Sure there's type safety there... The compiler will ensure the get and
set are both of the same type, otherwise you get a compile time error.
How much more type safety could you get than that?
On Wed, Nov 5, 2008 at 4:57 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
> The examples given for C# showe
The examples given for C# showed shorthand for expressing properties but
showed nothing in the way of actually improving type safety.
Moreover, being able to use foo->bar rather foo.getBar()/foo.setBar() is
also just sugar -- the latter are perfectly type safe.
Brett Ryan wrote:
> Okay, so wher
The difference between Introspector and the language really is
irrelevant to a degree.
If the Introspector and JavaBeans APIs provide suitable capabilities and
type-safety, then we're set in my book. If not, then /add /them --
don't invent something else entirely.
If we want type-safe usage t
Okay, so wheres the answer for compile time safety?
My attached ad-hoc code was not meant to be used, it was to
demonstrate what Introspector or any other inspector needs to do to
discover properties. What you get back are `assumed' properties (if
BeanInfo classes haven't been defined).
-Brett
What I'm trying to get at is we don't have type safety in properties.
Introspector is simply a convenience to find our assumed properties
for us. It's not part of the language but part of the class libraries
that come with the language.
I think we've gone off on a tangent ;)
-Brett.
On Wed, Nov
Brett Ryan wrote:
> @Weiqi
>
> Do you like using Introspector? ;) Okay it might be a tongue in cheek
> question, but I'd still much prefer being able to do
> foo.getDeclaredProperties() and have a PropertyDescriptor array
> returned without the penalty of the Introspector having to go and
> discove
@Weiqi
Do you like using Introspector? ;) Okay it might be a tongue in cheek
question, but I'd still much prefer being able to do
foo.getDeclaredProperties() and have a PropertyDescriptor array
returned without the penalty of the Introspector having to go and
discover them.
-Brett
On Wed, Nov 5
Brett Ryan wrote:
>> Yes, these two are vastly different, as I've expressed earlier you
>> can't simply identify a property on a Class, take my attached example
>> a few posts ago and you'll see what I mean.
>>
>> When you traverse Foo.class.getDeclaredMethods() that match a pattern
>> of set|get.*
Brett Ryan wrote:
>
> But it's not baked into swing and other areas where a component model
> is needed, there maybe API's out there, but they aren't something I
> can discover. If I'm given a component from some component author who
> has quite simply developed some swing control, how do I place
>
> If you do have a way to unify getters/setters into a property without
> having to try and discover them I'd be interested to see.
>
First, I don't necessarily want to expose get/set methods. Second I
don't necessarily want clients to discover them. That said, Swing is at
the edge of the
>>
>> Maybe I've missed the point but :-)
>>
>
> Yes, these two are vastly different, as I've expressed earlier you
> can't simply identify a property on a Class, take my attached example
> a few posts ago and you'll see what I mean.
>
> When you traverse Foo.class.getDeclaredMethods()
> Yes, these two are vastly different, as I've expressed earlier you
> can't simply identify a property on a Class, take my attached example
> a few posts ago and you'll see what I mean.
>
> When you traverse Foo.class.getDeclaredMethods() that match a pattern
> of set|get.* and then pair the two
Jess Holle wrote:
> There's no reason that the getter/setter conventions from the
> JavaBeans spec cannot be interpreted in just as type-safe a manner as
> some official "Property" construct.
>
> I will /not/ argue that the current state of affairs is anywhere near
> perfect here in Java. For s
Brett Ryan wrote:
> Yes, these two are vastly different, as I've expressed earlier you
> can't simply identify a property on a Class, take my attached example
> a few posts ago and you'll see what I mean.
>
> When you traverse Foo.class.getDeclaredMethods() that match a pattern
> of set|get.* and t
>> private int foo;
>> public int Foo {
>> get { return foo; }
>> set {
>> if (value < 0)
>> ArgumentOutOfRangeException("Value for property Foo must be >=
>> 0");
>> foo = value;
>> }
>> }
>>
>
> private int foo;
>
> public int getFoo() { return foo; }
>
>
> private int foo;
> public int Foo {
> get { return foo; }
> set {
> if (value < 0)
> ArgumentOutOfRangeException("Value for property Foo must be >=
> 0");
> foo = value;
> }
> }
>
private int foo;
public int getFoo() { return foo; }
public voi
>>
> First class methods are roughly the same as delegates which are
> essentially the Java/C# equivalent of function pointers.
Sure and the point is roughly. So pardon my language nit but I'd much
rather talk about methods as first class objects than function pointers. ;-)
Regards,
Kirk
-
@Jess Holle
> There are plenty of good use cases for a stateless listener, but clearly
> UI's involve state no matter how you try to avoid it :-)
Point taken ;-)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups "The
Properties are a 1-to-1 relationship of a classes member and the state
it's representing,
>>> which is a violation of encapsulation and promotes unnecessary couplings.
>>>
>>
>> That 1-to-1 relationship is the encapsulation, and it's actually
>> promoting the point.
>>
> Encapsulati
Brett Ryan wrote:
> @kir
>>> Properties are a 1-to-1 relationship of a classes member and the state
>>> it's representing,
>>>
>> which is a violation of encapsulation and promotes unnecessary couplings.
>>
> That 1-to-1 relationship is the encapsulation, and it's actually
> promoting t
At runtime you can take class Foo and determine that it requires
generic type parameters, but you can take an instance of Foo and
find out what generic type parameter T is. For a decompiler (while I'm
just speculating) it shouldn't need to know what type an instance of
Foo is as it's just trying t
Brett Ryan wrote:
> I don't think they are syntactic sugar, like I've mentioned previously
> a Property isn't simply a wrapper around getFoo/setFoo methods, they
> are a separate construct that does allow for type safety of some
> state. If you're a component designer and you come across a class wi
Brett Ryan wrote:
> @kirk
>
>
>>> Properties are a 1-to-1 relationship of a classes member and the state
>>> it's representing,
>>>
>> which is a violation of encapsulation and promotes unnecessary couplings.
>>
>
> That 1-to-1 relationship is the encapsulation, and it's actually
>
@kirk
>> Properties are a 1-to-1 relationship of a classes member and the state
>> it's representing,
> which is a violation of encapsulation and promotes unnecessary couplings.
That 1-to-1 relationship is the encapsulation, and it's actually
promoting the point.
>> To properly get closures, y
>
> Properties are a 1-to-1 relationship of a classes member and the state
> it's representing,
which is a violation of encapsulation and promotes unnecessary couplings.
> To properly get closures, you need function pointers, and that's why
> we need them in Java, and with function pointers we
I don't think they are syntactic sugar, like I've mentioned previously
a Property isn't simply a wrapper around getFoo/setFoo methods, they
are a separate construct that does allow for type safety of some
state. If you're a component designer and you come across a class with
String getFoo(); void s
Brett Ryan wrote:
> So hey, now we have PEDL, the four language features required to power
> Java ahead of C#.
>
> Properties, Events, Delegates and Lambda expressions :)
>
I won't say these aren't much better in C# than in Java.
I will say the examples given in posts thus far haven't really pr
What's funny, is that Joe was saying: If it's in the class file it should be
in the reflection API as an extension... Well that's exactly how it goes.
All the "erased by erasure" information is in the class file. So, you can
query generics and annotations on a class file.
The problem if you get a L
@Pete F
> again -take a long view -C# is doing the heavy lifting right now,
> implementing experimental stuff like linq that will take its toll on
> the language, and inevitably cripple c# with backwards compatibility
> restrictions, -about then would be a good time for son-of-java
> (literall
@RoverV
I very much agree with you that the java ecosystem has a vast plethora
of frameworks to help us along, mind you C# is starting to pick up the
pace with codeplex and IoC/DI frameworks like Unity. They also didn't
really need a NIO because they got IO right from the beginning. The
build sys
> I'm sorry Casper, that's not a darn good question.
i think it is a gosh darn good question Casper ;-), because it goes to
the rather obvious similarities between the two languages and
runtimes -and more importantly to the fantasy that they are
radically different
Weiqi Gao's list of languag
Seriously, there's no reason to think he would be "unpopular" by
suggesting to improve the Java language, and to look at other languages
to do so. The Java community, and this group in particular, are not THAT
close-minded.
Now I suspect YOU're trying to start a flamewar, Casper, with your
com
I wonder if anyones looked at writing a C# compiler for the JVM?
On Mon, Nov 3, 2008 at 11:43 PM, Pete F
<[EMAIL PROTECTED]>wrote:
>
> Well yes, there is the argument that Java.next already exists -and is
> called C# :-) (or is java.next called android?)
>
--
"It is easier to optimize corre
For my current employer I've written a lot C# .NET application code
and Java middle-tier code.
On balance, if I were to be tossed on a desert island and could have a
choice of only one of these 2 languages, I'd opt for Java (as long as
I get an Internet connection and Maven). In the end I find it
Greetings Adam,
as mentioned before by Mike, Lift is a Scala product.
Also, I happen to know that there are a few companies out there who have
adopted Scala:
i.e. Sygneca in the UK, a company called Triental in Sweden (Jonas Bonér
(creator of AspektWerkz, Terracottatech guy)), there's a company in
52 matches
Mail list logo
