- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Re: Tuples with naming parts
Thu, 2010-11-25, 17:16
On Thu, Nov 25, 2010 at 4:01 PM, Alexander Podkhalyuzin
wrote:
> So question is why Scala hasn’t type like: val t: (name: String, age: Int).
> And this type is equivalent to simple tuple type (String, Int), but you can
> use names to get tuple parts: t.name, t.age. But this is just syntactic
> sugar, compiler replace it with t._1, t._2. This would be great improvement
> of tuples.
If it's just local renaming you're after you can always import the
tuple's elements and simultaneously rename them,
scala> val t = ("foo", 23)
t: (java.lang.String, Int) = (foo,23)
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
scala> name
res8: java.lang.String = foo
scala> age
res9: Int = 23
Cheers,
Miles
Fri, 2010-11-26, 09:37
#2
Re: Tuples with naming parts
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
AANLkTik3TK_RapmsxdP2dtyyT-mnC0_tXVS-JpdOHYRQ [at] mail [dot] gmail [dot] com" type="cite">
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
Fri, 2010-11-26, 10:27
#3
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 10:47
#4
Re: Tuples with naming parts
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
R7xZHJ [at] mail [dot] gmail [dot] com" type="cite">
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" target="_blank" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 10:57
#5
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 11:07
#6
Re: Tuples with naming parts
Am 26.11.2010 10:49, schrieb √iktor Klang:
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
gSm9qj-+osvuKaHDZx-pvB_Py1-Rb_6ABjvmZ [at] mail [dot] gmail [dot] com" type="cite">the noname-class would only be generated once. in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
gSm9qj-+osvuKaHDZx-pvB_Py1-Rb_6ABjvmZ [at] mail [dot] gmail [dot] com" type="cite">
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" target="_blank" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 11:17
#7
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 11:27
#8
Re: Tuples with naming parts
Am 26.11.2010 11:09, schrieb √iktor Klang:
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
just like you would any other class.
BfFxNmkCxr61vQ1TVvUr_4j5LFPqGGxF3_v5t [at] mail [dot] gmail [dot] com" type="cite">when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
just like you would any other class.
BfFxNmkCxr61vQ1TVvUr_4j5LFPqGGxF3_v5t [at] mail [dot] gmail [dot] com" type="cite">in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" target="_blank" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 11:47
#9
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 11:57
#10
Re: Tuples with naming parts
"Then project C depends on both A and B: What happens if A produces
a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
Am 26.11.2010 11:27, schrieb √iktor Klang:
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
Am 26.11.2010 11:27, schrieb √iktor Klang:
AANLkTinsKE9p4ESHVFka_s+RvRnN-1tmSn_G_VHp-i0C [at] mail [dot] gmail [dot] com" type="cite">
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" target="_blank" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 12:07
#11
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 12:57
#12
Re: Tuples with naming parts
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
Am 26.11.2010 12:02, schrieb √iktor Klang:
k4yOJGbxuajycEv9Vq_ww7Y6cZDvNRaCYoZSy [at] mail [dot] gmail [dot] com" type="cite">
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" target="_blank" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 13:07
#13
Re: Tuples with naming parts
It's a type alias for a structural type, very handy at times.
On Nov 26, 2010 12:49 PM, "HamsterofDeath" <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
>
>
>
> On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
>>
>> "Then project...
Fri, 2010-11-26, 13:17
#14
Re: Tuples with naming parts
<AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-11-26, 13:17
#15
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 1:01 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
<AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
That'll only be a problem if you do extreme number crushing, for most uses it's not that bad :-)
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 13:27
#16
Re: Tuples with naming parts
*makes a note*
Am 26.11.2010 13:01, schrieb Kevin Wright:
Am 26.11.2010 13:01, schrieb Kevin Wright:
GPB0yssOGc2vrJoqN_HiSNMwOyRx-Z6wpepnp [at] mail [dot] gmail [dot] com" type="cite"> <AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
On 26 November 2010 11:49, HamsterofDeath <h-star [at] gmx [dot] de" rel="nofollow">h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star [at] gmx [dot] de" target="_blank" rel="nofollow">h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles [at] milessabin [dot] com" target="_blank" rel="nofollow">miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev [dot] lee [dot] wright [at] gmail [dot] com" target="_blank" rel="nofollow">kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-11-26, 13:27
#17
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 1:16 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
On 26 November 2010 12:13, √iktor Klang <viktor.klang@gmail.com> wrote:
On Fri, Nov 26, 2010 at 1:01 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
<AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
That'll only be a problem if you do extreme number crushing, for most uses it's not that bad :-)
It's more a warning against using them almost exclusively throughout an entire codebase...
The only thing you should use exclusively throughout an entire codebase is Akka Actors. ;-)
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 13:37
#18
Re: Tuples with naming parts
On 26 November 2010 12:13, √iktor Klang <viktor.klang@gmail.com> wrote:
On Fri, Nov 26, 2010 at 1:01 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
<AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
That'll only be a problem if you do extreme number crushing, for most uses it's not that bad :-)
It's more a warning against using them almost exclusively throughout an entire codebase...
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-11-26, 13:47
#19
Re: Tuples with naming parts
On 26 November 2010 12:24, √iktor Klang <viktor.klang@gmail.com> wrote:
On Fri, Nov 26, 2010 at 1:16 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
On 26 November 2010 12:13, √iktor Klang <viktor.klang@gmail.com> wrote:
On Fri, Nov 26, 2010 at 1:01 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
<AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
That'll only be a problem if you do extreme number crushing, for most uses it's not that bad :-)
It's more a warning against using them almost exclusively throughout an entire codebase...
The only thing you should use exclusively throughout an entire codebase is Akka Actors. ;-)
Oh yes... How *is* that world domination thing of yours coming along?
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
Fri, 2010-11-26, 13:57
#20
Re: Tuples with naming parts
On Fri, Nov 26, 2010 at 1:36 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
On 26 November 2010 12:24, √iktor Klang <viktor.klang@gmail.com> wrote:
On Fri, Nov 26, 2010 at 1:16 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
On 26 November 2010 12:13, √iktor Klang <viktor.klang@gmail.com> wrote:
On Fri, Nov 26, 2010 at 1:01 PM, Kevin Wright <kev.lee.wright@gmail.com> wrote:
<AlecGuinessVoice>Be careful young hamster...</AlecGuinessVoice>
Structural types use reflection to do their magic, so they can be a bit slow if you're not careful... Sadly not a panacea for all that ails you.
That'll only be a problem if you do extreme number crushing, for most uses it's not that bad :-)
It's more a warning against using them almost exclusively throughout an entire codebase...
The only thing you should use exclusively throughout an entire codebase is Akka Actors. ;-)
Oh yes... How *is* that world domination thing of yours coming along?
It's going super, thanks for asking! :-)
On 26 November 2010 11:49, HamsterofDeath <h-star@gmx.de> wrote:
scala can do such magic with types? omg! got to read more
Am 26.11.2010 12:02, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:55 AM, HamsterofDeath <h-star@gmx.de> wrote:
"Then project C depends on both A and B: What happens if A produces a noname that C passes to B?"
->
project a:
object x {
var something = ("hello"=>String, "world"=>string) // compiled to packageofx.anon_hello_world
}
project b:
object y {
var something = ("goodbye"=>String, "world"=>string) // compiled to packageofy.anon_goodbye_world
}
project c:
object z {
def tryToMessItUp {
x.something = y.something // would not compile since packageofx.anon_hello_world != packageofy.anon_goodbye_world
}
}
}
which is why i thought of traits. it would be easy for the compiler to generate a wrapper around y-something in the case above.
ducktyping also could be a solution. the given object just has to offer the same methods, not be of the same type.
So why not use case classes and structural types?
case class struct(name: String, age: Int
type Struct = { def name: String, def age: Int }
Voilá!
Am 26.11.2010 11:27, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 11:21 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 11:09, schrieb √iktor Klang:when the compiler looks at the code above, it must have somelib in the classpath, so it knows about all the nonamesugarclasses in there.
On Fri, Nov 26, 2010 at 11:02 AM, HamsterofDeath <h-star@gmx.de> wrote:
Am 26.11.2010 10:49, schrieb √iktor Klang:the noname-class would only be generated once.
On Fri, Nov 26, 2010 at 10:42 AM, HamsterofDeath <h-star@gmx.de> wrote:
good question. it would require type inferrence to work backwards:
val magic = ("string"=>getText, 1.0=>theNumberPlease)
somelib.call(magic) //<- the compiler has to work backwards from here to determine which nonameclass inside somelib would match by signature and declare magic to be of that type.
But you can't do that since if you generate the classes, they will be generated in both projects. will they have the same package? Or will they be generated with the package-declaration of the enclosing scope?
That can't be true since you have the same declaration in two separate projects, since they have no knowledge of eachother 2 classes would need to be generated.
And since there are 2 generated classes, what packages do they belong to?
if you'd decompile somelib.call you'd see something like
call(param1:thispackage.anon_getText_theNumberPlease) {
// ...
}
But project A and project B are not depending on eachother, and they indivisually declare noname(name: String, age: Int)
Then project C depends on both A and B: What happens if A produces a noname that C passes to B?
just like you would any other class.
in the case above, the compiler would check the parameter type of call, which could be something like anon_getText_theNumberPlease. since the not yet determined type*would* match to that and is used as a parameter, it would infer that magic should be declared as anon_getText_theNumberPlease and not be generated.
But if the 2 separate projects are compiled separately and then you place their jars on the same classpath, what happens?
you could also explicitly write
somelib.call(new anon_getText_theNumberPlease("t", 0.0))
if you wanted.
that still leaves some "what if the compiler cannot infer the type"-questions open which is why i prefer the trait-solution.
or the compiler could use traits for declaration and compile the actual implementation as it sees fit.
but i see no reason why this should not work at all, as long as there is no additional logic involved.
Am 26.11.2010 10:20, schrieb √iktor Klang:
On Fri, Nov 26, 2010 at 9:26 AM, HamsterofDeath <h-star@gmx.de> wrote:
basically, you want a shortcut to write
(case?) class noname(a:x, b:y,...)
as part of a val/var declaration
+1
Is noname-instances from one project interoperable with noname instances from another?
Am 26.11.2010 07:47, schrieb Naftoli Gugenheim:
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
scala> import t.{ _1 => name, _2 => age }
import t.{_1=>name, _2=>age}
Or
val (name, age) = t
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
--
Kevin Wright
mail / gtalk / msn : kev.lee.wright@gmail.com
pulse / skype: kev.lee.wright
twitter: @thecoda
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
Fri, 2010-11-26, 18:27
#21
Re: Tuples with naming parts
√iktor Klang <viktor.klang@gmail.com> wrote on 26/11/2010 12:38:33:
>> Oh yes... How *is* that world domination thing of yours coming along?
>
> It's going super, thanks for asking! :-)
Your Devoxx session was great btw. Thanks for that!
Kieron
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.
Fri, 2010-11-26, 18:37
#22
Re: Tuples with naming parts
2010/11/26 <Kieron.Wilkinson@paretopartners.com>
√iktor Klang <viktor.klang@gmail.com> wrote on 26/11/2010 12:38:33:
>> Oh yes... How *is* that world domination thing of yours coming along?
>
> It's going super, thanks for asking! :-)
Your Devoxx session was great btw. Thanks for that!
Thanks Kieron, I had a great audience and a lovely venue :-)
Kieron
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.
--
Viktor Klang,
Code Connoisseur
Work: Scalable Solutions
Code: github.com/viktorklang
Follow: twitter.com/viktorklang
Read: klangism.tumblr.com
On Thu, Nov 25, 2010 at 11:15 AM, Miles Sabin <miles@milessabin.com> wrote:
Or
val (name, age) = t