@published String foo;
we suggest you write:
@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);
The old style will continue to work, but the new style has a more predictable timing. In particular, say you use 'foo' in a binding, someone updates that binding, and later you read 'foo'. The old style has no guarantees about what you'll read out of 'foo'. If notifications have been propagated through the system, you'll see the latest value, but if not, you may see the old value. The new style guarantees that you'll see the new value in the binding regardless of the state of the notifications. This also matches how things work in polymer.js elements.
@ComputedProperty('a + b')
String get aPlusB => readValue(#aPlusB);
You can find more details in the dart docs for ComputedProperty
We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).
- Change in @published: There is a variation for how to declare @published properties. Instead of:
@published String foo;
we suggest you write:@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);
Please also update the dart polymer homepage under https:// www.dartlang.org/polymer-dart/ . There is still the old syntax described.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_pK9j9uhRVTasMvxJ_-4mCLobTPPQHwhd1dNvD0tfHG1Q%40mail.gmail.com.
--
For more news and information, visit http://news.dartlang.org/
To join the conversation, visit https://groups.google.com/a/dartlang.org/
--
@PublishedProperty(reflect: true)
String get foo => readValue(#foo);set foo(String value) => writeValue(#foo, value);
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.
--
For more news and information, visit http://news.dartlang.org/
To join the conversation, visit https://groups.google.com/a/dartlang.org/
To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.
Please also update the dart polymer homepage under https:// www.dartlang.org/polymer-dart/ . There is still the old syntax described.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CALz8j4dOcLsVwmBxR51hOeb_Og%2BU%3DD2o-cYG-w2Mk7j1HehD6g%40mail.gmail.com.
On Wed, Jul 30, 2014 at 9:18 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:
Thanks for the great work and for the info!On Thursday, July 31, 2014 2:11:34 AM UTC+2, 'Siggi Cherem' via Dart Announcements wrote:We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).
- Change in @published: There is a variation for how to declare @published properties. Instead of:
@published String foo;
we suggest you write:@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);Are the values of such properties reflected to the attribute and is @PublishedProperty(reflect: true) obsolete then or how does this relate to reflected properties?@publishedProperty(reflect: true) is still needed if you want to make it reflected as an attribute.
Both annotations work the same way in terms of timing, so you can do:@PublishedProperty(reflect: true)String get foo => readValue(#foo);set foo(String value) => writeValue(#foo, value);--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_qDou3Bz9fwewG4CkiCaWKjXoWZWY8y8dp2r5emgs5E-A%40mail.gmail.com.
1. @PublishedProperty(reflect: true) in new syntax?
@PublishedProperty(reflect: true)
String get foo => readValue(#foo);set foo(String value) => writeValue(#foo, value);
2. @observable similar behavior of @published in new syntax?
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/c994e238-f3a1-478a-802f-33f7f4a4e6d6%40dartlang.org.
Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)
To be honest I find it strange that we are moving from boilerplate (@published was already annoying to write) to even *more* boilerplate
> Change in @published ... we suggest you write:
To be honest I find it strange that we are moving from boilerplate (@published was already annoying to write) to even *more* boilerplate.Seriously: foo is mentioned 4 times in the code, and the semantics is duplicated (set -> writeValue, get -> readValue) this is a very bad sign.Can we get a better picture of why this is needed? Is something missing in the language or libraries, why can't transformers do something like this for us, etc.
polymer js implementation and ours were slightly inconsistent in how we dealt with published properties. The timing difference I mentioned in the first announcement is the visible effect to someone using the framework. The differences are very subtle, but you can read in detail what they are in dartbug.com/18343 comment #13.In terms of implementation, the difference is that in Javascript they rewrite the prototype to change a field into a property, and we can't do that in Dart without a transformation.
Yes.It might matter for interoperability between JS elements and Dart elements. And it may be important if you want to rely on certain consistency between what you have in a binding and what you read from public properties of custom elements. Many of us have been building apps without running into this, but it is a race condition, so it might surprise you when you hit a bug related to this.
Not yet.Back in the days of web_ui we were always running a compiler. With pub-serve, a transformer runs when launching code in Dartium, so it is possible to adjust @published properties during this transformation.
On the other hand, we don't require using pub-serve today. Polymer has the advantage that it can run in Dartium without any code transformations. I think some of our users need this for situations where it is not easy to use pub-serve. For example, if you have a server for your application that includes some JSON API, and you want to use it while developing the code in Dartium. With same-origin restrictions, you end up having to serve the Dart code from that server. It's possible to set up a proxy from your server to pub-serve, but it's not trivial.IMHO, we shouldn't require a transformation step until we have an easy and reliable mechanism to support these scenarios. There are many tricks we can use to get there, but they require a considerable amount of work or changes in either the language or the infrastructure. For example, some ideas are:
- Build libraries people can add to their servers to automatically proxy requests (see issue 18039).
- Create a chrome extension that runs the transformation before the page loads in Dartium. We did this for web_ui, but it was hard for users to keep it up to date and deal with multiple versions of the package.
- Run the compiler as a script that launches the app as a new isolate. This requires changes in Dartium which are not expected for a while.
- Ask for changes in the language that would let us do the transformation while the app is loaded. Or changes that would allow us to override properties dynamically.
Maybe?
We could say that by default @published is transformed, but when running in Dartium it may have race conditions. This hybrid approach might lead to surprising results when something works/doesn't work in one mode but works in the other. We could use the boilerplate code as a fallback for those who run into issues, but the problem is that the annotation lives in code that you might not be able to modify (code in a shared library).
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAPD5VRuTDpnAfaDG8rriE2Cn8QWcBBkunrF%2B07SM%2BO8mfLhZSw%40mail.gmail.com.
Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)Any chance you will also convert/wrap Googlewebcomponents (http://googlewebcomponents.github.io/) ?
-g.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/27b6b7ad-4906-41c0-b914-d2425ef4c720%40dartlang.org.
On Thu, Jul 31, 2014 at 10:15 AM, 'Siggi Cherem' via Dart Web Development <w...@dartlang.org> wrote:
On Wed, Jul 30, 2014 at 9:18 PM, Günter Zöchbauer <gzo...@gmail.com> wrote:
Thanks for the great work and for the info!On Thursday, July 31, 2014 2:11:34 AM UTC+2, 'Siggi Cherem' via Dart Announcements wrote:We just uploaded a new stable version of the polymer, core, and paper packages, bringing us up to date with the latest release of polymer.js and it's related libraries (js version 0.3.4 as of today).
- Change in @published: There is a variation for how to declare @published properties. Instead of:
@published String foo;
we suggest you write:@published
String get foo => readValue(#foo);
set foo(String value) => writeValue(#foo, value);Are the values of such properties reflected to the attribute and is @PublishedProperty(reflect: true) obsolete then or how does this relate to reflected properties?@publishedProperty(reflect: true) is still needed if you want to make it reflected as an attribute.The intent isn't very clear in this annotation. Any more thoughts on calling this @attribute ? That's a lot more clear, at least to me :) And then if it matters (for performance?) @attribute(two-way: false) (where two-way is the default)
var x = querySelector('x-foo');x.bar = "hi";...print(x.attributes["bar"]);
"reflect" is an overloaded term, especially with mirrors.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_qDou3Bz9fwewG4CkiCaWKjXoWZWY8y8dp2r5emgs5E-A%40mail.gmail.com.Both annotations work the same way in terms of timing, so you can do:@PublishedProperty(reflect: true)String get foo => readValue(#foo);set foo(String value) => writeValue(#foo, value);--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
--
For more news and information, visit http://news.dartlang.org/
To join the conversation, visit https://groups.google.com/a/dartlang.org/
To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.
- announce,engOn Thu, Jul 31, 2014 at 10:25 AM, George Moschovitis <george.mo...@gmail.com> wrote:
Core 0.1.0+1, Paper 0.1.0+1: The core and paper packages have been updated too, they now have the Dart API associated with the 0.3.4 js elements. Many of the examples have been updated to use some of the changes above (like the better js-interop features)Any chance you will also convert/wrap Googlewebcomponents (http://googlewebcomponents.github.io/) ?Hi George,I'm under the impression that they should "just work". Did you run into a bug when you tried them?
-g.--To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/27b6b7ad-4906-41c0-b914-d2425ef4c720%40dartlang.org.
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CACr%3D8_Of8UYuibAXW5ZzDQtyGy8npeR6Cb1qyQbsuSEebxk%2BHg%40mail.gmail.com.
Thoughts?SiggiTo view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_qDou3Bz9fwewG4CkiCaWKjXoWZWY8y8dp2r5emgs5E-A%40mail.gmail.com.Both annotations work the same way in terms of timing, so you can do:@PublishedProperty(reflect: true)String get foo => readValue(#foo);set foo(String value) => writeValue(#foo, value);--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/672fa515-4b73-41b8-b21c-b0c95dfb43aa%40dartlang.org.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To unsubscribe from this group and stop receiving emails from it, send an email to announce+u...@dartlang.org.--
For more news and information, visit http://news.dartlang.org/
To join the conversation, visit https://groups.google.com/a/dartlang.org/
--
For other discussions, see https://groups.google.com/a/dartlang.org/
For HOWTO questions, visit http://stackoverflow.com/tags/dart
To file a bug report or feature request, go to http://www.dartbug.com/new
To unsubscribe from this group and stop receiving emails from it, send an email to misc+uns...@dartlang.org.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAJmP2_pvLKor-ZTMdUZfr1ZdMNN1DJi9ay-oU%2B_dCaonObp%3Dpw%40mail.gmail.com.
I see, thanks for the background.Indeed it seems we are in a very unfortunate situation here where language is simply to restrictive and lack expressive power to achieve something that JavaScript can achieve easily.I think we should put the following restrictions on ourself here:1) We should never tolerate boilerplate;2) We should match JavaScript behavior;3) We should have fast edit-refresh cycle (which means avoid transformers when running in the pure Dart mode).
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CAPD5VRsYV6w2Up1sUccmV4KHdhHoERmFADfAvKqNSO8EJP-Y9g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/CACr%3D8_OfXKY66b8kQKALQjoLkvEMuZX-Yp1x3Dfuc0cPqfDP%2BQ%40mail.gmail.com.
I'm under the impression that they should "just work". Did you run into a bug when you tried them?
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/1bf49d2a-f10c-4279-8e57-ab868c709112%40dartlang.org.
const attribute = const PublishedProperty(reflect: true);
We handle both Bower and Pub packages in Chrome Dev Editor, so if we could have a formalized, step-by-step, guaranteed-to-work description of what needs to be done, we could do it.Also, several thoughts on @PublishedProperty(reflect: true) and the new boilerplate with readValue/writeValue:* First of all, if you're writing a library of reusable elements, you can't possibly know how they will be used on the other end. That means that the whole thing is a must: otherwise, your end users are bound to run into and give you a headache with bizarre timing issues (we've have more that a fair share of those with our own widgets in CDE).* Second, among the possible solutions that Siggi has suggested under 'Are we willing to always require a transformation step?', quite a few might not work with Chrome apps (e.g. a server proxying requests). Just something to keep in mind.
* Third, at least speaking of @PublishedProperty(reflect: true) vs. @attribute debate, I've added the following in a common source included by all the widgets in CDE:const attribute = const PublishedProperty(reflect: true);
...and use it as:@attribute foo;Question is, is it possible to expand that to auto-generate the entire readValue/writeValue boilerplate? Does Dart's annotations allow that?
On Friday, August 1, 2014 11:46:37 AM UTC-7, sethladd wrote:On Fri, Aug 1, 2014 at 11:27 AM, George Moschovitis <george.mo...@gmail.com> wrote:
I'm under the impression that they should "just work". Did you run into a bug when you tried them?Maybe we have a different interpretation of 'just work'. I would like to do just a 'pub get' and be ready to add html imports to my page.In other words, I am looking for a pub package similar to core_elements and paper_elements.Gotcha, thanks. I think the plan is to integrate Bower with Pub somehow, or let them play nicely together: https://code.google.com/p/dart/issues/detail?id=19354unfortunately, it's not scalable to put every web component into pub. We'll need a way to work with Bower.Glad to see the interest in the google-components!--To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/1bf49d2a-f10c-4279-8e57-ab868c709112%40dartlang.org.
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/5a517c24-ca74-4462-9556-cec59712547f%40dartlang.org.
Question is, is it possible to expand that to auto-generate the entire readValue/writeValue boilerplate? Does Dart's annotations allow that?Unfortunately annotations can't do that. However, to follow up on the feedback and discussions we had here, last week we've started some discussions with the language designers to see if we can pursue some new language feature in this direction.
"Are we willing to always require a transformation step?" "Not yet."
I agree with this, and would say, "Please, please, not ever".
I also agree with @Vyacheslav but understand that it is very hard to reconcile all of his three items. So if we are forced to choose, I would say that item 3 (no transformers) is the most important and should override item 1 (no boilerplate) if necessary.
Like everyone else, I do not like boilerplate. However I dislike “black magic” even more than I dislike boilerplate. Transformers create code that I cannot even see, and if I cannot put a breakpoint on it, then to me it is “black magic” :-). With frameworks that apply a lot of this magic you are basically in a bad place if somethings goes wrong. Also they tend to only be useful for showing of in very simple hello-world or todo items examples. But once you have a large scale complex application you will be willing to trade anything for the ability to see what is actually going on when you debug a really complex scenario involving multiple change notifications triggering each other, and reading properties with timing issues etc.
The explicit syntax for reading and writing the property is actually pretty much how it looks in C# with INotifyPropertyChange and ppl have been doing that for many years without too much complaint. I think Dart should try to do better, but if it is not possible it is nice to know that having explicit notifications are not that bad as has been proven in practice.
Also, in C# there was originally a problem because the notification used strings that had to match the property name which was not refactor friendly. Some smart ppl came up with a way to have a lambda for the property name which would change with property rename refactoring. In Dart we have the #Symbol syntax which is really nice because we don’t have to rely on magic strings and the #Symbol name changes when we refactor rename it’s target. However, I think the analyzer is not checking if the #Symbol actually exists? This makes it easy to make spelling mistakes which are not easy to discover. If there is an issue for this let me know and I will star it.
/Jonas
--
You received this message because you are subscribed to the Google Groups "Dart Web Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web+uns...@dartlang.org.
Visit this group at http://groups.google.com/a/dartlang.org/group/web/.
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/aac160f2-120b-484a-8654-76f91f3830ff%40dartlang.org.
"Are we willing to always require a transformation step?" "Not yet."
I agree with this, and would say, "Please, please, not ever".
To view this discussion on the web visit https://groups.google.com/a/dartlang.org/d/msgid/web/eeeb395b-88de-474c-a1ce-9694fb8f4dc9%40dartlang.org.