http://permalink.gmane.org/gmane.comp.lang.scala hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.lang.scala/26577 <pre>Hi, I have a problem in defining the right type parameters due to recursive type definitions? I want to define a trait for a wrapper that holds a value and contains several methods that again return a wrapper - here there is only a map() method. Now I want to define nesting wrappers like NestingWrapper and AnotherNestingWrapper that nest another wrapper. At the base of this nested wrapper stack there is a BaseWrapper that nests no other wrapper. My problem is now, how can I define the type parameters of trait wrapper such that I can better define each nested wrapper more exactly. For example in the main method I want to access the test() method of the nested wrapper but this is not possible since it is only a Wrapper and not a NestingWrapper. If I add an additional type parameter to the trait Wrapper then I get errors since there is always an unbound parameter or some kind of recursive definition. I simply want to define: AnotherNestingWrapper[A, NestingWrapper[A, BaseWrapper[A, BaseWrapper]]] and the BaseW</pre> Ka Ter 2012-05-17T21:07:18 http://permalink.gmane.org/gmane.comp.lang.scala/26576 <pre>Thanks, Sasha. All I would ask is that the section on " Scala code is faster, because JVM is faster. " be made a little bit clearer. I think I understand what you're saying re:Erlang and Java, but it took a moment. On Thu, May 17, 2012 at 9:16 AM, Sasha Kazachonak &lt;sasha&lt; at &gt;kazachonak.com&gt;wrote: </pre> Stan Campbell 2012-05-17T16:33:59 http://permalink.gmane.org/gmane.comp.lang.scala/26575 <pre>I compiled a very short Scala teaser http://www.kazachonak.com/2012/05/why-scala_09.html I give it to people, who are not motivated enough to visit full Scala presentation yet =) On 12 май, 19:46, Simon Ochsenreither &lt;simon.ochsenreit...&lt; at &gt;googlemail.com&gt; wrote: </pre> Sasha Kazachonak 2012-05-17T16:16:52 http://permalink.gmane.org/gmane.comp.lang.scala/26574 <pre>I'm "Random J Hacker", contactable at 555 - 555555, and also via my dedicated "expect to be spammed" email address. The file itself is totally legit, it also contains no new insights of any value whatsoever. On 17 May 2012 01:21, Olek Swirski &lt;olekswirski&lt; at &gt;gmail.com&gt; wrote: </pre> Kevin Wright 2012-05-17T10:21:52 http://permalink.gmane.org/gmane.comp.lang.scala/26573 <pre>Ok, I got it. Thank you. On 17/05/12 03:02, Stan Campbell wrote: </pre> Olek Swirski 2012-05-17T01:12:14 http://permalink.gmane.org/gmane.comp.lang.scala/26572 <pre>Simon posted it earlier to this list. On Wed, May 16, 2012 at 5:55 PM, Daniel Sobral &lt;dcsobral&lt; at &gt;gmail.com&gt; wrote: </pre> Stan Campbell 2012-05-17T01:02:14 http://permalink.gmane.org/gmane.comp.lang.scala/26571 <pre>Ah, but that's the thing: I left it at work. On Wed, May 16, 2012 at 9:46 PM, Olek Swirski &lt;olekswirski&lt; at &gt;gmail.com&gt; wrote: </pre> Daniel Sobral 2012-05-17T00:55:10 http://permalink.gmane.org/gmane.comp.lang.scala/26570 <pre>If it's not explicitly forbidden, please forward it via e-mail to me :) On 17/05/12 02:41, Daniel Sobral wrote: </pre> Olek Swirski 2012-05-17T00:46:33 http://permalink.gmane.org/gmane.comp.lang.scala/26569 <pre> Oh, damn, I knew I had forgotten something! :-) I downloaded it, and at least the first page appears legit. </pre> Daniel Sobral 2012-05-17T00:41:28 http://permalink.gmane.org/gmane.comp.lang.scala/26568 <pre>oh, it's not at mkto-o0074.com but at zeroturnaround.com so it's more promising. did someone actually read it ? :) On 17/05/12 02:21, Olek Swirski wrote: </pre> Olek Swirski 2012-05-17T00:36:35 http://permalink.gmane.org/gmane.comp.lang.scala/26567 <pre>Getting this document requires filling out quite much personal information too. Why would they need phone number? And domain name, it doesn't look trustworthy to me. On 17/05/12 02:16, Simon Ochsenreither wrote: </pre> Olek Swirski 2012-05-17T00:21:31 http://permalink.gmane.org/gmane.comp.lang.scala/26566 <pre>The eMail with the URL to the report creates this warning in Thunderbird: Thunderbird thinks this message is a scam. The links in the message may be trying to impersonate web pages you want to visit. Are you sure you want to visit mkto-o0074.com? </pre> Simon Ochsenreither 2012-05-17T00:16:26 http://permalink.gmane.org/gmane.comp.lang.scala/26565 <pre>Scala has established itself as the Java alternative on the JVM and is especially gaining ground with those who need a highly distributed environment or great messaging, but don’t want to use Erlang. </pre> Bogomil Shopov 2012-05-16T13:03:59 http://permalink.gmane.org/gmane.comp.lang.scala/26564 <pre>Maybe an Either5 is simpler in its usage (same as a Tuple5) and it return plain types: https://gist.github.com/2705479 // Exiting paste mode, now interpreting. import language.implicitConversions defined class Either5 defined class C1 defined class C2 defined class C3 defined class C4 defined class C5 defined module Either5 defined class Edge defined class RedEdge defined class RedBoldEdge defined class GreenEdge defined class BlueEdge defined class Vertex defined class RedVertex defined class RedBoldVertex defined class GreenVertex defined class BlueVertex defined class Test scala&gt; val test0 = (new Test(new Vertex)).test() test0: Product with Serializable with Either5[RedBoldEdge,RedEdge,GreenEdge,Blue Edge,Edge] = C5(Edge&lt; at &gt;1c1aa24) scala&gt; val test1 = (new Test(new Vertex)).test()._5.node.edge.node.edge test1: Edge = Edge&lt; at &gt;f14d8b scala&gt; val test2 = (new Test(new RedVertex)).test()._2.node.edge.node.edge test2: RedEdge = RedEdge&lt; at &gt;3ad246 scala&gt; val test3 = (new Test(new RedBoldVertex)).test()._1.node.edge.</pre> Dave 2012-05-15T22:06:03 http://permalink.gmane.org/gmane.comp.lang.scala/26563 <pre> trait SymbolDelegate[+T &gt;: Null &lt;: Symbol] { protected lazy val real = synchronized { load() } protected def load(): T } </pre> Jan Vanek 2012-05-15T15:57:10 http://permalink.gmane.org/gmane.comp.lang.scala/26562 <pre> Yes, that's what I meant with the "immutable (basically to the point where you jump from one class to another". I thought the complete pickling data from one class-file is translated into a tree of symbols. Each leaf which represents an indirection to another symbol from another class-file would be an instance of a "delegate" symbol. We need such "delegate" symbol trait only for symbols which can be indirect, which I think is ClassSymbol and ModuleSymbol, but it will never be a MethodSymbol. So, the difference is: instead of creating a real symbol, which however in fact is not complete at the moment, and can "complete" himself, so it needs to have this information about its completeness in its state, I would spent an instance of a delegate symbol. I remember I spoke about this with Eugene once, and he said we don't need delegate symbols (if I remember correctly). We spoke about it in relation to the ownership of symbols. In your current case it seems that the owner of the indirect symbol is in fact the cl</pre> Jan Vanek 2012-05-15T15:23:10 http://permalink.gmane.org/gmane.comp.lang.scala/26561 <pre> 2007-me apologizes, deprecate away </pre> Adriaan Moors 2012-05-15T13:30:28 http://permalink.gmane.org/gmane.comp.lang.scala/26560 <pre> It's not so easy, unfortunately. Even reading symbols from classfiles has to be done lazily, or you would read in the whole universe with each symbol by following indirect dependencies. So a symbol's definitions can be forced by any thread that demands them, and that's the mutation behavior we are talking about. The other part that synchronization needs to handle is safe publishing of symbol data that are completed. Cheers - Martin </pre> martin odersky 2012-05-15T00:48:09 http://permalink.gmane.org/gmane.comp.lang.scala/26559 <pre> I see that I can help the most by not making things any worse. Consider it done. </pre> Paul Phillips 2012-05-14T23:44:27 http://permalink.gmane.org/gmane.comp.lang.scala/26558 <pre> for help here. Just to be clear: I am working day and night on reflection for the last 3 weeks, after having spent a much larger amount of time last summer. It's a huge effort, in no part because it involves cleaning up the ball of mud the api and the corresponding parts of the compiler have turned into (Something like a 100 symbol creation methods, seriously!) I have called for help repeatedly. Much help was offered, but none was ever delivered. I am afraid that if you insist I stop and write the tests for correct synchronization behavior, the whole think will stop in its tracks and nothing will be done. So, I call one last time for a volunteer. It would really be appreciated! - Martin </pre> martin odersky 2012-05-14T22:59:57 http://permalink.gmane.org/gmane.comp.lang.scala/26557 <pre> I don't wish to propose any alternative because it isn't what I'm after. My point is that if we don't hold both code and design to a higher standard, we will continue to burden ourselves with non-solutions. A higher standard, and one evenly applied: would we accept contributed code for something as sensitive as this which came with no tests? </pre> Paul Phillips 2012-05-14T22:41:24 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lang.scala