If you do as Ray suggests and implement @IsLiteral, please make it
work transitively. ie. make this work:
public static T extends IMarker T foo(@IsLiteral ClassT clazz) {
return (T)GWT.create(clazz);
}
The above example is not particularly compelling, but it's the best I
can do right now.
Just idle curiosity here, but why did you have to make the same change
twice? I know you're modifying selection scripts, and maybe that
means you need to violate DRY for some reason, but it strikes me as a
potential refactoring.
Ian
On Mon, Mar 8, 2010 at 9:23 AM, sp...@google.com wrote:
Nathan,
You might want to have a look at super-source, if it's still called
that. If you are willing to put empty definitions of your server-side
classes on the client, then you could reference the class names from
client code without having to modify GWT. It's been too long since
I've touched
On Wed, Oct 21, 2009 at 3:52 PM, John Tamplin j...@google.com wrote:
The problem is more than that. As mentioned above, the actual compiled code
is frequently different depending on the messages, such as when the
parameters are re-ordered in different locales or have different formatting
On Fri, Oct 2, 2009 at 8:06 AM, Joel Webber j...@google.com wrote:
scalac + a decompiler ought to do the trick, roughly. But you'd still end up
with a bunch of big ugly Java constructs for things like functions, case
classes, pattern matching, and the like. And while I'd love to see what
On Thu, Oct 1, 2009 at 8:18 AM, Sami Jaber sami.ja...@gmail.com wrote:
Yes you are right, but do you really think that in the case of a failure,
you would try to change your code flow differently depending on where you
are ? Except displaying a generic message, you won't be able to go further
On Wed, Aug 19, 2009 at 6:28 AM, sp...@google.com wrote:
I like the #x; idea. There is just one potential problem: will XML
readers support it? The linked XML spec has the same restrictions on
encoded character entities as on raw characters appearing in the file.
Does anyone know if that
JUnit 4 has @Theory and @Assumption annotations that might help here.
I forget which does what, but one of them (probably @Assumption) can
say I believe X is true and it needs to be for my tests to pass, so
ignore these if it's false. If there was some way to expose a
predicate that was true
On Fri, Aug 7, 2009 at 10:30 AM, Bruce Johnsonbr...@google.com wrote:
I think assumeThat() might indeed be a good general solution, along the
lines of your examples. It subsumes the annotations I proposed, and it's
nice that it could be generalized easily to any sort of tests. Also, it
On Thu, Jul 16, 2009 at 8:12 AM, r...@google.com wrote:
Index: user/src/com/google/gwt/dom/client/AnchorElement.java
===
--- user/src/com/google/gwt/dom/client/AnchorElement.java (revision
5739)
+++
On Thu, Jul 2, 2009 at 12:14 PM, cromwell...@gmail.com wrote:
Reviewers: scottb,
Description:
This patch removes trailing parenthesis from Javascript 'new' operators
if there
are no constructor arguments.
new Foo() - new Foo
Now with fixes based on Scott's review, as well as some inline
On Wed, Jun 24, 2009 at 9:32 AM, Lex Spoonsp...@google.com wrote:
It's the *call* of runAsync that the compiler pays direct attention
to, not its argument. That's why I am pushing back against approaches
that annotate some aspect of the argument.
I think the push-back is a really good idea.
On Wed, Jun 24, 2009 at 11:15 AM, Lex Spoonsp...@google.com wrote:
On Wed, Jun 24, 2009 at 12:48 PM, Ian Petersenispet...@gmail.com wrote:
The following should be allowed:
@SplitPointName(foo)
final AsyncCallback callback = chooseACallback();
if (flipACoin())
GWT.runAsync(callback);
On Wed, Jun 24, 2009 at 2:08 PM, Ray Cromwellcromwell...@gmail.com wrote:
However, I'm curious, what is the effect of the following:
GWT.runAsync(foo, callback1);
GWT.runAsync(bar, callback1);
That would appear to me to generate identical code, but with two different
named output files.
I
On Wed, Jun 24, 2009 at 2:08 PM, Lex Spoonsp...@google.com wrote:
Thoughts? The main downside I know of is the one John Tamplin has
pointed out: if there are multiple runAsync calls within a single
class -- as sometimes happens -- then the programmer has to code up
some new classes that will
On Mon, Jun 22, 2009 at 2:08 PM, Lex Spoonsp...@google.com wrote:
The options I see are:
1. Annotate the surrounding method with something like @RunAsyncName(Foo)
2. Use the fully-qualified method name surrounding the call.
3. Use the fully-qualified type name of the callback object.
4. Use
On Fri, Jun 19, 2009 at 8:23 AM, Lex Spoonsp...@google.com wrote:
The main tradeoffs I see are that the files version integrates well
with existing tools and IDEs. No matter what build tool you use, you
should be able to get a fast incremental build by using the files
version. On the flip
On Fri, Jun 19, 2009 at 8:33 AM, Lex Spoonsp...@google.com wrote:
This looks like a straightforward and easily understood way to name
calls to runAsync. What do others think?
As a brainstorm-quality idea, what about requiring that runAsync
invocations are in their own methods (as you
On Fri, Jun 19, 2009 at 9:57 AM, Bruce Johnsonbr...@google.com wrote:
My worry about Ian's proposal is
that method overloading complicate things
Excellent point--wasn't thinking about overloads. I think your
solution might be more elegant--it seems easier to explain,
understand, and enforce
Ever since I started using Eclipse, I've always thought that compilers
and make systems should be always on. I'd bet an incremental build
would be hard to pull off first time around, but an always-on GWT
compiler could at least keep the initial JDT parse tree alive
somewhere (in RAM if it's not
Can I suggest checking for $GIT_DIR in the environment? I'm using Git
beside another system at work and, in order to play along better with
the other system, I don't have a .git directory inside my workspace.
Instead, I have a completely separate Git repository and all the Git
tools find it via
On Mon, Apr 20, 2009 at 10:59 AM, Scott Blum sco...@google.com wrote:
That would be a nice enhancement. Patches welcome. :)
How about this?
static boolean looksLikeGit(File dir) {
if (looksLikeSvn(dir)) {
// Prefer svn to git.
return false;
}
File gitDir = findGitDir(dir);
:
This looks good as far as I can eyeball. �...@eric: what do you think?
On Mon, Apr 20, 2009 at 2:18 PM, Ian Petersen ispet...@gmail.com wrote:
On Mon, Apr 20, 2009 at 10:59 AM, Scott Blum sco...@google.com wrote:
That would be a nice enhancement. Patches welcome. :)
How about
LGTM.
On Mon, Apr 20, 2009 at 12:53 PM, Eric Ayers zun...@google.com wrote:
On Mon, Apr 20, 2009 at 3:46 PM, Ian Petersen ispet...@gmail.com wrote:
On Mon, Apr 20, 2009 at 12:36 PM, Eric Ayers zun...@google.com wrote:
Here is a new patch that incorporates the test for $GIT_DIR. I don't
On Mon, Apr 13, 2009 at 1:53 PM, John Tamplin j...@google.com wrote:
On Mon, Apr 13, 2009 at 3:51 PM, Scott Blum sco...@google.com wrote:
If we were playing Mao, I would give you a card penalty for stating the
obvious. :-)
But uh, reliably tracking whether or not you're in a string literal
On Mon, Apr 6, 2009 at 1:47 PM, Bruce Johnson br...@google.com wrote:
(BTW, I could be wrong about the whole let's not have freeform text. It
was just one guy's opinion that it makes things too inconsistent. I'd like
to hear if other people agree/disagree.)
@Other people: agree/disagree?
Seems like this might be related to
http://code.google.com/p/google-web-toolkit/issues/detail?id=2243
I like the idea.
Ian
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
Would it be possible to engineer something that would throw up a
warning message in the hosted mode logger when the client requests one
of the deprecated files? Doing so probably wouldn't catch everybody
because -noserver users would presumably circumvent the check, but it
would probably catch a
On Tue, Jan 13, 2009 at 4:10 PM, gregor greg.power...@googlemail.com wrote:
Well, finding a windows command line svn client looks easier said
than done. I've spent over an hour now trying to find a free one (I've
got no use for it at the moment apart from this issue), and it's not
at all
On Thu, Dec 4, 2008 at 3:03 PM, John Tamplin [EMAIL PROTECTED] wrote:
On Thu, Dec 4, 2008 at 5:02 PM, Bruce Johnson [EMAIL PROTECTED] wrote:
Would it make sense to group fragment files under a subdir whose name is
the strong name of the startup script?
A40BE3F0/
A40BE3F0-001.cache.js
On Mon, Dec 1, 2008 at 3:12 PM, Ray Ryan [EMAIL PROTECTED] wrote:
On Mon, Dec 1, 2008 at 3:02 PM, Ian Petersen [EMAIL PROTECTED] wrote:
First, I think there should be two interfaces, one that only supports
getValue(), and another that inherits from the first and adds
setValue(T). I'll let
On Fri, Oct 31, 2008 at 12:39 PM, aris [EMAIL PROTECTED] wrote:
If I have:
public void onSuccess()
{
objModule.startWorking();
}
And objModule.startWorking is a static method that creates a new
object and starts doing something… the compiler will put all the
objModule code in a
For whatever it's worth, I was initially thrown off by the long type
names. In fact, I think I was surprised that multi-letter names were
allowed by the compiler. But, after my surprise passed, I realized I
like the long names that I have seen.
I think that arguing capital letter means class
On Wed, Oct 22, 2008 at 11:41 AM, Arthur Kalmenson
[EMAIL PROTECTED] wrote:
Great, I've added a ticket already. The code would be helpful though
:P. We'd like to start sending in patches when we find some things to
change.
OK, the code is there now, but what do you use to build your
On Tue, Oct 21, 2008 at 9:07 AM, Arthur Kalmenson [EMAIL PROTECTED] wrote:
I think requiring the HasData interface isn't a bad thing, but this
might frustrate developers in the short term as standard GWT widgets
don't implement the HasData interface.
I don't expect to require HasData, I just
On Tue, Oct 21, 2008 at 6:21 PM, John Tamplin [EMAIL PROTECTED] wrote:
Currently, the translations for the foo method are looked up in files named
A$B_locale.properties. The problem is that some build tools don't like
filenames with $ in them, and while you might be able to work around it
Hi Ray,
On Wed, Oct 8, 2008 at 6:24 PM, Ray Cromwell [EMAIL PROTECTED] wrote:
Something struck me about the way you are approaching things, that
is, letting the BoundField's return widgets. With the new HasData
stuff being proposed, why not let the programmer create the widget,
and bind the
Hi Ray,
I can't answer you fully right now because I'm supposed to be leaving,
but I'll think about your suggestion and get back to you. As it is,
BoundFieldImpl constructs its editor lazily so perhaps a BoundField
could be given an editor rather than constructing one itself.
Also, regarding
On Tue, Oct 7, 2008 at 10:56 AM, Arthur Kalmenson [EMAIL PROTECTED] wrote:
Yes, I'm looking to avoid updating the bean automatically. I want to
specify when the bean should be updated.
I see. I hadn't thought of that use case. As it stands, no, you
can't do that. BoundFieldImplB, P has a
Hi Arthur,
On Tue, Oct 7, 2008 at 1:51 PM, Arthur Kalmenson [EMAIL PROTECTED] wrote:
I don't mean to nitpick, but it's actually the editor that puts back
the previous value, not the converter. The converter just throws a
ConversionException if the String couldn't be converted. It's up to
On Fri, Oct 3, 2008 at 12:07 PM, Ray Ryan [EMAIL PROTECTED] wrote:
I'm with Isaac. I think the case for teaching our Widgets to implement
HasDataT is really clear cut (especially if they also accept DataChange
listeners). The DataManager is a bit harder to justify, and anyway trivial
for
Isaac has also replied while I'm writing this. I now see that Isaac's
and Ray's suggestions are not as all-encompassing as I originally
interpreted them. I'm just stepping out for lunch now, though, so I
don't really have time to think about this properly or reply with the
thoughtfulness that's
On Fri, Oct 3, 2008 at 1:09 PM, Isaac Truett [EMAIL PROTECTED] wrote:
Would Label implement HasDataString?
Yes. HasDataString would essentially replace HasText, wouldn't it?
(As an aside, if HasDataString replaces HasText, perhaps HasText
should be redefined to extend HasDataString.)
Ray
On Fri, Oct 3, 2008 at 5:12 PM, Ian Petersen [EMAIL PROTECTED] wrote:
I just realized I should work up an example project that uses the
library. I'll get to that and post it shortly.
I've started a pretty thorough example, but the office is closing and
I don't have a key so I have leave now
44 matches
Mail list logo
