yes I am not sure if it is great, but it may just be acceptable -
given people can turn it on/off depending if they like it.
On Feb 8, 10:29 am, Reinier Zwitserloot wrote:
> Not convinced myself that this is an acceptable alternative, but:
>
> What if we just bite the bullet and say that use of
I've found this library quite handy: http://javatuple.com/
On Feb 8, 10:41 pm, Keith Haber wrote:
> Our team's Pair class has a few extra methods in it that make it non-
> trivial enough to justify putting it into a reusable jar file (with
> other utility classes we've come up with, of course).
One reason I was thinking of the array style return, is that means we're not
actually replacing javas "single return type" idiom, we're just changing the
type system slightly to allow us syntactic sugar around that single return
value (I'm thinking this would easier than the alternatives, maybe).
Our team's Pair class has a few extra methods in it that make it non-
trivial enough to justify putting it into a reusable jar file (with
other utility classes we've come up with, of course).
Our Pair implements java.lang.Comparable. It compares first element
to first element, then second elemen
Another vote for Google RFC-2445: we've been using it in our
application for over a year, no problems. It was even fairly easy to
extend it to support hourly recurrences required by our domain.
Chris
On Jan 30, 10:20 am, Robin wrote:
> by way of an update for anyone interested we went for this
Hi Mark,
Smells similar to how Matlab passes multiple return arguments. The []
give the feeling that it is an array, which I like, but I'm not too
keen on accessing the elements by index. Following is an alternate
suggestion for how to use the return arguments:
[Integer foo, String bar] = d
Reinier Zwitserloot wrote:
> having foo->bar mean something -entirely- different from foo->bar()
> would be extremely bad.
>
foo.bar means something entirely different than foo.bar(), unless you
consider fields and methods to be the same thing.
That said using "->" for both properties and dyn
Thank you for your comments.
Par is spanish for Pair. It seems close enough. Also, the name pops up
in third pary code from time to time.
car and cdr are names on the back of my head, from being lisped a few years ago.
I don't like returning non-serializable pairs, so I decided it would
be better
Reinier Zwitserloot wrote:
>
> If you've been adding it to every project, why not make a jar out of
> it?
Because that would be more work than writing the class.
--
Weiqi Gao
weiqi...@gmail.com
http://www.weiqigao.com/blog/
--~--~-~--~~~---~--~~
You received th
having foo->bar mean something -entirely- different from foo->bar()
would be extremely bad.
If -> syntax is used for properties, we must accept that -> is 'taken'
and can not be coopted for something else (unless that something is so
close in spirit to properties that it would be allright). So, t
What's with the serializable? What's with the typo from pair to par?
You can make Pair serializable and then make P and Q not explicitly
serializable. If you pass in serializables, it'll work. If you don't,
it won't. That seems like a better solution than forcing. A powerful
type system should be
Although, as you say, they're both geared towards artists and
designers and live on the Java platform, JavaFX and Processing are
pretty different as far as I can tell (having spent significantly more
time in Processing than in JavaFX). Processing allows you to easily
create and process media data,
Dynamic /methods/ could still be referenced by -> as foo->bar is clearly
different than foo->bar().
phil.swen...@gmail.com wrote:
> I don't object to "->" if that's what it takes to get everyone on
> board with properties. I had half hoped that one day java will add in
> dymanic methods with the
I don't object to "->" if that's what it takes to get everyone on
board with properties. I had half hoped that one day java will add in
dymanic methods with the "->" notation (like Fan does), but being
realistic that's not doing to happen.
On Feb 8, 11:11 am, Jess Holle wrote:
> My thinking is
We have Tuple2, Tuple3, Tuple4 in our utils package, rather handy. Wish
this was avaialable directly in the language, probably as form of
generic/typed "array", maybe something like:
public [Integer,String] doSomething() {
return new [Integer,String] {5, "Hello"};
}
...
Integer foo = doSomethi
My thinking is that when you combine Java's lowercase field and property
naming conventions with use of the existing "." notation for properties
you cause confusion. Sure you can create rules that eliminate all
ambiguity, but these are inevitably tricky for developers. For instance
if foo.bar
If you are a Java coder and you don't use an IDE, you are crazy and
are giving up huge productivity gains. But that's another thread.
But yes, you should be able to look at a code snippet and tell what's
going on. But I don't think properties would be hard to follow. I
never had an issue in D
H
I still know a good number of Java programmers who don't use IDEs. I
see ad hoc code review and browsing via e-mail or web pages with
insufficient knowledge of the code to do such highlighting.
While I use an IDE, I've always been reluctant to assume that somehow
the usage patterns
On Sun, Feb 8, 2009 at 2:40 PM, Weiqi Gao wrote:
>
> marcelomorales.n...@gmail.com wrote:
> > This is the first time I've felt the need to change the language. I
> > guess everybody else here wants other changes. I've got this class in
> > every project I've worked on for the last 2 years. Anybod
marcelomorales.n...@gmail.com wrote:
> This is the first time I've felt the need to change the language. I
> guess everybody else here wants other changes. I've got this class in
> every project I've worked on for the last 2 years. Anybody has a
> better one?
public class Pair {
public Object
Cool. Thank you both for the insight.
On Feb 7, 7:25 pm, Steven Herod wrote:
> I've used that library and simulated up to 40 clients reading and
> writing from an sqlite db. Unless moz is doing some thing unusual
> sqlite only locks on write operations and the lock handling approach
> is to jus
This is the first time I've felt the need to change the language. I
guess everybody else here wants other changes. I've got this class in
every project I've worked on for the last 2 years. Anybody has a
better one?
public class Par
implements Serializable {
static final long serialVersionUID
22 matches
Mail list logo
