Getters/Setters

[Julian Cox]

Hi Hamish,

First off, concrete looks great. I can see it really fitting in with
the jQuery "write less do more" philosophy. I'm sure I'll use it in a
project sometime soon.

There may be a technical reason why this is not possible, but can
getters and setters be made more consistent with jQuery as a whole by
making them the same as the property name and if you pass a value it’s
a setter, if you don't, it’s a getter?

Cheers,
Julian.

[hamish]

> First off, concrete looks great.  I can see it really fitting in with
> the jQuery "write less do more" philosophy.  I'm sure I'll use it in a
> project sometime soon.

Thanks. If you do use it in something and it's publicly accessible,
it'd be cool if you could post a link here. I'm definitely interested
in seeing how other people use it.

> There may be a technical reason why this is not possible, but can
> getters and setters be made more consistent with jQuery as a whole by
> making them the same as the property name and if you pass a value it’s
> a setter, if you don't, it’s a getter?

Short answer:

I've been thinking about adding that. Since someone else wants it too,
I will. It'll be an extension to, not replacement for, current syntax.

Longer answer:

The way the setters and getters are named now are taken from
SilverStripe. Although they're not quite the same as jQuery they do
have the advantage of being easily override-able.

There's a function called concreteData which works the same as regular
jQuery.data, but makes sure that properties in different namespaces
don't collide. The get and set methods are simply wrappers around this
function. Because of this you can easily adjust how they work by
overriding either the getter or the setter.

For instance, you can override the getter to force the returned value
to be an integer by:

$('.selector').concrete({
Foo: 1
getFoo: function(){
return parseInt(this.concreteData('Foo'));
}
})

Or you can trigger an event on set by doing

$('.selector').concrete({
Foo: 1
setFoo: function(val){
this.concreteData('Foo', val);
this.trigger('foochanged');
}
})

The override-ability is important enough that jQuery-style accessors
would be directed to the get / set versions. That is, they'd be the
equivalent of doing

$('.selector').concrete({
Foo: function(val){
if (arguments.length) return this.setFoo(val);
return this.getFoo();
}
})

You can't override jQuery-style accessors, because you'd end up having
the 'Foo' key twice in the same object.

$('.selector').concrete({
Foo: 1,
Foo: function(val){}
})

How does that sound? I'll try and knock up the jQuery-style accessors
and some better examples in the next couple of days

Hamish Friedlander

[Julian Cox]

> Thanks. If you do use it in something and it's publicly accessible,
> it'd be cool if you could post a link here. I'm definitely interested
> in seeing how other people use it.

Will do

> How does that sound? I'll try and knock up the jQuery-style accessors
> and some better examples in the next couple of days

Sounds great. Not urgent though for me though, and if necessary I can
always do the equivalent with the old _ standby...
$('.selector').concrete({
Foo_: 1,
Foo: function(val){
if (arguments.length) return this.setFoo_(val);
return this.getFoo_();
}
})

[Mike Frawley]

> You can't override jQuery-style accessors, because you'd end up having
> the 'Foo' key twice in the same object.
>
> $('.selector').concrete({
>   Foo: 1,
>   Foo: function(val){}
>

What if the properties were namespaced in a 'defaults' or
'properties' object?

$('.selector').concrete({
Properties: { Foo: 1 },
});

That would let you build a same-named get/set fn, though I'm not sure
what other effects that would have.