On 1 September 2010 20:24, Ricky Clarkson <[email protected]> wrote:
> > Scala's type system is richer than that embedded into the .NET IL spec, > so > > it's impossible to fully reify on the platform. > > It is possible to reify what is supported by IL and reify the rest via > Manifest or a similar solution. > > > Coming from the other direction, allowing Scala to consume reified type > > parameters from other languages on .NET, the plan is to expose this > > information via Manifests, though it isn't implemented yet. > > This direction is probably more important. > > >> Is there a solution to the mismatch between .NET's > >> PublicMethodNamesInCapitals and Scala's lowerCaseForAlmostEverything? > > > > Isn't this just a convention? > > Yes, as far as I know, but a) mixing case conventions in one program > is ugly b) Scala treats identifiers that begin with uppercase > differently in cases. Ok, scrap this question then. Specifically, anything beginning with an lowercase letter is treated as a placeholder name in pattern matching, anything beginning with an Uppercase letter is treated as an extractor. As a convention, this works well, because constants, objects and classes tend to start with uppercase letters, variables with lowercase. These conventions are pretty much inherited, unchanged, direct from Java. This convention can be overridden by wrapping any lowercase identifier in `backticks`, there's essentially no need for overriding in the other direction (binding an extracted value to a an uppercase-prefixed identifier) > >> Does Scala on .NET support .NET's properties without having to write > >> Get_X and Set_X > > > > By design, there's no separation between methods and properties in Scala; > so > > it definitely can't be automated. > > I don't see any reason though why properties couldn't be specified by an > > annotation, we already do that with @BeanProperty when compiling to Java > > bytecode :) > > I mean that it would be poor to have C# code: x.Y += a.B; translated > to Scala: x.Set_Y(x.Get_Y() + a.Get_B()); Even for single-character > names it's ugly; when you have real identifiers in there it's close to > obfuscation. Oh, that suggests a better approach! - I think I'll raise this one on the Scala lists :) Again, by convention, any method defined in Scala is a de facto property. It's considered VERY bad form for such a method to cause mutations, caching excepted. I see no reason why such a method shouldn't just be mapped to a property in .NET (with the corresponding setter, if present) There's only one possible catch, if properties and methods in .NET share the same namespace and this could cause a name clash (though I don't *think* it would). It should still be doable, but it'll add some extra complexity to IL generation, and might well make things very confusing where compatibility via IKVM is also involved... > >> On Wed, Sep 1, 2010 at 7:46 AM, Roland Tepp <[email protected]> wrote: > >> > Oh, I beg to differ. > >> > > >> > Using Scala (at least on the language level) does not necessarily mean > >> > you have to use JVM. > >> > > >> > In fact it is quite possible to write Scala source and compile it > >> > to .Net > >> > > >> > The only thing tying your Scala programs to JVM is your own use of > >> > Java libraries. > >> > > >> > On 31 aug, 14:40, Jan Goyvaerts <[email protected]> wrote: > >> >> I didn't say you need to be there. > >> >> > >> >> Wait until the day after to read about it - when they stopped > throwing > >> >> the > >> >> eggs and rotten tomato's. :-) > >> >> > >> >> Anyway, it's now owned by them and switching to Scala (or anything > else > >> >> JVM > >> >> related) won't change a thing. > >> > > >> > -- > >> > You received this message because you are subscribed to the Google > >> > Groups "The Java Posse" group. > >> > To post to this group, send email to [email protected]. > >> > To unsubscribe from this group, send email to > >> > [email protected]<javaposse%[email protected]> > . > >> > For more options, visit this group at > >> > http://groups.google.com/group/javaposse?hl=en. > >> > > >> > > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "The Java Posse" group. > >> To post to this group, send email to [email protected]. > >> To unsubscribe from this group, send email to > >> [email protected]<javaposse%[email protected]> > . > >> For more options, visit this group at > >> http://groups.google.com/group/javaposse?hl=en. > >> > > > > > > > > -- > > Kevin Wright > > > > mail/google talk: [email protected] > > wave: [email protected] > > pulse: kev.lee.wright > > skype: kev.lee.wright > > twitter: @thecoda > > > > -- > > You received this message because you are subscribed to the Google Groups > > "The Java Posse" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<javaposse%[email protected]> > . > > For more options, visit this group at > > http://groups.google.com/group/javaposse?hl=en. > > > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Kevin Wright mail/google talk: [email protected] wave: [email protected] pulse: kev.lee.wright skype: kev.lee.wright twitter: @thecoda -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
