- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Fixed val Members Produce Fields
Thu, 2009-03-19, 14:26
Hi,
I've been looking at the class definitions that result from my first cut
at a type system for a reimplementation of a large Java program I've
been working on for several years.
I'm very pleased with the expressiveness, the parsimony, the flexibility
of the type system, the ability to maximize sharing of state and all
that good stuff.
What I noticed that surprised me is that if I define a class with a
member such as this:
val arity: Int = 1
The generated class still creates an int field to hold this value even
though it is fixed, not only within an instance but across all
instances of this class. If I change the definition to:
def arity: Int = 1
then I get only the accessor function.
I had no trouble casting my entire class lattice to accommodate this,
even though there's a mix of fixed and instance-dependent values for
fields such as arity, but I am wondering why the compiler can't turn a
val declaration with a fixed value into a simple method? It seems that
replicating the value in a field for each instance is wasteful in these
cases.
Randall Schulz
Fri, 2009-03-20, 03:17
#2
Re: Fixed val Members Produce Fields
How do you know that each instance gets its own copy? Is it possible they're all pointing to the same copy?
Regards,
Russ
On Thu, Mar 19, 2009 at 6:14 PM, Randall R Schulz <rschulz@sonic.net> wrote:
--
http://RussP.us
Regards,
Russ
On Thu, Mar 19, 2009 at 6:14 PM, Randall R Schulz <rschulz@sonic.net> wrote:
On Thursday March 19 2009, Randall R Schulz wrote:
> Hi,
>
> ...
>
> What I noticed that surprised me is that if I define a class with a
> member such as this:
>
> val arity: Int = 1
>
> The generated class still creates an int field to hold this value
> even though it is fixed, not only within an instance but across all
> instances of this class. If I change the definition to:
>
> def arity: Int = 1
>
> then I get only the accessor function.
There's nothing to say about this? I still can't see why an immutable
value that is fixed for all instances requires a private instance field.
It seems entirely redundant. Can someone explain it to me?
Or is it something the compiler should not do?
Randall Schulz
--
http://RussP.us
Fri, 2009-03-20, 04:17
#3
Re: Fixed val Members Produce Fields
Randall R Schulz wrote:
> On Thursday March 19 2009, Randall R Schulz wrote:
>> Hi,
>>
>> ...
>>
>> What I noticed that surprised me is that if I define a class with a
>> member such as this:
>>
>> val arity: Int = 1
>>
>> The generated class still creates an int field to hold this value
>> even though it is fixed, not only within an instance but across all
>> instances of this class. If I change the definition to:
>>
>> def arity: Int = 1
>>
>> then I get only the accessor function.
>
>
> There's nothing to say about this? I still can't see why an immutable
> value that is fixed for all instances requires a private instance field.
> It seems entirely redundant. Can someone explain it to me?
> Or is it something the compiler should not do?
A derived class might
override val arity: Int = 2
You can avoid having a field per instance by moving it to a companion
object.
Alternately, you could write
private[this] val arity: Int = 1
and hope/request/implement a compiler feature to optimise the field away.
Fri, 2009-03-20, 04:37
#4
Re: Fixed val Members Produce Fields
On Thursday March 19 2009, Russ Paielli wrote:
> How do you know that each instance gets its own copy? Is it possible
> they're all pointing to the same copy?
They're int fields.
Randall Schulz
Fri, 2009-03-20, 04:47
#5
Re: Fixed val Members Produce Fields
On Thu, Mar 19, 2009 at 6:14 PM, Randall R Schulz <rschulz@sonic.net> wrote:
On Thursday March 19 2009, Randall R Schulz wrote:
> Hi,
>
> ...
>
> What I noticed that surprised me is that if I define a class with a
> member such as this:
>
> val arity: Int = 1
>
> The generated class still creates an int field to hold this value
> even though it is fixed, not only within an instance but across all
> instances of this class. If I change the definition to:
>
> def arity: Int = 1
>
> then I get only the accessor function.
There's nothing to say about this? I still can't see why an immutable
value that is fixed for all instances requires a private instance field.
It seems entirely redundant. Can someone explain it to me?
val y = (new Random).nextInt // not constantval y = (1 to 100000).filter(_ % 100 == 0).foldLeft(0)(_ + _) // expensive to compute
While the latter is precomputable, the former is not. But, without an effects system (something that allows the compiler to know that the latter example results in the same value every time), any computation must be run and cached at runtime rather than pre-computed at compile time. So, the only thing that's left is the static assignment of:
val y = 1
Perhaps the EPFL folks looked at that optimization and said, "we've got better things to do with our time than optimize a case where the result is so trivial that the developer could just write def y = 1."
Or is it something the compiler should not do?
Randall Schulz
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp
On Thursday March 19 2009, Randall R Schulz wrote:
> Hi,
>
> ...
>
> What I noticed that surprised me is that if I define a class with a
> member such as this:
>
> val arity: Int = 1
>
> The generated class still creates an int field to hold this value
> even though it is fixed, not only within an instance but across all
> instances of this class. If I change the definition to:
>
> def arity: Int = 1
>
> then I get only the accessor function.
There's nothing to say about this? I still can't see why an immutable
value that is fixed for all instances requires a private instance field.
It seems entirely redundant. Can someone explain it to me?
Or is it something the compiler should not do?
Randall Schulz