[whatwg] Canvas 2d methods

On Sun, 2 Jul 2006, Stefan G?ssner wrote:
> >
> > Each of the methods defined for the canvas 2d context return null. I 
> > think it would be very convenient if instead they would return a 
> > reference to the 2d context for that canvas. This would allow writing 
> > such code as ctx.fill().stroke() or ctx.moveTo(0,0).lineTo(10,10). 
> > This is how many of the native string and array methods work in 
> > javaScript.
>
> I strongly agree and second this.

On Sun, 2 Jul 2006, Andrew Fedoniouk wrote:
> 
> As far as I can see return value is not defined at all in: 
> http://developer.apple.com/documentation/AppleApplications/Reference/SafariJSRef/Classes/Canvas.html#//apple_ref/js/Canvas.lineTo 
> So the proposal is just to define them as returning 'this' instead of 
> nothing.

On Mon, 3 Jul 2006, Stefan Haustein wrote:
> 
> I would like to second the request for returning the context in drawing 
> methods that currently return null.

On Mon, 3 Jul 2006, Ric Hardacre wrote:
> 
> I'm also strongly in favor of this. If only because it seems intuitive 
> considering that this is the norm for most objects in not just the JS 
> universe but increasingly others (e.g. C#, and you can even do it with 
> some objects in VBs) so it's not like we're introducing an alien concept 
> here.

On Mon, 3 Jul 2006, David Hyatt wrote:
>
> I don't think it's intuitive to support chaining only on those methods 
> that happen to return null right now.

On Mon, 3 Jul 2006, L. David Baron wrote:
> 
> In my opinion, this pattern generally makes sense semantically when used 
> on immutable objects (e.g., strings in JavaScript).
> 
> I don't think this pattern makes sense for mutable objects.  It just 
> suggests immutability.  And making the canvas context objects immutable 
> doesn't really make sense without much more significant changes.

On Mon, 3 Jul 2006, Vladimir Vukicevic wrote:
>
> Even without using |with|, why not just create a simple JS wrapper for 
> the context object that can have return-this or any other desired 
> semantics?  This would avoid a change that would have some apps require 
> "canvas 2D 2.0" or some such, and require authors to do version checks 
> to see which version of canvas is supported -- and still write "old" 
> code for quite some time.  Adding "a different way" to do the same 
> things that can be done now without much benefit in simplicity or 
> efficiency doesn't seem useful.
> 
> Canvas supports multiple contexts for a reason; if there are compelling 
> arguments for a complete rev of the 2D API, then a new context can be 
> introduced to support that.

Given that the two first <canvas> implementors are against this change, 
and that the request doesn't introduce a new feature per se, and that 
there are a number of ways to obtain the desired language style even with 
the current spec, and that the DOM APIs don't generally use this calling 
style anyway, I'm going to opt for not changing the spec at this stage.

I understand that this isn't what everyone wanted, and I understand that 
chaining calls is a common idiom in other contexts. The cost of changing 
the spec at this point is just higher than the potential benefit, in my 
opinion. (The cost is quite high, mostly in terms of testing.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 10 May 2007 14:01:12 UTC