|
def xx and def xx () not the same?
at some point in 2.8 it happened that
def xx = 13
and
def xx () = 13
are not the same anymore.
I can't call the first with ()...i.e.
class Test13 {
def xx = 13
xx () // compilation error: xx doesn't take parameters or smth like that
}
it's annoying...why this righteousness ?
|
|
Re: def xx and def xx () not the same?
On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
> at some point in 2.8 it happened that [...]
Welcome to Scala version 2.7.5.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_15).
scala> def xx = 13
xx: Int
scala> xx()
<console>:6: error: xx of type Int does not take parameters
xx()
^
Welcome to Scala version 2.7.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_15).
scala> def xx = 13
xx: Int
scala> xx()
<console>:6: error: xx of type Int does not take parameters
xx()
^
Welcome to Scala version 2.6.1-final.
scala> def xx = 13
xx: Int
scala> xx()
<console>:6: error: xx of type Int does not take parameters
xx()
^
> it's annoying...why this righteousness ?
The path of the righteous man is beset on all sides by the iniquities of
the selfish and the tyranny of evil men. Blessed is he, who in the name
of charity and good will, shepherds the weak through the valley of
darkness, for he is truly his brother's keeper and the finder of lost
children.
--
Paul Phillips | One way is to make it so simple that there are
Everyman | obviously no deficiencies. And the other way is to make
Empiricist | it so complicated that there are no obvious deficiencies.
i pull his palp! | -- Hoare
|
|
Re: def xx and def xx () not the same?
On Thu, Nov 5, 2009 at 9:04 PM, Paul Phillips < paulp@...> wrote:
> On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
>> it's annoying...why this righteousness ?
>
> The path of the righteous man is beset on all sides by the iniquities of
> the selfish and the tyranny of evil men. Blessed is he, who in the name
> of charity and good will, shepherds the weak through the valley of
> darkness, for he is truly his brother's keeper and the finder of lost
> children.
That is is some cold-blooded shit to say to a man before you answer
their questions. Are you the shepherd, or the tyranny of evil men?
-- David
|
|
Re: def xx and def xx () not the same?
Oops - my bad, so it's been like that for a while...my memory must still be trick or treating...bad memory!
I don't get the subtleties, but I need a bit more shepherding: it seems asymmetrical...and I don't like asymmetrical... stuff! Does it need to be?
def xx() =13
xx // works
and
def xx = 13 // the simpler form
xx () // it doesn't works !
Paul Phillips-3 wrote:
On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
> at some point in 2.8 it happened that [...]
Welcome to Scala version 2.7.5.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_15).
scala> def xx = 13
xx: Int
scala> xx()
<console>:6: error: xx of type Int does not take parameters
xx()
^
Welcome to Scala version 2.7.1.final (Java HotSpot(TM) 64-Bit Server VM, Java 1.6.0_15).
scala> def xx = 13
xx: Int
scala> xx()
<console>:6: error: xx of type Int does not take parameters
xx()
^
Welcome to Scala version 2.6.1-final.
scala> def xx = 13
xx: Int
scala> xx()
<console>:6: error: xx of type Int does not take parameters
xx()
^
> it's annoying...why this righteousness ?
The path of the righteous man is beset on all sides by the iniquities of
the selfish and the tyranny of evil men. Blessed is he, who in the name
of charity and good will, shepherds the weak through the valley of
darkness, for he is truly his brother's keeper and the finder of lost
children.
--
Paul Phillips | One way is to make it so simple that there are
Everyman | obviously no deficiencies. And the other way is to make
Empiricist | it so complicated that there are no obvious deficiencies.
i pull his palp! | -- Hoare
|
|
Re: def xx and def xx () not the same?
Well - to be exact, that came after answering half the question...not before :)
David Hall-17 wrote:
On Thu, Nov 5, 2009 at 9:04 PM, Paul Phillips <paulp@improving.org> wrote:
> On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
>> it's annoying...why this righteousness ?
>
> The path of the righteous man is beset on all sides by the iniquities of
> the selfish and the tyranny of evil men. Blessed is he, who in the name
> of charity and good will, shepherds the weak through the valley of
> darkness, for he is truly his brother's keeper and the finder of lost
> children.
That is is some cold-blooded shit to say to a man before you answer
their questions. Are you the shepherd, or the tyranny of evil men?
-- David
|
|
Re: def xx and def xx () not the same?
On Thu, Nov 5, 2009 at 10:16 PM, Razvan Cojocaru < razvanc99@...> wrote:
>
> Oops - my bad, so it's been like that for a while...my memory must still be
> trick or treating...bad memory!
>
> I don't get the subtleties, but I need a bit more shepherding: it seems
> asymmetrical...and I don't like asymmetrical... stuff! Does it need to be?
>
> def xx() =13
> xx // works
> and
> def xx = 13 // the simpler form
> xx () // it doesn't works !
So, yes, it's asymmetrical. The Scala way to do things is that things
that are logically getters should have no argument lists, and things
that are logically operations should take 1 empty arg list.
A reason (maybe the reason?) it's asymmetrical is to make Java interop
look prettier. It's more scala-like to make to say .toString, and not
.toString(), but Java doesn't understand the difference. I believe
it's been proposed to only allow it in the case of calling Java apis;
I have doubts that will happen any time soon.
(And adapting movie quotes doesn't always come out exactly the way you want...)
-- David
>
>
> Paul Phillips-3 wrote:
>>
>> On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
>>> at some point in 2.8 it happened that [...]
>>
>> Welcome to Scala version 2.7.5.final (Java HotSpot(TM) 64-Bit Server VM,
>> Java 1.6.0_15).
>> scala> def xx = 13
>> xx: Int
>>
>> scala> xx()
>> <console>:6: error: xx of type Int does not take parameters
>> xx()
>> ^
>>
>> Welcome to Scala version 2.7.1.final (Java HotSpot(TM) 64-Bit Server VM,
>> Java 1.6.0_15).
>> scala> def xx = 13
>> xx: Int
>>
>> scala> xx()
>> <console>:6: error: xx of type Int does not take parameters
>> xx()
>> ^
>>
>> Welcome to Scala version 2.6.1-final.
>> scala> def xx = 13
>> xx: Int
>>
>> scala> xx()
>> <console>:6: error: xx of type Int does not take parameters
>> xx()
>> ^
>>
>>> it's annoying...why this righteousness ?
>>
>> The path of the righteous man is beset on all sides by the iniquities of
>> the selfish and the tyranny of evil men. Blessed is he, who in the name
>> of charity and good will, shepherds the weak through the valley of
>> darkness, for he is truly his brother's keeper and the finder of lost
>> children.
>>
>> --
>> Paul Phillips | One way is to make it so simple that there are
>> Everyman | obviously no deficiencies. And the other way is to
>> make
>> Empiricist | it so complicated that there are no obvious
>> deficiencies.
>> i pull his palp! | -- Hoare
>>
>>
>
>
> -----
> Razvan Cojocaru,
> Work: http://www.sigma-systems.com> Me: http://feeds.razie.com/RazvanTech> --
> View this message in context: http://old.nabble.com/def-xx-and-def-xx-%28%29-not-the-same--tp26226554p26227373.html> Sent from the Scala - User mailing list archive at Nabble.com.
>
>
|
|
Re: def xx and def xx () not the same?
On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
> I don't get the subtleties, but I need a bit more shepherding: it
> seems asymmetrical...and I don't like asymmetrical... stuff! Does it
> need to be?
It does. Helpfully supplying missing parentheses is (mostly)
unambiguous; also helpfully unsupplying possibly unnecessary parentheses
is definitely not. Most things are asymmetrical you know. Ints are
widened to longs but longs aren't crushed down to ints. Methods can be
turned into functions but functions can't become methods. I can do this
all day.
If def foo returns something with an apply method then the parens are
calling apply. If you want to strip them away you'd have to apply some
very ill-advised heuristic.
scala> def foo = new { def apply() = "hi mom" }
foo: java.lang.Object{def apply(): java.lang.String}
scala> foo()
res0: java.lang.String = hi mom
At one point there was some noise about making the scala side tighter
about call site paren usage matching definition site, but something came
up and now it is only spoken of in hushed voices.
--
Paul Phillips | Where there's smoke, there's mirrors!
Protagonist |
Empiricist |
pal, i pill push |----------* http://www.improving.org/paulp/ *----------
|
|
 Re: def xx and def xx () not the same?
-------------------------------------
David Hall< dlwh@...> wrote:
On Thu, Nov 5, 2009 at 9:04 PM, Paul Phillips < paulp@...> wrote:
> On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
>> it's annoying...why this righteousness ?
>
> The path of the righteous man is beset on all sides by the iniquities of
> the selfish and the tyranny of evil men. Blessed is he, who in the name
> of charity and good will, shepherds the weak through the valley of
> darkness, for he is truly his brother's keeper and the finder of lost
> children.
That is is some cold-blooded shit to say to a man before you answer
their questions. Are you the shepherd, or the tyranny of evil men?
-- David
|
|
Re: def xx and def xx () not the same?
I believe the reason is to allow properties to be interchangeable with
functions. So:
object Foo {
val xx = 12
}
can some day become:
object Foo {
def xx = { println("getting xx"); 12 }
}
and then back to the original form when you realize you forgot to take
out your debug print, without anyone being able to compile something
with xx() in the meantime.
On Thu, Nov 5, 2009 at 10:40 PM, Paul Phillips < paulp@...> wrote:
> On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
>> I don't get the subtleties, but I need a bit more shepherding: it
>> seems asymmetrical...and I don't like asymmetrical... stuff! Does it
>> need to be?
>
> It does. Helpfully supplying missing parentheses is (mostly)
> unambiguous; also helpfully unsupplying possibly unnecessary parentheses
> is definitely not. Most things are asymmetrical you know. Ints are
> widened to longs but longs aren't crushed down to ints. Methods can be
> turned into functions but functions can't become methods. I can do this
> all day.
>
> If def foo returns something with an apply method then the parens are
> calling apply. If you want to strip them away you'd have to apply some
> very ill-advised heuristic.
>
> scala> def foo = new { def apply() = "hi mom" }
> foo: java.lang.Object{def apply(): java.lang.String}
>
> scala> foo()
> res0: java.lang.String = hi mom
>
> At one point there was some noise about making the scala side tighter
> about call site paren usage matching definition site, but something came
> up and now it is only spoken of in hushed voices.
>
> --
> Paul Phillips | Where there's smoke, there's mirrors!
> Protagonist |
> Empiricist |
> pal, i pill push |----------* http://www.improving.org/paulp/ *----------
>
--
Alex Neth
Liivid, Inc
www.liivid.com
+1 206 499 4995
+86 13761577188
Marie von Ebner-Eschenbach - "Even a stopped clock is right twice a
day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
|
|
RE: def xx and def xx () not the same?
Wasn't
it also a recommended convention to specify the brackets to indicate use of
methods causing side-effects?
For
example, use println(), not println
Kieron
I believe the reason is to allow properties to be interchangeable
with functions. So: object Foo { val xx = 12 } can
some day become: object Foo { def xx = { println("getting xx"); 12 }
} and then back to the original form when you realize you forgot to
take out your debug print, without anyone being able to compile something
with xx() in the meantime.
This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.
Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.
|
|
Re: def xx and def xx () not the same?
It's a lot better than the corporate disclaimers many people spurt
into public mailing lists. Hell, one person's disclaimer prevents us
from replying to emails and including the list!
"This message may contain confidential and privileged information and
is intended solely for the use of the named addressee. Access, copying
or re-use of the e-mail or any information contained therein by any
other person is not authorised. If you are not the intended recipient
please notify us immediately by returning the e-mail to the originator
and then immediately delete this message. Although we attempt to sweep
e-mail and attachments for viruses, we do not guarantee that either
are virus-free and accept no liability for any damage sustained as a
result of viruses."
2009/11/6 David Hall < dlwh@...>:
> On Thu, Nov 5, 2009 at 9:04 PM, Paul Phillips < paulp@...> wrote:
>> On Thu, Nov 05, 2009 at 08:56:49PM -0800, Razvan Cojocaru wrote:
>>> it's annoying...why this righteousness ?
>>
>> The path of the righteous man is beset on all sides by the iniquities of
>> the selfish and the tyranny of evil men. Blessed is he, who in the name
>> of charity and good will, shepherds the weak through the valley of
>> darkness, for he is truly his brother's keeper and the finder of lost
>> children.
>
> That is is some cold-blooded shit to say to a man before you answer
> their questions. Are you the shepherd, or the tyranny of evil men?
>
> -- David
>
--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...
|
|
Re: def xx and def xx () not the same?
This is wacky - possible but should be avoided....since it's not strait-forward and hard to understand/debug...I'm actually inclined to consider allowing that a bug...
I still don't see why def xxx is not the same as def xxx () - in fact you're defining a function with no arguments, in both cases - is that not true? Splitting hairs over the parens operator ... only confuses most people. I've worked with enough to know that...
I'm still trying to see Scala as "simplified and better Java"...and this is again one of those things you do every day, like defining and invoking methods...like iterating over a Range...
Paul Phillips-3 wrote:
On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
scala> def foo = new { def apply() = "hi mom" }
foo: java.lang.Object{def apply(): java.lang.String}
scala> foo()
res0: java.lang.String = hi mom
|
|
Re: def xx and def xx () not the same?
A method with no arguments is different than a method with one empty argument list (there can be more than one argument list, of course).
Mostly, I agree with you in this respect. It makes for more flexible DSLs, but it can be a pain to understand exactly what is going on.
On Fri, Nov 6, 2009 at 11:41 AM, Razvan Cojocaru <razvanc99@...> wrote:
This is wacky - possible but should be avoided....since it's not
strait-forward and hard to understand/debug...I'm actually inclined to
consider allowing that a bug...
I still don't see why def xxx is not the same as def xxx () - in fact you're
defining a function with no arguments, in both cases - is that not true?
Splitting hairs over the parens operator ... only confuses most people. I've
worked with enough to know that...
I'm still trying to see Scala as "simplified and better Java"...and this is
again one of those things you do every day, like defining and invoking
methods...like iterating over a Range...
Paul Phillips-3 wrote:
>
> On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
> scala> def foo = new { def apply() = "hi mom" }
> foo: java.lang.Object{def apply(): java.lang.String}
>
> scala> foo()
> res0: java.lang.String = hi mom
>
>
View this message in context: http://old.nabble.com/def-xx-and-def-xx-%28%29-not-the-same--tp26226554p26230521.html
Sent from the Scala - User mailing list archive at Nabble.com.
-- Daniel C. Sobral Veni, vidi, veterni.
|
|
Re: def xx and def xx () not the same?
Personally, I agree with you Razvan, but let me give a bit of reasoning first to illustrate why it might not be quite as clear-cut as it first seems: There is a mapping between argument lists of methods and functions. In particular,
method(Int)(String,Double):Byte
can be converted to
function: (Int) => ( (String,Double)=>Byte ) That is, each separate parameter list for a method will turn into a function that returns a function of the remaining parameter list(s).
Now, you can write a function like this:
func: () => ( ()=>Byte )
so that suggests that perhaps a method
meth()():Byte
is a sensible thing to do (and in fact Scala allows you to do this).
So, if we allow both of
g()
h()()
why not allow
f
as well (all are just hints to the compiler--I don't know how these
manage to get transmitted through a .class file--in that they are all
methods with no arguments as far as the JVM calls are concerned)?
Personally, I think that insisting that methods have at least *one*
parameter list would be sensible. The idea of
fA: => Int
doesn't seem to me to be usefully different from
fB:() => Int
since both are actually Function0[Int] (whereas fC:()=>()=>Int is Function0[Function0[Int]], which is distinct). Since there's no difference in functions, and no differences (aside from annoying syntactic inconsistencies) in methods, it's hard to see why there's a difference.
But, given this distinction, it's pretty obvious why in the former case
you can't call f() (because even though you're passing it nothing, it's
more nothing than it wants--the same reason why you can't call g()()). Scala helpfully inserts extra ()'s for
you so you don't have to type them, though, so f g h all are interpreted as method calls. (If they are functions, you have to actually call them.)
--Rex On Fri, Nov 6, 2009 at 8:41 AM, Razvan Cojocaru <razvanc99@...> wrote:
This is wacky - possible but should be avoided....since it's not
strait-forward and hard to understand/debug...I'm actually inclined to
consider allowing that a bug...
I still don't see why def xxx is not the same as def xxx () - in fact you're
defining a function with no arguments, in both cases - is that not true?
Splitting hairs over the parens operator ... only confuses most people. I've
worked with enough to know that...
I'm still trying to see Scala as "simplified and better Java"...and this is
again one of those things you do every day, like defining and invoking
methods...like iterating over a Range...
Paul Phillips-3 wrote:
>
> On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
> scala> def foo = new { def apply() = "hi mom" }
> foo: java.lang.Object{def apply(): java.lang.String}
>
> scala> foo()
> res0: java.lang.String = hi mom
>
>
View this message in context: http://old.nabble.com/def-xx-and-def-xx-%28%29-not-the-same--tp26226554p26230521.html
Sent from the Scala - User mailing list archive at Nabble.com.
|
|
Re: def xx and def xx () not the same?
On Thu, 05 Nov 2009 20:56:49 -0800, Razvan Cojocaru wrote:
> at some point in 2.8 it happened that
>
> def xx = 13
> and
> def xx () = 13
> are not the same anymore.
>
> I can't call the first with ()...i.e.
>
> class Test13 {
> def xx = 13
> xx () // compilation error: xx doesn't take parameters or smth like
> that
> }
>
> it's annoying...why this righteousness ?
It's part of a type compatiblity thing between vals and defs.
For example, you can't override a val with a def because code that uses
the superclass may expect the val to retain the same value on every call,
and a def doesn't provide that guarantee.
Similarly, the number of parentheses on a def is significant because the
compiler interprets any extra sets as apply() calls on the object
returned by the function call.
--Ken
--
Chanoch (Ken) Bloom. PhD candidate. Linguistic Cognition Laboratory.
Department of Computer Science. Illinois Institute of Technology.
http://www.iit.edu/~kbloom1/
|
|
AW: def xx and def xx () not the same?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
If there is a difference between def xx and def xx () how can
the numbers of arguments be counted on runtime?
Is it possible to define a count
function that counts the arguments like
def count(e: () => Any):Int=try{1+count(e())} finally { 0} // doesn’t
work
for this program:
def e=9;
def f()=9;
def g()()=9;
println(count(e)) // should give
0
println(count(f)) // should give
1
println(count(g)) // should give 2
Von: Rex Kerr
[mailto:ichoran@...]
Gesendet: Freitag, 6. November 2009 15:52
An: Razvan Cojocaru
Cc: scala-user@...
Betreff: Re: [scala-user] def xx and def xx () not the same?
Personally, I agree with you
Razvan, but let me give a bit of reasoning first to illustrate why it might not
be quite as clear-cut as it first seems:
There is a mapping between argument lists of methods and functions. In
particular,
method(Int)(String,Double):Byte
can be converted to
function: (Int) => ( (String,Double)=>Byte )
That is, each separate parameter list for a method will turn into a function
that returns a function of the remaining parameter list(s).
Now, you can write a function like this:
func: () => ( ()=>Byte )
so that suggests that perhaps a method
meth()():Byte
is a sensible thing to do (and in fact Scala allows you to do this).
So, if we allow both of
g()
h()()
why not allow
f
as well (all are just hints to the compiler--I don't know how these manage to
get transmitted through a .class file--in that they are all methods with no
arguments as far as the JVM calls are concerned)?
Personally, I think that insisting that methods have at least *one* parameter
list would be sensible. The idea of
fA: => Int
doesn't seem to me to be usefully different from
fB:() => Int
since both are actually Function0[Int] (whereas fC:()=>()=>Int is
Function0[Function0[Int]], which is distinct). Since there's no
difference in functions, and no differences (aside from annoying syntactic
inconsistencies) in methods, it's hard to see why there's a difference.
But, given this distinction, it's pretty obvious why in the former case you
can't call f() (because even though you're passing it nothing, it's more
nothing than it wants--the same reason why you can't call g()()). Scala
helpfully inserts extra ()'s for you so you don't have to type them, though, so
f
g
h
all are interpreted as method calls. (If they are functions, you have to
actually call them.)
--Rex
On Fri, Nov 6, 2009 at 8:41 AM, Razvan Cojocaru <razvanc99@...> wrote:
This is wacky - possible but should be avoided....since it's not
strait-forward and hard to understand/debug...I'm actually inclined to
consider allowing that a bug...
I still don't see why def xxx is not the same as def xxx () - in fact you're
defining a function with no arguments, in both cases - is that not true?
Splitting hairs over the parens operator ... only confuses most people. I've
worked with enough to know that...
I'm still trying to see Scala as "simplified and better
Java"...and this is
again one of those things you do every day, like defining and invoking
methods...like iterating over a Range...
Paul Phillips-3 wrote:
>
> On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
> scala> def foo = new {
def apply() = "hi mom" }
> foo: java.lang.Object{def apply(): java.lang.String}
>
> scala> foo()
> res0: java.lang.String = hi mom
>
>
View this message in context: http://old.nabble.com/def-xx-and-def-xx-%28%29-not-the-same--tp26226554p26230521.html
Sent from the Scala - User
mailing list archive at Nabble.com.
|
|
Re: def xx and def xx () not the same?
The run-time representation of Scala constructs is dependent on the underlying vm. In many, many cases, what is true for code to be compiled by the Scala compiler is not true for the compiled bytecode.
On Fri, Nov 6, 2009 at 1:14 PM, Kubitz, Jörg <jkubitz@...> wrote:
If there is a difference between def xx and def xx () how can the numbers of arguments be counted on runtime?
Is it possible to define a count function that counts the arguments like
def count(e: () => Any):Int=try{1+count(e())} finally { 0} // doesn’t work
for this program:
def e=9;
def f()=9;
def g()()=9;
println(count(e)) // should give 0
println(count(f)) // should give 1
println(count(g)) // should give 2
Von: Rex Kerr [mailto:ichoran@...]
Gesendet: Freitag, 6. November 2009 15:52
An: Razvan Cojocaru
Cc: scala-user@...
Betreff: Re: [scala-user] def xx and def xx () not the same?
Personally, I agree with you Razvan, but let me give a bit of reasoning first to illustrate why it might not be quite as clear-cut as it first seems:
There is a mapping between argument lists of methods and functions. In particular,
method(Int)(String,Double):Byte
can be converted to
function: (Int) => ( (String,Double)=>Byte )
That is, each separate parameter list for a method will turn into a function that returns a function of the remaining parameter list(s).
Now, you can write a function like this:
func: () => ( ()=>Byte )
so that suggests that perhaps a method
meth()():Byte
is a sensible thing to do (and in fact Scala allows you to do this).
So, if we allow both of
g()
h()()
why not allow
f
as well (all are just hints to the compiler--I don't know how these manage to get transmitted through a .class file--in that they are all methods with no arguments as far as the JVM calls are concerned)?
Personally, I think that insisting that methods have at least *one* parameter list would be sensible. The idea of
fA: => Int
doesn't seem to me to be usefully different from
fB:() => Int
since both are actually Function0[Int] (whereas fC:()=>()=>Int is Function0[Function0[Int]], which is distinct). Since there's no difference in functions, and no differences (aside from annoying syntactic inconsistencies) in methods, it's hard to see why there's a difference.
But, given this distinction, it's pretty obvious why in the former case you can't call f() (because even though you're passing it nothing, it's more nothing than it wants--the same reason why you can't call g()()). Scala helpfully inserts extra ()'s for you so you don't have to type them, though, so
f
g
h
all are interpreted as method calls. (If they are functions, you have to actually call them.)
--Rex
On Fri, Nov 6, 2009 at 8:41 AM, Razvan Cojocaru <razvanc99@...> wrote:
This is wacky - possible but should be avoided....since it's not
strait-forward and hard to understand/debug...I'm actually inclined to
consider allowing that a bug...
I still don't see why def xxx is not the same as def xxx () - in fact you're
defining a function with no arguments, in both cases - is that not true?
Splitting hairs over the parens operator ... only confuses most people. I've
worked with enough to know that...
I'm still trying to see Scala as "simplified and better Java"...and this is
again one of those things you do every day, like defining and invoking
methods...like iterating over a Range...
Paul Phillips-3 wrote:
>
> On Thu, Nov 05, 2009 at 10:16:33PM -0800, Razvan Cojocaru wrote:
> scala> def foo = new { def apply() = "hi mom" }
> foo: java.lang.Object{def apply(): java.lang.String}
>
> scala> foo()
> res0: java.lang.String = hi mom
>
>
View this message in context: http://old.nabble.com/def-xx-and-def-xx-%28%29-not-the-same--tp26226554p26230521.html
Sent from the Scala - User mailing list archive at Nabble.com.
-- Daniel C. Sobral Veni, vidi, veterni.
|
|
Re: AW: def xx and def xx () not the same?
On Friday November 6 2009, Kubitz, Jörg wrote:
> If there is a difference between def xx and def xx () how can the
> numbers of arguments be counted on runtime? Is it possible to define
> a count function that counts the arguments like
>
> def count(e: () => Any):Int=try{1+count(e())} finally { 0} //
> doesn't work
>
> for this program:
> def e=9;
> def f()=9;
> def g()()=9;
> println(count(e)) // should give 0
> println(count(f)) // should give 1
> println(count(g)) // should give 2
Are you interested in counting arguments or argument lists? If you have
repeated arguments, you can easily ascertain how many were given:
def nArgs(args: Any*): Int = args.length
scala> def nArgs(args: Any*): Int = args.length
nArgs: (Any*)Int
scala> nArgs()
res1: Int = 0
scala> nArgs(1)
res2: Int = 1
scala> nArgs("get", "me", "out", "of", "here", '!')
res3: Int = 6
If you're talking about number of argument lists, that's a static
property of the program. I don't know how you'd access it at runtime,
but I also don't know why you'd want to.
Randall Schulz
|
|
AW: AW: def xx and def xx () not the same?
No, I would count the order of the function.
Not a real applicaton problem. Just a theoretical question. If its not possible to get the order I don’t see a difference between def xx and def xx()
-----Ursprüngliche Nachricht-----
Von: Randall R Schulz [mailto: rschulz@...]
Gesendet: Freitag, 6. November 2009 16:25
An: scala-user@...
Betreff: Re: AW: [scala-user] def xx and def xx () not the same?
On Friday November 6 2009, Kubitz, Jörg wrote:
> If there is a difference between def xx and def xx () how can the
> numbers of arguments be counted on runtime? Is it possible to define
> a count function that counts the arguments like
>
> def count(e: () => Any):Int=try{1+count(e())} finally { 0} //
> doesn't work
>
> for this program:
> def e=9;
> def f()=9;
> def g()()=9;
> println(count(e)) // should give 0
> println(count(f)) // should give 1
> println(count(g)) // should give 2
Are you interested in counting arguments or argument lists? If you have
repeated arguments, you can easily ascertain how many were given:
def nArgs(args: Any*): Int = args.length
scala> def nArgs(args: Any*): Int = args.length
nArgs: (Any*)Int
scala> nArgs()
res1: Int = 0
scala> nArgs(1)
res2: Int = 1
scala> nArgs("get", "me", "out", "of", "here", '!')
res3: Int = 6
If you're talking about number of argument lists, that's a static
property of the program. I don't know how you'd access it at runtime,
but I also don't know why you'd want to.
Randall Schulz
|
|
RE: def xx and def xx () not the same?
> I'm still trying to see Scala as "simplified and better
> Java"...
I would consider this approach wrong.
Scala is not simplified Java. At least not in the sense
you seem to use this attribute.
When coming to Scala from Java, you are confronted with
a whole bunch of new/strange concepts which makes life
really complex, until you get them into your head.
After that, you start to think different about "simple".
Java is much simpler, and that is why writing progs in
in it often becomes such a complex task.
Scala has some complex rules and features, but applying them
makes things much simpler, once you are used to it.
So Scala is better.
Just my 2ct
Det
|
