get accessor function name

Hi Francisco,

There was some talk about modifying the language to provide a convenient
way of doing this about a year ago, but AFAIR, nothing came of it.

You've got a few options, none of them ideal:

1. Define a Field type, something like:

class Field[T](var get : T) {
def set(v : T) : Unit = get = v
}

and pass around your field object for these purposes. You could also
define an implicit method:

def fieldValue[T](f : Field[T]) : T = f.get

to avoid having to call .get on all your fields, though note that this
isn't entirely transparent. (Notably, fieldA == fieldB is not the same
as fieldA.get == fieldB.get).

2. Use Java reflection.

I'll let someone else fill in the details here if they feel inclined to,
but you might get some unbelievably dodgy reflection code to do just
what you want it to under certain conditions. But it's so horrible, I
really shouldn't even be suggesting it...

(3. Use a language feature which doesn't exist yet.)

I think there's an opportunity to improve the Scala language with
support for inferring setters. Maybe one day in the near future I'll
write a SIP on this...

Cheers,
Jon

thanks, jon.

for those who are interested, as an exercise i actually started to
create an implementation of wicket's imodel with scala features (a
sort of type-safe version of propertymodel). but for it to make sense
i needed to know the "path", which in scala coincides with the getter.

is there a place to keep track of this eventual language feature?

thanks,

francisco

On Sat, Feb 14, 2009 at 10:06 PM, Jon Pretty wrote:
> Hi Francisco,
>
> There was some talk about modifying the language to provide a convenient
> way of doing this about a year ago, but AFAIR, nothing came of it.
>
> You've got a few options, none of them ideal:
>
> 1. Define a Field type, something like:
>
> class Field[T](var get : T) {
> def set(v : T) : Unit = get = v
> }
>
> and pass around your field object for these purposes. You could also
> define an implicit method:
>
> def fieldValue[T](f : Field[T]) : T = f.get
>
> to avoid having to call .get on all your fields, though note that this
> isn't entirely transparent. (Notably, fieldA == fieldB is not the same
> as fieldA.get == fieldB.get).
>
>
> 2. Use Java reflection.
>
> I'll let someone else fill in the details here if they feel inclined to,
> but you might get some unbelievably dodgy reflection code to do just
> what you want it to under certain conditions. But it's so horrible, I
> really shouldn't even be suggesting it...
>
>
> (3. Use a language feature which doesn't exist yet.)
>
> I think there's an opportunity to improve the Scala language with
> support for inferring setters. Maybe one day in the near future I'll
> write a SIP on this...
>
> Cheers,
> Jon
>
> --
> Jon Pretty | Sygneca Ltd.
>
>

Hi Francisco,

> for those who are interested, as an exercise i actually started to
> create an implementation of wicket's imodel with scala features (a
> sort of type-safe version of propertymodel). but for it to make sense
> i needed to know the "path", which in scala coincides with the getter.

have you taken a look at the slides of the Scala-Wicket presentation I gave in
London 2 weeks ago? There's a 'VarModel' which should suffice as a type-safe
replacement for Wicket's PropertyModel.

Cheers, --- Jan.

hi jan,

(hope this is not too off-topic for the scala mailing list)

yes, i came across the slides and VarModel is roughly what i have
achieved so far. i see you can either instantiate it as a read-only
model, or read/write in which case you need to pass-in the setter.

however, i had defined getObject like so:

def getObject: T = {
try {
getter
} catch {
case npe: NullPointerException => null.asInstanceOf[T]
}
}

to take care of nulls like propertymodel does.

but i wanted to go further, and actually make it a kind of
compoundpropertymodel, where you just provide the getter (or "dotted
path") and it figured out the rest (setter + wicket id == dotted
path). not easy task as you can't right now grab the getter expression
in scala. just experimenting, anyway =)

cheers, and nice slides btw.

francisco

On Thu, Feb 19, 2009 at 12:38 PM, Jan Kriesten
wrote:
>
> Hi Francisco,
>
>> for those who are interested, as an exercise i actually started to
>> create an implementation of wicket's imodel with scala features (a
>> sort of type-safe version of propertymodel). but for it to make sense
>> i needed to know the "path", which in scala coincides with the getter.
>
> have you taken a look at the slides of the Scala-Wicket presentation I gave in
> London 2 weeks ago? There's a 'VarModel' which should suffice as a type-safe
> replacement for Wicket's PropertyModel.
>
> Cheers, --- Jan.
>
>
>

I'd be very interested in those slides, where can I find them?

Cheers,
 -Tako


On Thu, Feb 19, 2009 at 12:38, Jan Kriesten <kriesten@mail.footprint.de> wrote:

Hi Francisco,

> for those who are interested, as an exercise i actually started to
> create an implementation of wicket's imodel with scala features (a
> sort of type-safe version of propertymodel). but for it to make sense
> i needed to know the "path", which in scala coincides with the getter.

have you taken a look at the slides of the Scala-Wicket presentation I gave in
London 2 weeks ago? There's a 'VarModel' which should suffice as a type-safe
replacement for Wicket's PropertyModel.

Cheers, --- Jan.

Hi Tako,

> I'd be very interested in those slides, where can I find them?

there you go: http://www.footprint.de/fcc/2009/02/london-wicket-presentation/

Best regards, --- Jan.