- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Question about definitions
Sun, 2009-03-15, 22:33
It's the latter.
The former can be produced automatically by adding the scala.reflect.BeanProperty annotation to a field.
If in doubt, use javap to check what the actual name was.
--j
On Sun, Mar 15, 2009 at 12:27 PM, Silvio Bierman <sbierman@jambo-software.com> wrote:
The former can be produced automatically by adding the scala.reflect.BeanProperty annotation to a field.
If in doubt, use javap to check what the actual name was.
--j
On Sun, Mar 15, 2009 at 12:27 PM, Silvio Bierman <sbierman@jambo-software.com> wrote:
Hello Jorge, Actually I do not know what to expect. I would guess that a field 'foo : X' would result in eiter X getFoo() { } void setFoo(X x) { } or X foo() { } void foo(X x) { } The former might conflict with methods named that way already so the latter sounds more likely. Regards, Silvio
From: Jorge Ortiz Sent: Sunday, March 15, 2009 20:22 To: Silvio Bierman Cc: scala-user@listes.epfl.ch Subject: Re: [scala-user] Question about definitions
Naming scheme? They're named as you'd expect. The one "gotcha" is operator symbols. Those are transformed as per the compiler's scala.tools.nsc.util.NameTransformer
--j
On Sun, Mar 15, 2009 at 12:06 PM, Silvio Bierman <sbierman@jambo-software.com> wrote:
Thank you Jorge,
Yes, I know that part about the field access being implemented by methods
calls. I can see two advantages in this: field access can be overridden and
changing a field to a method can be implemented in such a way that it does
not require recompilation.
It complicates the interface with Java somewhat, though. Do you know where I
can find info on the naming scheme used for these methods?
Regards,
Silvio
Jorge Ortiz-3 wrote:
>
> Correct, but...
>
> Remember how I said I was lying about vals/vars being Java fields? They're
> backed by private fields but exposed by public methods. The reason they're
> exposed by public methods is so that they can be overriden in subclasses.
> The bottom line is that they still require a method call, like fun2.
> However, fun2 will allocate a new Function object every time it is called,
> whereas fun3 will return the same (pre-allocated) Function object every
> time.
>
> Methods of the form fun1 can sometimes (as in this case) be converted
> automatically to Function objects. If you want to explicitly force the
> conversion, use: fun1 _
>
> --j
>
> On Thu, Mar 12, 2009 at 7:03 AM, Silvio Bierman
> <sbierman@jambo-software.com
>> wrote:
>
>>
>> Thanks you, guys. This was kind of what I expected but these detailed
>> explanations makes it all clear as a whistle to me now.
>> The thing that threw me off a little was that fun1, fun2 and fun3 are all
>> good candidates for
>>
>> def stub(f : Int => Int,x : Int) = f(x)
>>
>> println(stub(fun1,1) + stub(fun2,2) + stub(fun3,3))
>>
>> but I now understand that fun3 is a direct match for f, fun2 needs to be
>> called to return such an exact match and fun1 needs some implicit
>> coersion
>> to a matching value.
>>
>> Am I correct?
>>
>> Silvio
>> --
>> View this message in context:
>> http://www.nabble.com/Question-about-definitions-tp22471447p22477052.html
>> Sent from the Scala - User mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/Question-about-definitions-tp22471447p22526787.html
Sent from the Scala - User mailing list archive at Nabble.com.