5 Apr 2004 09:28
Re: Minor syntax question.
On 31 Mar 2004, at 17:24, Mike Spille wrote: > > The difference here is exposing a Closure as an Object vs. treating > it as magic. > > On the Object side of the argument: If you allow only ".call()" > syntax, then you're telling programmers "A Closure is an Object. Deal > with it as such". For conflicts in naming - resolve them as you would > any other object naming conflict. > > On the Magic side: Closures are made unique (and perhaps somewhat > mysteriouswith rules unto themselves. > > Now - as I see it, Closures are conceptually unique - but they are > conceptually unique _objects_, not unique items that fall outside of > the object system. They are constructed with some magic in the > language because that magic is absolutely necessary, and there's some > magic as well in how they can package up their enclosing variable > environment and carry it around with them. But the user doesn't and > shouldn't have to care about that - once it's created, a Closure is > just an object with some interesting semantics. > > By allowing only ".call()" syntax, you're not just eliminating > ambiguity, you're also reinforcing to newbies to the language that a > Closure is a special kind of Object, but when all is said and done > it's still just an object. In this context, it's an Object with a > call() method. Newbies can easily deal with this and understand it, > and they can figure out how to work through naming conflicts because > it's the same way they avoid naming conflicts for anything else back > in Java land. There's a slight extra baggage for newbies, but it's > slight - and I'd argue that even experts can get a bit confused right > now with the existing syntax, and mandated ".call()" is even valuable > to them. Agreed. I'm becoming less and less keen on the () magic with closures. I've already been bitten at least once with confusion over a variable name containing a closure and a method name. At least using foo.call() then its immediately clear of the users intention - that 'foo' is a variable. Saying foo() could mean two things, a local variable called foo which happens to be a closure, or a method called 'foo'. So I think we should maybe back off the () magic. James ------- http://radio.weblogs.com/0112098/
with rules unto themselves.
>
> Now - as I see it, Closures are conceptually unique - but they are
> conceptually unique _objects_, not unique items that fall outside of
> the object system. They are constructed with some magic in the
> language because that magic is absolutely necessary, and there's some
> magic as well in how they can package up their enclosing variable
> environment and carry it around with them. But the user doesn't and
> shouldn't have to care about that - once it's created, a Closure is
> just an object with some interesting semantics.
>
> By allowing only ".call()" syntax, you're not just eliminating
> ambiguity, you're also reinforcing to newbies to the language that a
> Closure is a special kind of Object, but when all is said and done
> it's still just an object. In this context, it's an Object with a
> call() method. Newbies can easily deal with this and understand it,
> and they can figure out how to work through naming conflicts because
> it's the same way they avoid naming conflicts for anything else back
> in Java land. There's a slight extra baggage for newbies, but it's
> slight - and I'd argue that even experts can get a bit confused right
> now with the existing syntax, and mandated ".call()" is even valuable
> to them.
Agreed. I'm becoming less and less keen on the () magic with closures.
I've already been bitten at least once with confusion over a variable
name containing a closure and a method name. At least using foo.call()
then its immediately clear of the users intention - that 'foo' is a
variable. Saying foo() could mean two things, a local variable called
foo which happens to be a closure, or a method called 'foo'.
So I think we should maybe back off the () magic.
James
-------
RSS Feed