On Fri, Feb 19, 2010 at 8:58 AM, David Herman <dher...@mozilla.com> wrote:
> First, this traits proposal looks very nice -- thanks, Tom and Mark, for
> your work on this.
>
> I want to add another point about the benefit of new syntax by calling out
> a piece of the code.google.com proposal under "Performance," where it
> says: "In order for the partial evaluation scheme to work, programmers
> should use the library with some restrictions." This is one of the places
> where you have the opportunity to call out more precisely in the language
> where users can expect better performance. By creating a declarative syntax,
> you invite implementors to make the common cases efficient, and provide a
> clearer set of rules for programmers to know when they are or aren't
> straying into "you can do that, but it'll cost you" territory.
>
> Another side of the same coin is that you /dis/invite users from
> accidentally straying into the expensive territory. The convenient syntax
> provides an incentive for people to use the version you want to be the
> common case.
>
> On Feb 19, 2010, at 7:29 AM, Kam Kasravi wrote:
>
> > Picking up where Tom left off below... I've wondered how you and the
> ECMAScript body prefer to have
> > particular concepts presented. Given that the lag time between new syntax
> and conformance across vendors
> > could be months, years or never, it seems that there is always a need to
> provide a 'shim'
> > or implementation that emulates proposed syntax. I think many concepts
> including Tom and Mark's
> > steer away from new syntax due to the problems noted. In general should
> there be due diligence on both?
> > I realize this may vary per strawperson but thought you may have a
> general philosophy to share.
>
> I know your question was to Brendan, but if I may add my $.02: we should be
> mindful but not terrified of changing the language. That's what we're here
> to do, after all!
>
> Now, the specific concern over new syntax has been that it prevents a
> program from even running, which means you can't dynamically test for a
> feature before using it.
In for a penny in for a pound. Harmony will already have other new syntax,
so this need not be an impediment for a traits proposal. When the benefits
of the new syntax are great enough to pay for the cost of new syntax, by all
means. For example, I felt that new syntax was justified for my old
classes-as-sugar proposal. I only wish to remind everyone to exercise
skepticism and restraint. E grew too much syntax over time even though each
bit of new syntax seemed justified by itself. The benefits of new syntax are
easily apparent. The costs of new syntax are diffuse and most burdensome on
those newly learning the language, and so are easy to underestimate,
especially by us experts.
So let us experiment with syntactic support for traits. But let's just be
careful before blessing any of these experiments. Apple pie I know, but
worth saying.
> Putting aside the fact that you could use `eval' (or dynamic module
> loading, given a module system) for such a purpose, I'm still not sure how
> often people actually want to build two different implementations of a
> program based on whether or not a particular feature exists. We shouldn't
> hold back the language just because it'll take take for new features to be
> spread enough for commonplace use. That's all the more reason to move
> forward sooner than later.
>
> That said, I think something like the traits library could have a nice
> migration path, where a library compatible with ES5 could be even more
> attractive down the road with new syntax.
>
> Dave
>
>
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
