(funs) val vs. def revisited..

Do you mean something like this?

scala> object X {
     |   var f: (Int => Int) = _
     |   def apply(x: Int) = f(x)
     | }
defined module X

scala> X.f = { x => 1 }

scala> X(0)
res1: Int = 1

scala> X.f = { x => 2 }

scala> X(0)
res2: Int = 2


On Thu, Apr 9, 2009 at 7:24 AM, Martin S. Weber <martin.weber@nist.gov> wrote:

Hrm.. it's a pity the third part doesn't work. (why would you want to? To assign the result of a higher order fun to an object's apply(). How can you solve that? Another indirection via calling a function value inside the object to which you assign. How will you solve the issue that you cannot know the function type of the returned function? A partial function maybe? Not a pressing issue for me (atm), I just dislike the dichotomy and wonder what others are thinking)

object X {
 val valFun: (Int => Int) = { x => x + 1 }
 def defFun(x: Int) : Int = x + 1
 val apply: (Int => Int) = { x => x + 1 }
}

X.valFun(1)
X.defFun(1)
X(1) // ? X of type object X does not take parameters
X.apply(1)

-Martin

Quoting Alex Boisvert :

> Do you mean something like this?
>
> scala> object X {
> | var f: (Int => Int) = _
> | def apply(x: Int) = f(x)
> | }
> defined module X

Yes that was what I meant when I wrote

>> (...) How can you
>> solve that? Another indirection via calling a function value inside the
>> object to which you assign.

What I'm still wondering is the function's type:

>> How will you solve the issue that you cannot
>> know the function type of the returned function? A partial function maybe?

You fix it to Int => Int, but imagine you want to overload apply
etc. Or you don't know the precise return or argument type yet. Or ..

...

-M

On Thu, Apr 9, 2009 at 7:43 AM, Martin S. Weber <martin.weber@nist.gov> wrote:

How will you solve the issue that you cannot
know the function type of the returned function? A partial function maybe?

 You fix it to Int => Int, but imagine you want to overload apply etc. Or you don't know the precise return or argument type yet. Or ..

Well, Scala is a statically typed language and it imposes restrictions for your own good ;)

Functions types are covariant in their result type and contravariant in their argument types, so this provides some flexibility even if you fix the function type directly.    A function of type (Dog => Food) can be overridden with a function of type (Animal => Meat)

scala> object X {
     |   var f: (Dog => Food) = _
     |   def apply(x: Dog) = f(x)
     | }
defined module X

scala> X.f = { x: Dog => new Food }

scala> X(new Dog)
res1: Food = Food@1ff395a

scala> X.f = { x: Animal => new Meat }

scala> X(new Dog)
res2: Food = Meat@1ee69d3

Another alternative is to use generics if you need more flexibility.  

Heck, you can even use the function type (Any => Any) and cast like there's no tomorrow... but then you're on your own with regards to type errors.  Don't come back complainin' to the compiler because it told you so! ;)

alex

Quoting Alex Boisvert :

> On Thu, Apr 9, 2009 at 7:43 AM, Martin S. Weber wrote:
>>
>> How will you solve the issue that you cannot
>>>> know the function type of the returned function? A partial function
>>>> maybe?
>>>>
>>>
>> You fix it to Int => Int, but imagine you want to overload apply etc. Or
>> you don't know the precise return or argument type yet. Or ..
>
>
> Well, Scala is a statically typed language and it imposes restrictions for
> your own good ;)

And I'm talking about assigning the function at compile-time... I'm
just looking closer at swing.Reactions which likely gets nearer to
what I wanna do..

I am aware that for one function I can use type parameters. I'm also
aware that I could go Any => Any. As I've written in the original
post, "partial functions", because with those from the wrapper
apply(), could check isDefinedAt and only call it then.

I did write my message though to point out the dichotomy of
$Object.(def )apply vs. $Object.(val )apply in usage in contrast to
the non-dichotomy of X.defFun vs. X.valFun (yes I am aware that the
latter is giving access to a function type which then is applied to
its argument, the net-effect is the same though)

Or, in other words: "Wouldn't it be nice if object X { val apply:
(function type) } would perform the same as object X { def apply ... }
?"

-Martin

On Thu, Apr 9, 2009 at 8:16 AM, Martin S. Weber <martin.weber@nist.gov> wrote:

I am aware that for one function I can use type parameters. I'm also aware that I could go Any => Any. As I've written in the original post, "partial functions", because with those from the wrapper apply(), could check isDefinedAt and only call it then.

Just for clarification, a "partial function" would actually be of the form Any => Option[Any].  And you'd still be left with an unsafe cast after isDefinedAt() unless you narrow it with type parameters.

I did write my message though to point out the dichotomy of $Object.(def )apply vs. $Object.(val )apply in usage in contrast to the non-dichotomy of X.defFun vs. X.valFun (yes I am aware that the latter is giving access to a function type which then is applied to its argument, the net-effect is the same though)

Or, in other words: "Wouldn't it be nice if object X { val apply: (function type) } would perform the same as object X { def apply ... } ?"

Alright, if we boil it down to this then yes, on the surface I would agree with you.   I just don't understand enough the ramifications to have an educated opinion about it.

alex

>> Or, in other words: "Wouldn't it be nice if object X { val apply:
>> (function type) } would perform the same as object X { def apply ... } ?"
>
> Alright, if we boil it down to this then yes, on the surface I would agree
> with you. I just don't understand enough the ramifications to have an
> educated opinion about it.

wow.

so, like, how often does the whole def vs. val thing come up? or the
() vs. none? etc.? ok, ok, i know that syntax is hard! :-)

p.s. sorry, i wasn't saying the original question was dumb, if that is
what it sounded like -- apologies. i meant more that i think Scala
seems to have ended up with some overly complex things and it scares
me a bit. which makes me wonder what it does to regular java people.
don't get me wrong, i /daily/ wish i were able to use Scala instead of
Java! but still... :-}

On Thu, Apr 9, 2009 at 10:45 AM, Raoul Duke wrote:
>>> Or, in other words: "Wouldn't it be nice if object X { val apply:
>>> (function type) } would perform the same as object X { def apply ... } ?"
>>
>> Alright, if we boil it down to this then yes, on the surface I would agree
>> with you.   I just don't understand enough the ramifications to have an
>> educated opinion about it.
>
> wow.
>
> so, like, how often does the whole def vs. val thing come up? or the
> () vs. none? etc.? ok, ok, i know that syntax is hard! :-)
>