Nabble - Scala Programming Language

Re: Why does this compile?

2009-11-11T20:14:47Z

On Wed, Nov 11, 2009 at 9:56 PM, Brian Maso <brian@...> wrote:

Irregardless of how its implemented on the JVM, I wouldn't think you should be allowed to have these two method signatures in the same class. Clearly there would be an ambiguity -- what type should "f" be here? It can't be inferred.

val f = bar(5);

Is it ambiguous? Isn't a trailing underscore *required* for currying?

From forum: Scala - User

Re: Why does this compile?

2009-11-11T19:56:08Z

Irregardless of how its implemented on the JVM, I wouldn't think you should be allowed to have these two method signatures in the same class. Clearly there would be an ambiguity -- what type should "f" be here? It can't be inferred.

val f = bar(5);

I guess someone will have to dig in to the Scala lang spec to prove it is/is not allowed.

Best regards,
Brian Maso
(949) 395-8551
brian@...
twitter: @bmaso
skype: brian.maso
LinkedIn: http://www.linkedin.com/in/brianmaso

On Wed, Nov 11, 2009 at 6:17 PM, Rex Kerr <ichoran@...> wrote:

I suspect that it compiles because the second one merges the multiple parameter lists to

def bar(i:Int , f:Float)
which is a valid overloading of bar.

Unfortunately, the compiler is then confused because it likes to be able to convert this to
bar: (i:Int) => ( (f:Float)=>Unit )
by creating a class like so:
class F(i:Int) { def apply(f:Float) = bar(i,f) }
i.e. by converting the parameter lists to separate function applications.

But now it's faced with two valid interpretations of bar(i:Int), which is what you see when you write the code, and which is what might make you think that it shouldn't compile.

(On the .class file side, though, I'd think that

def bar(i:Int) (f:Float) = println(i*f)
def bar(i:Int,f:Float) = println(i+f)
would be the one that conflicts, however; how does Scala keep this straight?)

--Rex

On Wed, Nov 11, 2009 at 8:04 PM, Nils Kilden-Pedersen <nilskp@...> wrote:

Someone please explain to my feeble mind why this compiles:

object Foo {
def bar(i: Int) = println(i)
def bar(i: Int) (f: Float) = println(i*f)
}

From forum: Scala - User

Re: Why does this compile?

2009-11-11T19:43:33Z

On Wed, Nov 11, 2009 at 7:36 PM, Dean Wampler <deanwampler@...> wrote:

Looks like a bug to me, as there appears to be no way to reference the second definition without an "ambiguous reference" error.

Actually neither can be referenced, at least on 2.8 trunk.

From forum: Scala - User

Re: Why does this compile?

2009-11-11T18:17:47Z

I suspect that it compiles because the second one merges the multiple parameter lists to
def bar(i:Int , f:Float)
which is a valid overloading of bar.

Unfortunately, the compiler is then confused because it likes to be able to convert this to
bar: (i:Int) => ( (f:Float)=>Unit )
by creating a class like so:
class F(i:Int) { def apply(f:Float) = bar(i,f) }
i.e. by converting the parameter lists to separate function applications.

But now it's faced with two valid interpretations of bar(i:Int), which is what you see when you write the code, and which is what might make you think that it shouldn't compile.

(On the .class file side, though, I'd think that
def bar(i:Int) (f:Float) = println(i*f)
def bar(i:Int,f:Float) = println(i+f)
would be the one that conflicts, however; how does Scala keep this straight?)

--Rex

On Wed, Nov 11, 2009 at 8:04 PM, Nils Kilden-Pedersen <nilskp@...> wrote:

Someone please explain to my feeble mind why this compiles:

object Foo {
def bar(i: Int) = println(i)
def bar(i: Int) (f: Float) = println(i*f)
}

From forum: Scala - User

Re: XmlResponse with cookies

2009-11-11T18:01:10Z

Hi,

On Wed, Nov 11, 2009 at 7:30 PM, Timothy Perrett
<timothy@...> wrote:
>
> Wouldn't a more appropriate idiom be to use overloaded apply methods in a companion object?
>
> That is:
>
> def apply(node: NodeSeq): XmlResponse
> def apply(node: NodeSeq, cookies: List[HTTPCookie]): XmlResponse
>
> Thoughts?

As for further enhancements, I prefer named and default arguments to
several apply methods. For example,

case class XmlResponse(xml: Node,
docType:Box[String] = Empty,
code:Int = 200,
cookies:List[HTTPCookie] = Nil)
extends NodeResponse {
def headers = List("Content-Type" -> "text/xml; charset=utf-8"
def out = xml
}

and we will have
XmlResponse(<foo />, cookies = S.responseCookies)

Of course, it must wait for Liftweb 1.1 release.

Sincerely,
--
Atsuhiko Yamanaka
JCraft,Inc.
1-14-20 HONCHO AOBA-KU,
SENDAI, MIYAGI 980-0014 Japan.
Tel +81-22-723-2150
+1-415-578-3454
Skype callto://jcraft/
Twitter: http://twitter.com/ymnk

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: Why does this compile?

2009-11-11T17:36:36Z

Looks like a bug to me, as there appears to be no way to reference the second definition without an "ambiguous reference" error.

On Wed, Nov 11, 2009 at 7:04 PM, Nils Kilden-Pedersen <nilskp@...> wrote:

Someone please explain to my feeble mind why this compiles:

object Foo {
def bar(i: Int) = println(i)
def bar(i: Int) (f: Float) = println(i*f)
}

--
Dean Wampler
coauthor of "Programming Scala" (O'Reilly)
- http://programmingscala.com

twitter: @deanwampler, @chicagoscala
blog: http://blog.polyglotprogramming.com
Chicago-Area Scala Enthusiasts (CASE):
- http://groups.google.com/group/chicagoscala
- http://www.meetup.com/chicagoscala/ (Meetings)
http://www.linkedin.com/in/deanwampler
http://www.polyglotprogramming.com
http://aquarium.rubyforge.org
http://www.contract4j.org

From forum: Scala - User

Why does this compile?

2009-11-11T17:04:52Z

Someone please explain to my feeble mind why this compiles:

object Foo {
def bar(i: Int) = println(i)
def bar(i: Int) (f: Float) = println(i*f)
}

From forum: Scala - User

Re: How to use Box

2009-11-11T16:28:32Z

What do you want to happen if you call "value" on an Empty?

-------------------------------------
Ferdinand Chan<uniquefer@...> wrote:

Wondering what's the normal practice of using a Box. As a Java
developer, I always want to get the boxed value by a method named
"Value" like

val optionalContent = Full("This is optional")

Log.info( " The optional content is " + optionalContent.value)

But I know its not a valid way to do so in lift ( same for Option in
Scala)

From the book programming in Scala , there's an example

val withDefault: Option[Int] => Int = {
case Some(x) => x
case None => 0
}

which suggest the use of match to retrieve the value of the boxed
content. It make sense to me and I'm totally agree with the advantage
of using match + option (Box) combination.

However, as a newbie to Scala, I'm so tempted to use something
like .Value to retrieve the box value .

So, what's the normal way to use Box ?? Could someone kindly provide
some example on how to use ? I tried to look through some source code
of Lift but its not easy for a newbie :)

Thanks

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: 503 for url: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd

2009-11-11T16:07:48Z

Sorry for what may seem like a stupid question, but I am very new to
scala/lift.

PCDataXmlParser solved my issue with w3 dtd but I am now getting a
parse error when I get a http stream.

:96:5: '<' not allowed in attrib valuegoogle_ad_type =
"text_image"; ^
Exception in thread "main" java.lang.ExceptionInInitializerError
at ca.ctrlspace.loveItHateItWeb.xml.UpcDatabaseFeed.main
(UpcDatabaseFeed.scala)
Caused by: java.lang.IllegalArgumentException: line 97 does not exist
at scala.io.Source.getLine(Source.scala:280)
at scala.io.Source.report(Source.scala:368)
at scala.io.Source.reportError(Source.scala:355)
at scala.io.Source.reportError(Source.scala:344)
at scala.xml.parsing.MarkupParser$class.reportSyntaxError
(MarkupParser.scala:1113)
at net.liftweb.util.PCDataXmlParser.reportSyntaxError
(PCDataMarkupParser.scala:91)

it looks like the following is causing this:

<script type="text/javascript"></script>

Is it possible to ask PCDataXmlParser not to grab certain xml
elements?
What is the proper way to use PCDataXmlParser?

As an aside why does PCDataXmlParser not give the w3 dtd exception?

Thanks,

Chris.

On Nov 9, 11:33 pm, David Pollak <feeder.of.the.be...@...>
wrote:

> It's not an issue of Lift's output working with XML.load, it's an issue of
> the W3C blocking the Java libraries. This has nothing to do with Lift or
> the XML Lift emits.
>
> If you want to parse XML and not run into that problem, use
> net.liftweb.util.PCDataXmlParser
>
>
>
>
>
> On Mon, Nov 9, 2009 at 7:11 PM, Alex Black <a...@...> wrote:
>
> > I read these two:
>
> >http://old.nabble.com/Exception-loading-XML-with-DTD-td25213294.html
>
> >http://stackoverflow.com/questions/1096285/is-scala-java-not-respecti...
>
> > Not sure what the answer is, some ugly work arounds are presented...
>
> > Presumably Lift's XML output *should* work with XML.Load?
>
> > - Alex
>
> > On Nov 9, 10:01 pm, Naftoli Gugenheim <naftoli...@...> wrote:
> > > Don't know but it's been asked so you should be able to search for it;
> > I'm not sure whether on this list or scala-user or both.
>
> > > -------------------------------------
>
> > > Alex Black<a...@...> wrote:
>
> > > Exception:
>
> > > java.io.IOException: Server returned HTTP response code: 503 for URL:
> >http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
> > > at sun.net.www.protocol.http.HttpURLConnection.getInputStream
> > > (HttpURLConnection.java:1313)
> > > at
>
> > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity
> > > (XMLEntityManager.java:677)
> > > at
> > > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity
> > > (XMLEntityManager.java:1315)
> > > at
> > > com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity
> > > (XMLEntityManager.java:1282)
> > > at
> > > com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource
> > > (XMLDTDScannerImpl.java:283)
> > > at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl
> > > $DTDDriver.dispatch(XMLDocumentScannerImpl.java:1193)
> > > at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl
> > > $DTDDriver.next(XMLDocumentScannerImpl.java:1090)
> > > at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl
> > > $PrologDriver.next(XMLDocumentScannerImpl.java:1003)
> > > at
> > com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next
> > > (XMLDocumentScannerImpl.java:648)
> > > at
>
> > com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scan Document
> > > (XMLDocumentFragmentScannerImpl.java:510)
> > > at
> > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> > > (XML11Configuration.java:807)
> > > at
> > com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse
> > > (XML11Configuration.java:737)
> > > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse
> > > (XMLParser.java:107)
> > > at
> > com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse
> > > (AbstractSAXParser.java:1205)
> > > at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl
> > > $JAXPSAXParser.parse(SAXParserImpl.java:522)
> > > at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
> > > at
> > scala.xml.parsing.FactoryAdapter.loadXML(FactoryAdapter.scala:292)
> > > at scala.xml.parsing.NoBindingFactoryAdapter.loadXML
> > > (NoBindingFactoryAdapter.scala:60)
> > > at scala.xml.XML$.load(XML.scala:72)
> > > at
> > com.snapsort.dataServer.api.ServerTest$$anonfun$testBasic$1.apply
> > > (ServerTest.scala:16)
> > > at
> > com.snapsort.dataServer.api.ServerTest$$anonfun$testBasic$1.apply
> > > (ServerTest.scala:14)
> > > at com.snapsort.common.Using$.apply(Using.scala:12)
> > > at
> > com.snapsort.dataServer.api.ServerTest.testBasic(ServerTest.scala:
> > > 14)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > at sun.reflect.NativeMethodAccessorImpl.invoke
> > > (NativeMethodAccessorImpl.java:39)
> > > at sun.reflect.DelegatingMethodAccessorImpl.invoke
> > > (DelegatingMethodAccessorImpl.java:25)
> > > at java.lang.reflect.Method.invoke(Method.java:597)
> > > at junit.framework.TestCase.runTest(TestCase.java:168)
> > > at junit.framework.TestCase.runBare(TestCase.java:134)
> > > at junit.framework.TestResult$1.protect(TestResult.java:110)
> > > at junit.framework.TestResult.runProtected(TestResult.java:128)
> > > at junit.framework.TestResult.run(TestResult.java:113)
> > > at junit.framework.TestCase.run(TestCase.java:124)
> > > at junit.framework.TestSuite.runTest(TestSuite.java:232)
> > > at junit.framework.TestSuite.run(TestSuite.java:227)
> > > at org.junit.internal.runners.JUnit38ClassRunner.run
> > > (JUnit38ClassRunner.java:83)
> > > at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run
> > > (JUnit4TestReference.java:46)
> > > at org.eclipse.jdt.internal.junit.runner.TestExecution.run
> > > (TestExecution.java:38)
> > > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
> > > (RemoteTestRunner.java:467)
> > > at
> > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
> > > (RemoteTestRunner.java:683)
> > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
> > > (RemoteTestRunner.java:390)
> > > at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
> > > (RemoteTestRunner.java:197)
>
> > > On Nov 9, 9:43 pm, Alex Black <a...@...> wrote:
>
> > > > Hi, I'm attempting to write a basic unit test for a webservice I'm
> > > > implementing in Lift, by test looks like this:
>
> > > > val foo = XML.load("http://localhost:8080")
>
> > > > I'm getting an exception I assume because the XML parser is trying to
> > > > download the DTD and is getting denied. Whats the best way to work
> > > > around this?
>
> > > > - Alex
>
> --
> Lift, the simply functional web frameworkhttp://liftweb.net
> Beginning Scalahttp://www.apress.com/book/view/1430219890
> Follow me:http://twitter.com/dpp
> Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

ReviewBoard upgrade

2009-11-11T16:06:09Z

I'll be working in the morning (US Mountain time) on upgrading ReviewBoard, just in case anyone notices any hiccups.

Derek

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: New Milestone coming soon

2009-11-11T15:40:24Z

OracleDriver doesn't work with CRUDify when attempting to view a
list of entries, it gets an SQL error due to use of LIMIT/OFFSET,
which Oracle does not support. Defining brokenLimit_? = true
in OracleDriver makes it work for me. I can do this myself by including
my own copy of Driver.scala, so I don't know if it counts as critical,
but it seems like a pretty localized (and thus low-risk) change.

--
Jim

On Wed, Nov 11, 2009 at 11:54:46AM -0800, David Pollak wrote:

> Date: Wed, 11 Nov 2009 11:54:46 -0800
> From: David Pollak <feeder.of.the.bears@...>
> To: liftweb <liftweb@...>
> Subject: [Lift] New Milestone coming soon
>
> Folks,
>
> There are two critical issues with M7:
>
> * Issue 164Â http://github.com/dpp/liftweb/issues#issue/164
> Â JSON/Ajax messages do not carry Notices back to the client.
> * The Session manager is not initialized properly. Â Basically, this
> means that sessions will be expired by the web container, but not
> by Lift and GUIDs that map to functions on the server side are not
> removed until the session is terminated.
>
> We're planning to do an M7.1 release later this week (probably Friday).
> If there are other *critical* defects (stuff that means you can't use
> M7 in production), please speak now.
> Thanks,
> David
> --
> Lift, the simply functional web framework http://liftweb.net
> Beginning Scala http://www.apress.com/book/view/1430219890
> Follow me: http://twitter.com/dpp
> Surf the harmonics
>
>

From forum: liftweb

Re: ScalaTest in Lift archetypes

2009-11-11T15:33:27Z

Bill, can I propose you and I get together at devoxx and discuss the
options?

I belive my talk is not long after yours!

Cheers, Tim

Sent from my iPhone

On 11 Nov 2009, at 21:50, Bill Venners <bill@...> wrote:

>
> Hi,
>
> I was talking with David Pollak the other night about putting some
> ScalaTest examples into the Lift archetypes. He said I should post to
> the list. Can anyone out there let me know how we might go about that?
>
> Thanks.
>
> Bill
> ----
> Bill Venners
> Artima, Inc.
> http://www.artima.com
>
> >
>

From forum: liftweb

Re: [scala-tools] VisualVM and Scala

2009-11-11T15:26:51Z

On 11/11/2009, at 8:35 PM, Iulian Dragos wrote:

On Wed, Nov 11, 2009 at 5:38 AM, Tony Sloane <inkytonik@...> wrote:

Profiler Agent Error: with message: Redefinition failed with error 69
Check JVMTI documentation for this error code.

The JVMTI documentation (http://java.sun.com/j2se/1.5.0/docs/guide/jvmti/jvmti.html#ErrorSection)
says that this error means

JVMTI_ERROR_NAMES_DONT_MATCH (69)
The class name defined in the new class file is different from the name in the old class object.

Probably Scala bytecode does not follow some Java naming convention, but otherwise the error message is quite useless. Have you noticed some pattern on those class names? Are they anonymous functions or top-level objects?

They appear to be anonymous functions. At least the list printed out seems to include only those. Yet, when I pick one, then look at the original class file and the one written by the profiler agent, they seem to be the same, or at least use the same names. I've run out of time to pursue this at the moment, but later on I may be able to get back to it and see if I can get further.

Each occurrence of this error (and there are many) pops up a dialog box that has to be dismissed manually. Even if the error can be ignored without affecting the profiling results, it's not practical to dismiss it this way, so I'd like to remove the error if possible.

I would file a bug report on VisualVM, it seems like this is not an error the user should be bothered with, especially since things go well from there on.

Well, it's not entirely clear that things do go well. Profiling data is produced, but given the errors, who knows exactly which classes are being run.

Any recommendations for Scala profiling tools?

I, and a few others in the Scala team, use YourKit. It's free for open-source projects, and works pretty well.

Thanks, I will take a look at YourKit.

cheers,

Tony

From forum: Scala - Tools

Re: [scala] Proposed Style Guide

2009-11-11T15:20:42Z

"The Scala language encourages a startling amount of nested scopes and
logical blocks (function values and such)."

I think this is false. If it happens to be true, you're not "doing it
properly."

It depends. Based on my experience, Scala tends to have a lot more nested scopes than either object-oriented languages or functional languages. I suspect the reason for this is unlike a purely-functional language, Scala functions may consist of numerous statements and expressions; and unlike an object-oriented language, Scala encourages anonymous functions, pattern matching and "blocks as expressions", all of which tend to push up the number of scopes. That's not really "doing it wrong" where Scala is concerned, it's just using the language in a way which would be wrong in Java or Haskell.

Daniel

From forum: Scala

Re: [scala] Proposed Style Guide

2009-11-11T15:17:10Z

"The Scala language encourages a startling amount of nested scopes and
logical blocks (function values and such)."

I think this is false. If it happens to be true, you're not "doing it
properly."

Daniel Spiewak wrote:

> One of the things about Scala which has always bugged me is the /lack/
> of an official style guide. There is simply no "right" way of doing
> things, syntactically speaking. Over the years, the Scala community
> has attempted to fill the void (as it were) by defining a set of
> unofficial, word-of-mouth conventions. Things like when to add
> parentheses to no-arg methods or what the preferred function literal
> definition style may be.
>
> This works fine for experienced Scala community members, but newcomers
> to the language are understandably baffled. This also causes a great
> deal of frustration on larger Scala projects with less-experienced
> Scala developers as some code will be stylized in one way, while other
> code will use a different convention.
>
> A few months ago, I decided that I had run into this problem one too
> many times, and so I took the time (with the generous support of my
> employer) to create a full (-ish) style guide for Scala syntax, naming
> conventions and project management. The guidelines it contains are
> based on what I have heard from the community and do not necessarily
> reflect my own preferences (e.g. function types). When in doubt about
> a particular convention, I have alternately looked at Martin Odersky's
> code or simply relied on my own knowledge of Java, C#, Standard ML and
> Haskell conventions. Comments and criticisms are very welcome.
>
> I would like to submit this guide for adoption by the larger Scala
> community. I know that sounds like I'm trying to foist my opinions on
> everyone else, but I'm really just hoping to get the ball rolling.
> Ideally, this guide should be used as a starting point from which a
> proper, officially-blessed and better-typeset guide can be fashioned.
> Until that happens, I'm more than happy to host the guide at Code
> Commit, incorporating any revisions the community as a whole deems
> necessary.
>
> The source for the guide is in reStructuredText, which is easily
> convertible to distributable formats like HTML, LaTeX, TWiki markup
> and more. For convenience, I have compiled the guide to a PDF (using
> rst2newlatex and pdflatex) and uploaded it along with the source. The
> document does not include a license declaration, but you can pretty
> much consider the material to be Public Domain.
>
> Enjoy!
>
> Daniel
>
> * http://www.codecommit.com/scala-style-guide.txt
> * http://www.codecommit.com/scala-style-guide.pdf
>

--
Tony Morris
http://tmorris.net/

From forum: Scala

Re: [scala] Proposed Style Guide

2009-11-11T15:14:31Z

The package naming conventions section will no longer be quite right
after 2.8, correct? In that one will no longer need to use __root__ so
much in imports - a package declaration will not include each level in
the hierarchy in scope for imports, correct?

Kris

On Wed, Nov 11, 2009 at 4:02 PM, Daniel Spiewak <djspiewak@...> wrote:

> One of the things about Scala which has always bugged me is the lack of an
> official style guide. There is simply no "right" way of doing things,
> syntactically speaking. Over the years, the Scala community has attempted
> to fill the void (as it were) by defining a set of unofficial, word-of-mouth
> conventions. Things like when to add parentheses to no-arg methods or what
> the preferred function literal definition style may be.
>
> This works fine for experienced Scala community members, but newcomers to
> the language are understandably baffled. This also causes a great deal of
> frustration on larger Scala projects with less-experienced Scala developers
> as some code will be stylized in one way, while other code will use a
> different convention.
>
> A few months ago, I decided that I had run into this problem one too many
> times, and so I took the time (with the generous support of my employer) to
> create a full (-ish) style guide for Scala syntax, naming conventions and
> project management. The guidelines it contains are based on what I have
> heard from the community and do not necessarily reflect my own preferences
> (e.g. function types). When in doubt about a particular convention, I have
> alternately looked at Martin Odersky's code or simply relied on my own
> knowledge of Java, C#, Standard ML and Haskell conventions. Comments and
> criticisms are very welcome.
>
> I would like to submit this guide for adoption by the larger Scala
> community. I know that sounds like I'm trying to foist my opinions on
> everyone else, but I'm really just hoping to get the ball rolling. Ideally,
> this guide should be used as a starting point from which a proper,
> officially-blessed and better-typeset guide can be fashioned. Until that
> happens, I'm more than happy to host the guide at Code Commit, incorporating
> any revisions the community as a whole deems necessary.
>
> The source for the guide is in reStructuredText, which is easily convertible
> to distributable formats like HTML, LaTeX, TWiki markup and more. For
> convenience, I have compiled the guide to a PDF (using rst2newlatex and
> pdflatex) and uploaded it along with the source. The document does not
> include a license declaration, but you can pretty much consider the material
> to be Public Domain.
>
> Enjoy!
>
> Daniel
>
> http://www.codecommit.com/scala-style-guide.txt
> http://www.codecommit.com/scala-style-guide.pdf

From forum: Scala

[scala] Proposed Style Guide

2009-11-11T15:02:57Z

One of the things about Scala which has always bugged me is the lack of an official style guide. There is simply no "right" way of doing things, syntactically speaking. Over the years, the Scala community has attempted to fill the void (as it were) by defining a set of unofficial, word-of-mouth conventions. Things like when to add parentheses to no-arg methods or what the preferred function literal definition style may be.

This works fine for experienced Scala community members, but newcomers to the language are understandably baffled. This also causes a great deal of frustration on larger Scala projects with less-experienced Scala developers as some code will be stylized in one way, while other code will use a different convention.

A few months ago, I decided that I had run into this problem one too many times, and so I took the time (with the generous support of my employer) to create a full (-ish) style guide for Scala syntax, naming conventions and project management. The guidelines it contains are based on what I have heard from the community and do not necessarily reflect my own preferences (e.g. function types). When in doubt about a particular convention, I have alternately looked at Martin Odersky's code or simply relied on my own knowledge of Java, C#, Standard ML and Haskell conventions. Comments and criticisms are very welcome.

I would like to submit this guide for adoption by the larger Scala community. I know that sounds like I'm trying to foist my opinions on everyone else, but I'm really just hoping to get the ball rolling. Ideally, this guide should be used as a starting point from which a proper, officially-blessed and better-typeset guide can be fashioned. Until that happens, I'm more than happy to host the guide at Code Commit, incorporating any revisions the community as a whole deems necessary.

The source for the guide is in reStructuredText, which is easily convertible to distributable formats like HTML, LaTeX, TWiki markup and more. For convenience, I have compiled the guide to a PDF (using rst2newlatex and pdflatex) and uploaded it along with the source. The document does not include a license declaration, but you can pretty much consider the material to be Public Domain.

Enjoy!

Daniel

From forum: Scala

Re: How to use Box

2009-11-11T14:55:59Z

http://blog.lostlake.org/index.php?/archives/50-The-Scala-Option-class-and-how-lift-uses-it.html

The for comprehension is your friend.

On Wed, Nov 11, 2009 at 2:40 PM, Ferdinand Chan <uniquefer@...> wrote:

Wondering what's the normal practice of using a Box. As a Java
developer, I always want to get the boxed value by a method named
"Value" like

val optionalContent = Full("This is optional")

Log.info( " The optional content is " + optionalContent.value)

But I know its not a valid way to do so in lift ( same for Option in
Scala)

From the book programming in Scala , there's an example

val withDefault: Option[Int] => Int = {
case Some(x) => x
case None => 0
}

which suggest the use of match to retrieve the value of the boxed
content. It make sense to me and I'm totally agree with the advantage
of using match + option (Box) combination.

However, as a newbie to Scala, I'm so tempted to use something
like .Value to retrieve the box value .

So, what's the normal way to use Box ?? Could someone kindly provide
some example on how to use ? I tried to look through some source code
of Lift but its not easy for a newbie :)

Thanks

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

How to use Box

2009-11-11T14:40:28Z

Wondering what's the normal practice of using a Box. As a Java
developer, I always want to get the boxed value by a method named
"Value" like

val optionalContent = Full("This is optional")

Log.info( " The optional content is " + optionalContent.value)

But I know its not a valid way to do so in lift ( same for Option in
Scala)

From the book programming in Scala , there's an example

val withDefault: Option[Int] => Int = {
case Some(x) => x
case None => 0
}

which suggest the use of match to retrieve the value of the boxed
content. It make sense to me and I'm totally agree with the advantage
of using match + option (Box) combination.

However, as a newbie to Scala, I'm so tempted to use something
like .Value to retrieve the box value .

So, what's the normal way to use Box ?? Could someone kindly provide
some example on how to use ? I tried to look through some source code
of Lift but its not easy for a newbie :)

Thanks
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

ScalaTest in Lift archetypes

2009-11-11T13:50:23Z

Hi,

I was talking with David Pollak the other night about putting some
ScalaTest examples into the Lift archetypes. He said I should post to
the list. Can anyone out there let me know how we might go about that?

Thanks.

Bill
----
Bill Venners
Artima, Inc.
http://www.artima.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: form input tag name values changed when moving from M6 to M7

2009-11-11T12:40:47Z

Thanks for the reply David. Below is some code which might suit both
our requirements ...

def locateFirstUserStackElement(stack: Array[StackTraceElement]) :
StackTraceElement = {
stack.foreach(element => {
if (!element.toString.startsWith("net.liftweb")) return
element
})
stack(0)
}

def formFuncName: String = if (Props.testMode) {
val bump: Long = ((_formGroup.is openOr 0) + 1000L) * 10000L
val num: Int = formItemNumber.is
formItemNumber.set(num + 1)
import _root_.java.text._
val prefix: String = new DecimalFormat("00000000000000000").format
(bump + num)
//M7 - "f" + prefix + "_" + Helpers.hashHex((new
Exception).getStackTrace.toList.take(10).map(_.toString).mkString
(",")))
"f" + prefix + "_" +Helpers.hashHex(locateFirstUserStackElement
(new Exception().getStackTrace).getClassName)
} else {
_formGroup.is match {
case Full(x) => Helpers.nextFuncName(x.toLong * 10000L)
case _ => Helpers.nextFuncName
}
}

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

New Milestone coming soon

2009-11-11T11:54:46Z

Folks,

There are two critical issues with M7:

Issue 164 http://github.com/dpp/liftweb/issues#issue/164 JSON/Ajax messages do not carry Notices back to the client.
The Session manager is not initialized properly. Basically, this means that sessions will be expired by the web container, but not by Lift and GUIDs that map to functions on the server side are not removed until the session is terminated.

We're planning to do an M7.1 release later this week (probably Friday).

If there are other *critical* defects (stuff that means you can't use M7 in production), please speak now.

Thanks,

David

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

From forum: liftweb

Minor Bug? MappedString.valUnique should return one FieldError

2009-11-11T11:53:26Z

Hi,

I'm currently adding a uniqueness requirement to a field, but there
are duplicate entries (for empty string) in my database already.
Currently valUnique maps each match it found to a FieldError, but
should probably return one FieldError regardless of how many matches
it finds.

- Jon
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: Case classes as Map key value fail?

2009-11-11T11:30:52Z

On Nov 11, 2009, at 5:55 PM, Paul Phillips <paulp@...> wrote:

> On Wed, Nov 11, 2009 at 05:25:46PM +0100, Normen Müller wrote:
>> Now, I defined a map with key type LocationPath.
>>
>> val m: Map[LocationPath, Message)
>>
>> The weird thing is the following:
>>
>> (1) println(m isDefinedAt (Ʈ↘(1)↘(3)))
>> (2) println(m.keys find (_ == Ʈ↘(1)↘(3
>
> Well, find on the keys just goes through them looking for one which
> returns equals, but isDefinedAt on the map will use the hashCode and
> only look in that bucket. In other words, you have equal objects with
> unequal hashCodes. This is a not-too-surprising bug which I expect is
> related to unicode and the fact that productPrefix (the name of the
> case
> class) is used in the generation of the hash code.
>

So, I will eliminate Unicode and try again. Right?

> If you could open a ticket that would be great.

I am on the road right now but will do asap.

Thanks for you help!

Cheers,
--
Normen Müller
>

From forum: Scala - User

Re: Template help

2009-11-11T11:09:39Z

I didn't see Tim's blog post, but another option is to bind in two passes. First bind the outer level: b1:link should become an SHtml.link, preserving the same set of child elements. So here use a NodeSeq function: kids => SHtml.link(..., kids). Then pass the resulting NodeSeq to a bind invocation that transforms your other elements.
You can place this in one statement, by using one call to bind as the NodeSeq argument to the other call. And you can use the implicit in BindPlus to chain bind calls:
xhtml.bind("prefix", bindParams ... ).bind("pre2", ...)
That said, I think there is a fundamental, inevitable tension between separation of view and logic, and repetition (not really your point). I tried to address this, as it applies to Mapper fields, to a small extent in ModelView. However if anyone has better ideas of how to do things I'm very interested to hear!

-------------------------------------
Timothy Perrett<timothy@...> wrote:

Take a look at:

http://logji.blogspot.com/2009/09/composable-bindings-in-lift.html

and then:

http://logji.blogspot.com/2009/10/composable-bindings-in-lift-part-ii.html

Sounds like this could provide a more flexible implementation pattern for your use case.

Cheers, Tim

On 11 Nov 2009, at 18:21, aw wrote:

>
> OK, your suggestion definitely makes the snippet code more readable,
> but I fear I didn't make my point clear because the snippet code still
> is highly coupled with the view layout.
>
> Imagine that I want to change my view from this:
>
> <a href="next">
> name
> description
> 
> </a>
>
> to this:
>
> name
> description
> <a href="next">
> 
> </a>
>
> This would mean that I need to change my template from:
>
> <b1:link>
> <b2:name/>
> <b2:description/>
> 
> </b1:link>
>
> to this:
>
> <b:name/>
> <b:description/>
> <b:link>
> 
> </b:link>
>
> And then I need to update my code from:
>
> bind("b1", xhtml",
> "link" -> kids => SHtml.link("next", () => clicked(b),
> bind("b2", kids, "name" -> b.name.is, "description" ->
> b.description.is
> )))
>
> to something like this:
>
> bind("b", xhtml",
> "name" -> b.name.is,
> "description" -> b.description.is,
> "link" -> kids => SHtml.link("next", () => clicked(b))
> )))
>
>
> My complaint is that reorganizing the view is tending to require code
> changes at the snippet level. And that just doesn't seem right to me.
>
> At first, I thought that I could leverage the recursive nature of
> snippets. In other words, I thought I could avoid the b1 and b2
> binding keys and simply use b, then when the first round contained
> more b variables to bind, it would recurse. Alas, this didn't work
> (I'm sorry, but I don't recall the error message). But this was what
> I was thinking:
>
> <b:link>
> <b:name/>
> <b:description/>
> 
> </b:link>
>
> or this:
>
> <b:name/>
> <b:description/>
> <b:link>
> 
> </b:link>
>
> and the code would remain this:
>
> bind("b", xhtml",
> "name" -> b.name.is,
> "description" -> b.description.is,
> "link" -> kids => SHtml.link("next", () => clicked(b))
> )))
>
>
> >
>

From forum: liftweb

Re: Template help

2009-11-11T10:55:34Z

On Wed, Nov 11, 2009 at 11:21 AM, aw <anthony@...> wrote:

OK, your suggestion definitely makes the snippet code more readable,
but I fear I didn't make my point clear because the snippet code still
is highly coupled with the view layout.

If this was a MVC type framework, I think you're point would be valid. But it isn't a MVC framework. The snippet is tightly coupled to the xhtml, because it's the dynamic part of the xhtml.

The best way to mitigate these kinds of changes is to design the UI first, then build the snippets. That way, you're not rearranging as often.
See this article for a better understanding: http://wiki.liftweb.net/index.php?title=Lift_View_First

Imagine that I want to change my view from this:

<a href="next">
name
description

</a>

to this:

name
description
<a href="next">


</a>

This would mean that I need to change my template from:

<b1:link>
<b2:name/>
<b2:description/>

</b1:link>

to this:

<b:name/>
<b:description/>
<b:link>

</b:link>

And then I need to update my code from:

bind("b1", xhtml",
"link" -> kids => SHtml.link("next", () => clicked(b),

bind("b2", kids, "name" -> b.name.is, "description" ->
b.description.is
)))

to something like this:

bind("b", xhtml",
"name" -> b.name.is,
"description" -> b.description.is,
"link" -> kids => SHtml.link("next", () => clicked(b))
)))

My complaint is that reorganizing the view is tending to require code
changes at the snippet level. And that just doesn't seem right to me.

At first, I thought that I could leverage the recursive nature of
snippets. In other words, I thought I could avoid the b1 and b2
binding keys and simply use b, then when the first round contained
more b variables to bind, it would recurse. Alas, this didn't work
(I'm sorry, but I don't recall the error message). But this was what
I was thinking:

<b:link>
<b:name/>
<b:description/>

</b:link>

or this:

<b:name/>
<b:description/>
<b:link>

</b:link>

and the code would remain this:

bind("b", xhtml",
"name" -> b.name.is,
"description" -> b.description.is,
"link" -> kids => SHtml.link("next", () => clicked(b))
)))

--
James A Barrows

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: Template help

2009-11-11T10:32:27Z

Take a look at:

http://logji.blogspot.com/2009/09/composable-bindings-in-lift.html

and then:

http://logji.blogspot.com/2009/10/composable-bindings-in-lift-part-ii.html

Sounds like this could provide a more flexible implementation pattern for your use case.

Cheers, Tim

On 11 Nov 2009, at 18:21, aw wrote:

From forum: liftweb

Re: Template help

2009-11-11T10:24:00Z

You can do a recursive bind, but you must make it explicit:

def mySnippet(xhtml: NodeSeq): NodeSeq = {
def doBind(xhtml: NodeSeq): NodeSeq =
bind("b", xhtml,
"link" -> { (kids: NodeSeq) => SHtml.link("next", () =>
clicked(b), doBind(kids)) },
"name" -> "the name",
"description" -> "the description")
doBind(xhtml)
}

-Ross

On Nov 11, 2009, at 1:21 PM, aw wrote:

From forum: liftweb

Re: Template help

2009-11-11T10:21:06Z

OK, your suggestion definitely makes the snippet code more readable,
but I fear I didn't make my point clear because the snippet code still
is highly coupled with the view layout.

Imagine that I want to change my view from this:

<a href="next">
name
description

</a>

to this:

name
description
<a href="next">

</a>

This would mean that I need to change my template from:

<b1:link>
<b2:name/>
<b2:description/>

</b1:link>

to this:

<b:name/>
<b:description/>
<b:link>

</b:link>

And then I need to update my code from:

bind("b1", xhtml",
"link" -> kids => SHtml.link("next", () => clicked(b),
bind("b2", kids, "name" -> b.name.is, "description" ->
b.description.is
)))

to something like this:

bind("b", xhtml",
"name" -> b.name.is,
"description" -> b.description.is,
"link" -> kids => SHtml.link("next", () => clicked(b))
)))

My complaint is that reorganizing the view is tending to require code
changes at the snippet level. And that just doesn't seem right to me.

At first, I thought that I could leverage the recursive nature of
snippets. In other words, I thought I could avoid the b1 and b2
binding keys and simply use b, then when the first round contained
more b variables to bind, it would recurse. Alas, this didn't work
(I'm sorry, but I don't recall the error message). But this was what
I was thinking:

<b:link>
<b:name/>
<b:description/>

</b:link>

or this:

<b:name/>
<b:description/>
<b:link>

</b:link>

and the code would remain this:

bind("b", xhtml",
"name" -> b.name.is,
"description" -> b.description.is,
"link" -> kids => SHtml.link("next", () => clicked(b))
)))

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: Template help

2009-11-11T09:38:48Z

You might need to surround the kids => ... function with parenthesis.

-------------------------------------
David Pollak<feeder.of.the.bears@...> wrote:

On Wed, Nov 11, 2009 at 12:35 AM, aw <anthony@...> wrote:

>
> I need to create a snippet sequence that looks something like this:
>
> <a href="next">
> name
> description
> 
> </a>
>
> The anchor needs to be generated using SHtml.link, and name &
> description need to be bound. As a result, I end up with a template
> sequence like this:
>
> <b1:link>
> <b2:name/>
> <b2:description/>
> 
> </b1:link>
>
> Then, I need snippet code that does something like:
>
> bind("b1", xhtml,
> "link" -> SHtml.link(S.contextPath, () => clicked(b), bind("b2",
> chooseTemplate("b1", "link", xhtml), "name" -> Text(b.name),
> "description" -> Text(b.description) ))
>

Why are you using S.contextPath? But:

bind("b1", xhtml",
"link" -> kids => SHtml.link("/", () => clicked(b),
bind("b2", kids, "name" -> b.name.is, "description" -> b.description.is
)))

>
> Yuk... I'm just not happy with this. Sure, I could make it a little
> more readable, but this still seems unnecessarily complex and
> verbose. I also really don't like how the view logic is dictating my
> binding logic. In other words, if I wanted to change my view
> organization, there is a high chance that I also need to change my
> binding logic -- and that just isn't right...
>
> Is there a better strategy?
> >
>

From forum: liftweb

Re: AW: right bounded infix notation (was:how to define Operator for {Double * myType}?)

2009-11-11T09:34:38Z

On Wednesday 11 November 2009 17:46:08 Kubitz, Jörg wrote:
> Hi David,
> Thanks for the detailed reply.
>
> First, your example shows very well how nasty scala code can be: it takes
> realy hard brain work to understand what it does (at least for me - being
> a non-scla guru). And implementing such a Pattern is not intuitive.
So why do you want to add yet another layer of complexity on top of that?

> Second, "a and b" in your counterexample should simply result in a
> "ambigious definition Error" at compiletime. Its hard to believe that
> anybody produces such code.
You think so? Imagine that there's a class with a "def +(that: AnyRef)" on it,
that does something like just calling ".toString" on "that"; quite reasonable.
With your approach, it would not be possible to add a "+" method to that class
by means of reverse methods, since every such method would conflict with the
original "+" method.

> Justification: Suppose I am the Author of
> Class B. "Inverse" is only needed if I cannot extend the source of Class
> A. If I cannot extend the source of Class A then I am not the author of
> Class A. Since I am not the author of Class A the author of Class A won't
> know my Class B. So the Author of Class A cannot write such a method.
Yes, I understand your problem, but there are multiple solutions for it that
don't require reverse methods, one being implicit conversions in companion
objects (that are somewhat inefficient, granted)

> The c# solution is also nice (there is also a Java trunk that enables such
> a feature) but I think the function should not need to be defined within a
> Class. If I could write pure function library it would be clearer:
>
>
> Package stringExtention {
> def myStringMethod(s: string)= ...
> }
>
> "hallo".myStringMethod()

You can already do that by either using 1. companion objects for a related
class or 2. package objects (Google it). I don't think that package-level
methods are a good idea, since Scala tries to be an object-oriented language,
and unless you want such package-level methods to be instantiated as singleton
function objects, it's not a sustainable solution.

> Nevertheless it would not fix that method "::" arbitrarily has the inverse
> order.
>
> Talking about future: How much is it to extend scalar with either mine or
> your idea?
I think that a good place to ask that would be on the scala-discussion mailing
list. It's there that discussions about new features are supposed to be,
anyways.

>
> Jörg
>
>
> -----Ursprüngliche Nachricht-----
> Von: David Flemström [mailto:david.flemstrom@...]
> Gesendet: Mittwoch, 11. November 2009 16:55
> An: scala-user@...; Kubitz, Jörg
> Betreff: Re: [scala-user] right bounded infix notation (was:how to define
> Operator for {Double * myType}?)
>
> Hello,
> First, your problem of "nasty implicit type conversion imports": You can
> always put your implicits in the companion object of your class, and they
> will be loaded automatically, e.g:
>
> package example {
> object S {
> implicit def int2s(i: Int) = new {
> def method() = println("s")
> }
> }
> class S
> }
> object Program {
> def main(args: Array[String]) = {
> import example._
> val x = new S
> x.method()
> }
> }
>
> Secondly, your language extensions:
> I see many problems with this, one being that the Scala syntax can't be
> changed "just like that", and another being that your solution brings about
> quite a few syntactical conflicts, like, for example:
>
> class A {
> def and(b: B) = println("A")
> }
>
> class B {
> inverse def and(a: A) = println("B")
> }
>
> object Program {
> def main(args: Array[String]) = {
> val (a, b) = (new A, new B)
> a and b
> }
> }
>
> I like the idea of adding some mechanic that would allow you to skip
> implicits for some use cases (because implicits are expensive; they
> require a wrapper object to be created), but I don't think that your
> soultion is sustainable.
>
> What would work, as can be seen in the CLI-language C# (some of you might
> have heard about it ;-) ), would be to allow for pure extension methods to
> classes, like so:
>
> class SomeClass
>
> object SomewhereElse {
> def newMethod(this: SomeClass, arg: String) = println(this + " says " +
> arg) }
>
> object Program {
> def main(args: Array[String]) = {
> import SomewhereElse._
> val x = new SomeClass
> x newMethod "Hello" //Compiler transforms this to newMethod(x,
> "Hello") }
> }
>
> It would be clean and not break any current code, but I don't think that
> something like that will be implemented in the near future (but maybe I
> should write a compiler plugin for it anyways?)
>
> On Wednesday 11 November 2009 14:43:15 Kubitz, Jörg wrote:
> > Hi
> >
> > I realy don’t like that Methods with ":" as the last character are
> > bounded in the inverse Order (by that implicity you put a domain specific
> > feature into the language). Thats neither intuitive nor documented on
> > http://www.scala-lang.org/node/118
> >
> > On the other side I see the need of inverse bounding and would like to
> > use the inverse bounding as well for my scalar-multiplication "*" to get
> > rid of that nesty implicit type conversion import.
> >
> > So my suggestion is that the inverse bounding can (and has to) be
> > declared explicitly Unary Operators would then become a special case
> > (inverse bounded method without parameter)
> >
> > Instead of
> > def ::[U>:T](x:U):List[U]= new scala.::(x,this)
> > def unary_~ : Rational = new Rational(denom, numer)
> >
> > I would like a explicit definition of inverse bounding like this:
> > inverse def ::[U>:T](x:U):List[U]= new scala.::(x,this)
> > inverse def ~ : Rational = new Rational(denom, numer)
> >
> > Furthermore it would be nice if one could define tenary (or even higher)
> > operators in this style: def myif(this)then(y)else(z) : any = if x then
> > y else z
> > def select(this)from(t : table) : ...
> > def insert(this)into(t : table) : ...
> >
> > i.e. "(this)" defines the place of the hidden class instance parameter.
> >
> > That’s why I suggest the following syntax for explicit inverse bounding:
> >
> > def [U>:T](x:U)::(this) :List[U]= new scala.::(x,this)
> > def ~(this) : Rational = new Rational(denom, numer)
> >
> >
> > Jörg Kubitz
> > -----Ursprüngliche Nachricht-----
> > Von: Kevin Wright [mailto:kev.lee.wright@...]
> > Gesendet: Montag, 9. November 2009 17:08
> > An: Kubitz, Jörg
> > Cc: Paul Phillips; scala-user@...
> > Betreff: Re: [scala-user] how to define Operator for {Double * myType}?
> >
> > You can use a static import, or put the implicit in the cashflow
> > companion object (I think, this may not work as you're not actually
> > converting to a cashflow, I forget the exact spec)
> >
> > I also believe that an implicit in the package object (for whatever
> > package contains cashflow) will do the trick under 2.8, though I
> > haven't actually tested this one myself...
> >
> > On Mon, Nov 9, 2009 at 4:00 PM, Kubitz, Jörg <jkubitz@...> wrote:
> > > Thanks, but the compiler does not allow a "implicit" outside a
> > > (class)body. So I would have to put the line
> > >
> > > implicit def num2commute(x: Double) = new { def *(c: cashflow) = c * x
> > > }
> > >
> > > in every method that uses a Multiplication? I hope you are kidding me
> > > ;)
> > >
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Kevin Wright [mailto:kev.lee.wright@...]
> > > Gesendet: Montag, 9. November 2009 16:57
> > > An: Paul Phillips
> > > Cc: Kubitz, Jörg; scala-user@...
> > > Betreff: Re: [scala-user] how to define Operator for {Double * myType}?
> > >
> > > On Mon, Nov 9, 2009 at 3:46 PM, Paul Phillips <paulp@...>

wrote:

> > >> On Mon, Nov 09, 2009 at 04:20:48PM +0100, Kubitz, Jörg wrote:
> > >>> Is there a trait for adding Commutativity? Can such a trait be
> > >>> implemented in general?
> > >>
> > >> In general? No. Your problem is that * already exists on Double, and
> > >> the error of calling that with the wrong type trumps an implicit
> > >> conversion (maybe that could change, but it feels unlikely.)
> > >
> > > Ouch! Looks like we have another candidate for Scala puzzlers...
> > > We live and learn :)
> > >
> > >> If you pick a fresh operator you can do this, or a more efficient
> > >> equivalent.
> > >>
> > >> implicit def num2commute(x: Double) = new { def **(c: cashflow) = c **
> > >> 2 }
> > >>
> > >> --
> > >> Paul Phillips | Every normal man must be tempted at times
> > >> Stickler | to spit on his hands, hoist the black flag,
> > >> Empiricist | and begin to slit throats.
> > >> i pull his palp! | -- H. L. Mencken
>

From forum: Scala - User

Re: Issue 164: S.notice, S.error, etc. broken from within AJAX/JSON calls

2009-11-11T09:33:32Z

M7.1 would be extremely helpful to me as I'm trying to move a project into QA and I'm loathe to use a moving target for QA. However, if need be I can stick with a working SNAPSHOT up until M8, if M8 is really coming around first week Dec.

-Ross

On Nov 11, 2009, at 12:21 PM, David Pollak wrote:

It's stuck on review board.

We're thinking of a M7.1 release because M7 is pretty broken with this issue and the Session-related issue that Harry reported.

On Wed, Nov 11, 2009 at 9:18 AM, Ross Mellgren <dridus@...> wrote:

Hey, any news on when this change will be pushed? I compiled a local copy and verified the fix works with my larger application, but I can't seem to get Maven to consistently keep my copy of 1.1-SNAPSHOT around and not download the new copies from scala-tools.org (I'm a Maven newbie, so I'm open to the possibility that I suck).

-Ross

On Nov 7, 2009, at 9:52 AM, David Pollak wrote:

On Fri, Nov 6, 2009 at 1:26 PM, Ross Mellgren <dridus@...> wrote:

I can confirm that my app now works correctly. Is there already a date set for M8? Or will this make it in to the M7 post release? I prefer to use milestones this late into dev, to avoid new errors popping up.

The M7 post-release was only for a particular issue for a particular user and it turns out that their issue was a non-Lift issue.

M8 will be out in early December (we target the first Wednesday of the month).

Is you app in production (actual end users using it)? We have a policy of heightened support for production apps and this issue is non-trivial, so it may be work an ancillary release if it's hitting you in production.

-Ross

On Nov 6, 2009, at 3:38 PM, David Pollak wrote:

On Fri, Nov 6, 2009 at 12:37 PM, Ross Mellgren <dridus@...> wrote:

On Nov 6, 2009, at 3:24 PM, David Pollak wrote:
On Fri, Nov 6, 2009 at 12:03 PM, Ross Mellgren <dridus@...> wrote:

Paytronix Systems, Inc.

Centrally hosted gift and loyalty card solution -- standard-ish 2-3 tier, SQL server backend, JBoss (mostly as servlet container) middleware exposing web and web services, custom POS integration software at restaurants. You've probably seen a bunch of our customers.

Right... you told me this already... sorry for forgetting.

No problem. My boss (Stefan Kochi) might be sending you an email soon.

Also, your fix is up in dpp_issue_164 on GitHub.

Thanks! I take it it'll go through the usual review board cycle?

Yes, it's up on review board now, but you can pull the dpp_issue_164 branch and do a local build.

-Ross

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Surf the harmonics

From forum: liftweb

Re: ManyToMany decision

2009-11-11T09:31:55Z

To clarify: The fundamental purpose of ManyToMany, like OneToMany, is that rather than dealing with "children" of an entity as they are in the database at a given moment, instead, they should have similar semantics to a MappedField: You load it from the database, modify it to your hearts content, and then decide whether you want to save it or not. For example, calling set() on a MappedField does not write immediately to the database, and it's a good thing too--imagine a multi-page form where you can go back and forth to different screens, or a single page form that uses submit buttons that perform some action but you stay on the same page. You don't want the user's changes to go the database unless he clicks "Save." So too, one often wants to edit a list on one screen. There should be submit buttons to add records, etc., but if you don't click save it shouldn't go to the database.
So MappedOneToMany and MappedManyToMany act as collections, internally keeping track of which records were inserted or removed, but not performing a create or delete until the "field" is saved. So in other words they act as multi-valued fields.
There are two ways MappedManyToMany can do this. It can hold a list of join table records, or child table records. Either way it will have to look up the other at times.
Now in order for saves and deletes on the ManyToMany Mapper to be propagated to the MappedManyToMany fields, it has to have a list of them. The list only gets populated when code references the field, causing it to be initialized and add itself to the list of m-n fields.
So we make all of these proposed changes?

-------------------------------------
Jim Barrows<jim.barrows@...> wrote:

On Tue, Nov 10, 2009 at 2:16 PM, Naftoli Gugenheim <naftoligug@...>wrote:

> Hello.
> When I wrote ManyToMany a couple of months ago, I designed it to internally
> hold a collection of join table records, and to act as a collection of
> elements of the child table.
> For example, given Volunteer and VolunteerGroup where volunteers can be in
> multiple groups, Volunteer.volunteerGroups implements a collection of
> VolunteerGroups, but internally it's actually managing a collection of
> VolunteerVolunteerGroups (the join table).
>

I don't think you really need to maintain the pivot table list
(VolunteerVolunteerGroups) at all. If you maintain the Many-to-Many as part
of the object, and use a standard naming convention then you don't really
need this extra list running around. You can still build the SQL correctly
knowing only the objects involved.

> The current implementation throws an error (Predef.error) when it tries to
> get the child element via the join record and it doesn't exist. Thus any
> page accessing corrupted data will not display if the error is not caught. I
> plan, G-d willing, to change the implementation to silently skip such
> records.
> But the occurrence that reminded me of the defect also brought another
> point to my attention. To my knowledge Lift's schemifier does not correctly
> generate foreign key constraints for all databases (at least not at the
> point in time it schemified my H2 database... :) ) so we need a way for
> ManyToMany to keep things in sync. ManyToMany helps, to an extent, because
> when its MappedManyToMany members are initialized, it puts them in a list,
> and it propagates saves and deletes. So if you have a ManyToMany Mapper
> instance that contains a MappedManyToMany that has been initialized, and you
> call delete_! on the Mapper, it will delete all the associated join table
> entries. But it's not enough.
>
> 1. That can only happen if both sides of the relationship use
> MappedManyToMany. Is there some way to enforce this? I was thinking of using
> a combination of (a) requiring the foreign MetaMapper to extends ManyToMany,
> and (b) when a MappedManyToMany is initialized, it should check that the
> foreign MetaMapper/ManyToMany actually contains a MappedManyToMany referring
> to the current MappedManyToMany. (a) is not sufficient without (b), and (b)
> has the same problem as #2 below, that objects are lazy.
>
>

I think you're right here. Both sides have to have the mapping.. however I
don't think there is a good clean way to detect this without a compiler
plugin of some kind.

>
> 1. There is a basic problem, which is that since objects are lazy, if
> you haven't referenced the MappedManyToMany field, delete_! will not be able
> to propagate to the join entries.
>
>
As you traverse the deleteing side, doesn't the other side get initialized
as well?

> #2 and #1.b can be solved by using reflection to initialize the
> MappedManyToMany members eagerly, just as MetaMapper does for all
> MappedFields. (MappedManyToMany is not a MappedField.) Now the advantage to
> having them lazy is that if you don't reference them they don't query the
> database. This advantage can be retained though by implementing the
> collection internally to populate lazily, much as MappedOneToMany already
> is.
>
> Thoughts?
>

I think your maintaining to much information that can be deduced from the
context.

>
> Thanks,
> Naftoli Gugenheim
>
>
>
> >
>

--
James A Barrows

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb

Re: Google's new language, Go

2009-11-11T09:24:32Z

Agreed about the standard library and case classes/pattern matching, thanks for pointing out my folly. I expect that a lazy var would confuse the life out of us.

C# and VB provide decent functional abstractions too, at least all of those that you listed.

2009/11/11 Alex Boisvert <alex.boisvert@...>

Scala encourages immutability in different ways. One is providing a set of immutable data structures as part of the standard library. Another is case classes defaulting to val's for their arguments. Tthere's no equivalent of "lazy val" for var's. Providing decent functional abstractions also indirectly encourages immutability (first-class functions, map, folds, reduce, for-comprehensions, ...). Pattern matching supports scalable decomposition of data structures without resorting to mutability, etc.

I agree there's more that could be done but I think there's a good case for saying that Scala encourages immutability -- at least if you consider other mainstream programming languages as your basis (Java, C/C++/C#, Ruby, Python, Perl, VB, ...).

alex

On Wed, Nov 11, 2009 at 8:52 AM, Ricky Clarkson <ricky.clarkson@...> wrote:

Scala doesn't help you to know whether a type is immutable any more than Java does. val is terser than public final, but other than that it's not very informative. The *docs* encourage immutability more than the language does.

Effect systems have been considered, but I think it's pretty hard to come up with one that makes the OO programmers happy too.

2009/11/11 Marcus Downing <marcus@...>

Ricky Clarkson wrote:
>
> Scala hardly encourages immutability either, so we might be the wrong
> people
> to ask. :)

Really? I'd say Scala encourages but doesn't enforce - which is the right
approach. Since learning Scala, I've found my code in Java and even in PHP
is more functional in nature (and more reliable because of it).

Ricky Clarkson wrote:
>
> I haven't worked out yet whether it supports type parameters.

No.
--
View this message in context: http://old.nabble.com/Google%27s-new-language%2C-Go-tp26302993p26304512.html

Sent from the Scala - Debate mailing list archive at Nabble.com.

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

From forum: Scala - Debate

Re: Unit testing a RESTful webservice with Lift

2009-11-11T09:22:47Z

Looks nice.

Singleton - ah, yes, that sounds like it will work well, good call.

On Wed, Nov 11, 2009 at 12:05 PM, David Pollak <feeder.of.the.bears@...> wrote:

On Wed, Nov 11, 2009 at 7:09 AM, Alex Black <alex@...> wrote:

What are you unhappy about? Those tests look pretty simple and slick
to me!

Yeah, but with this change: http://reviewboard.liftweb.net/r/95/

You'll get:
"Login" in { for{ login <- post("/api/login", "token" -> token) !@ "Failed to log in" if (testSuccess(login)) status <- login.get("/api/status") !@ "Failed to get status" if (testSuccess(status)) } { (status.xml \ "user" \ "@id").text must_== theUser.id.toString } }
It looks like the JettyTestServer is a singleton inside the test suite
- what happens if you have another test suite? I think you'd then hit
the same problem that I did, when the second test suite tries to fire
up Jetty it will fail because Lift has already been initialized.

The example in ESME is a singleton, but the start method is actually a lazy val, so you can call it from any test, but it will only be triggered once per run per classloader. Does this give you what you want? If not, it'll be some mucking around with multiple classloaders.

- Alex

On Nov 10, 2:25 pm, David Pollak <feeder.of.the.be...@...>
wrote:

> I've just committed simple API test code up to the ESME project. The key
> pieces are at:
>

> http://svn.apache.org/viewvc/incubator/esme/trunk/server/src/test/sca...http://svn.apache.org/viewvc/incubator/esme/trunk/server/src/test/sca...

>
> After spending 30 minutes with the Lift TestKit, I'm wicked unhappy with
> it... but that will change later today. ;-)
>
>
>

> On Tue, Nov 10, 2009 at 9:51 AM, Alex Black <a...@...> wrote:
>
> > My first unit test worked fine, but my second one dies:
>
> > ERROR - Failed to Boot
> > java.lang.IllegalStateException: Cannot modify after boot.
> > at net.liftweb.http.RulesSeq$class.safe_$qmark(LiftRules.scala:885)
> > at net.liftweb.http.RulesSeq$class.prepend(LiftRules.scala:892)
> > at net.liftweb.http.RulesSeq$$anon$3.prepend(LiftRules.scala:872)
> > ....
>
> > Presumably because it has already loaded and started Lift, and my
> > second unit test fires up Jetty again trying to start Lift again which
> > I take it is not supported.
>
> > So, I figure I should either:
> > a. refactor my tests so that I only create one jetty and lift instance
> > ever
> > - this will probably require 'resetting' the service somehow to ensure
> > a blank slate between each unit test, not sure how I get a hold of the
> > instance in question for that
>
> > b. somehow launch jetty/lift differently, or force lift to cleanup?
>
> > On Nov 9, 10:50 pm, Jonathan Ferguson <j...@...> wrote:
> > > We fire up Jetty populate a temp database and then run a batch of tests.
> > > Seems to work well for us.
>
> > > Jono
>
> > > 2009/11/10 Alex Black <a...@...>
>
> > > > Can anyone suggest some good examples or strategies to use to test a
> > > > webservice written with Lift?
>
> > > > I've started down the path of firing up Jetty in a unit test, then
> > > > just hitting it with say a GET and checking the response. Whats a
> > > > good way of firing up Jetty? It looks like using ServletTester would
> > > > be the way to go:
>
> >http://www.christianschenk.org/blog/testing-web-applications-with-jetty/
>
> > > > could that work with Lift?
>
> > > > - Alex
>
> --

> Lift, the simply functional web frameworkhttp://liftweb.net

> Beginning Scalahttp://www.apress.com/book/view/1430219890

> Follow me:http://twitter.com/dpp
> Surf the harmonics
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890

Follow me: http://twitter.com/dpp
Surf the harmonics

--
http://blog.alexblack.ca
http://twitter.com/waterlooalex

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to liftweb@...
To unsubscribe from this group, send email to liftweb+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
-~----------~----~----~----~------~----~------~--~---

From forum: liftweb