Back to Questions
1.1k
views9
comments
this. and implicit class decls
f#

Why can I use this.varExplicit, but not this.varCtor or this.varLet, if indeed slots are being created for all of them:

type Foo ( varCtor : int ) =
[<DefaultValue>] val varExplicit : int
let varLet = 42
memeber this.AMethod =
let a = this.varExplicit // OK
let b = this.varLet // nope
let c = this.varCtor // nope

thanks

.

let-bound and constructor-bound values do not take 'this.' Just say 'varLet' and 'varCtor'.

And in general, avoid declaring 'val's in classes.

[link:msdn.microsoft.com]

[link:msdn.microsoft.com]

[link:msdn.microsoft.com]

By on 9/9/2009 1:07 PM ()

Deja vu: [link:cs.hubfs.net]

Thanks for a pointer to the updated docs - they seem more clear.

Ok, so:
> A let binding creates a private field or function

If this is a normal, first-class CLR instance var, then why woudn't this as an option work if the var is in scope? How can I see these private vars in Intellisense, then? And more importantly, w/o this visibility, how can I tell the difference between primary c'tor args that have been turned into private vars, vs. those that have just been (rightly) "compiled away" as purely c'tor arguments that are not referenced outside of the body of the c'tor and do therefore not need to be made instance vars? (I still think the docs do not cover this case.)

thanks

By on 9/9/2009 1:43 PM ()

> A let binding creates a private field or function

If this is a normal, first-class CLR instance var, then why woudn't this as an option work if the var is in scope?

There are subtle differences between let-bound names and object members. (e.g. members can be overloaded, let-bound names cannot). 'this.' is a member lookup, it cannot be used for let-bound names.

How can I see these private vars in Intellisense, then?

let-bound names in general do not work as nicely with intellisense, this is true. (You can hit the completion character on a blank line in a member function, and the let-bound instance variables will be in the list, but the list is very long - <i>all <i>the names in scope at the top level.) <quote>And more importantly, w/o <b>this</b> visibility, how can I tell the difference between primary c'tor args that have been turned into private vars, vs. those that have just been (rightly) "compiled away" as purely c'tor arguments that are not referenced outside of the body of the c'tor and do therefore not need to be made instance vars? (I still think the docs do not cover this case.) </quote> Why do you want to know the difference? (I think the semantic here will change from Beta1 to Beta2, but I forget the details.) This seems like a fragile thing to care about.

By on 9/9/2009 1:58 PM ()

>There are subtle differences between let-bound names and object members

When using the implcit/primary c'tor syntax and lets in the type, are we creating a .Net class or not?

The docs explicily say let bindings create "private fields or functions" - is a "field" something other than a CLR entity?

If it's a .Net class member var, I expect certain things, such as .this access when in scope, availability through reflection, etc.

If it's something that just looks like part of the class from F# side, that's fine, but not apparent from the docs.

>> vs. those that have just been (rightly) "compiled away"

> Why do you want to know the difference?

If I'm creating (hundreds of) thousands of objects, I certainly want to know what I'm allocating as part of an object and what are simply parameters to the c'tor - or if I'm mapping to an entity framework or serializing etc.

Sorry if I'm being dense here - seems pretty basic to me to want to know what's simply a variable and what takes a slot in the class.

F# is succinct and high-level, but so far is transparent and predictable - this seems like an exception.

If the answer "you can never tell", that's fine - just means we'll have to use only explicit val syntax if we care.

By on 9/9/2009 9:48 PM ()

It is a .Net class.

Aha, yes, the docs currently conflict with the spec; the spec currently says

[link:research.microsoft.com]

... The compiled representation used for let-bounds values in classes is implementation dependent. Non-function let bindings are generally represented as instance fields in the corresponding class. However there is no guarantee of this. ...

so I'll try to ensure the docs and spec sync up on this point for Beta2. (I forget if the spec is changing to have stronger guarantees or not.)

And yes, though I think a rarer case, if you're going to allocate a million of them in an array, or do something else that requires you to 'care about the storage', then yes, predictability matters, at which point you can switch to the explicit syntax if you need to exercise finer control.

By on 9/9/2009 11:16 PM ()

Thanks for the clarification and the effort.

I think it's important way before 1M objects -- especially now that the powers-that-be are going to force 64-bit machines on the desktop-side, causing the memory requirements of int's and ptr's to double. If MS is committing the the non-deteriminant status of let's-in-types, then it would be nice to have a simpler way of defining things we are sure we want to be class vars. For example:

var i : int // this is the same as "[<DefaultValue>] mutable i : int"

but I'm sure that's all water that's way under the bridge by now, and I'm sure the tradeoffs in the merging of OCaml and C# style were hard to make.

Anyway, I guess the interop focus is more on consuming CLR classes in F#, than it is creating them in F# and exposing them elsewhere.

thanks, m

By on 9/10/2009 12:01 PM ()

(Discussed with Don to get an update)

In the Beta1 release notes there is a section "Optimizations for Class and Struct representations" which suggests the thing I think you want, namely that for classes, 'only things that must be instance variables will be instance variables' (and constructor-locals will be compiled as such) (also that let-functions become private instance members). In Beta1 that was merely an implementation optimization, but our intention is to fold that into the actual language spec (require these strong guarantees).

So I think in Beta2 the language spec will give you more of what you want. (Well, except the "this." syntax for let-bound stuff - that's not going to change :) ).

By on 9/10/2009 11:32 PM ()

So it was an my RTFM problem all along? - that's never happened before :)

Looking forward to the new spec.

Gee, next thing you know you'll want me to read the EULA too...

By on 9/11/2009 8:40 AM ()

If you drop the ``this'' does it work?

I don't think either of the ``nope'' variables are bound to this instance.

By on 9/9/2009 1:05 PM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper