Andy Hicks | 27 Jul 17:30 2014
Picon

Scala-Swing - Community Support

As you may know scala-swing has been given the status of 'community supported'. 

If anyone is interested and would like to contribute to making swing usable with scala then I would welcome your help.

As this does easily fit within the scala-internals googlegroup (or that matter any of the others ) we've created a new scala-swing group  https://groups.google.com/forum/#!forum/scala-swing

Some of the initial changes have been changes 
- java7 - most/all of the new work will be put into the 'java7' branch for mainly practical reasons, however this branch is still compiled for java 6 and will work on on it and above.
- beginning to fix the Publisher 
- making the examples work in sbt

Any questions? please post to the google group.




--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Kevin Mas Ruiz | 26 Jul 22:11 2014
Picon

Doubts about Scala language design

Hi,

I love programming language design and I've started to learn Scala about two months ago. Coming from a very functional style programming (but having basic knowledge about OOP) I started having doubts about different Scala approaches to some problems. I wanted to discuss them here because I think it's a very interesting debate and maybe we could learn a lot about it.

The first thing are traits. I don't understand why Scala supported traits. If they wanted sharing a default implementation of a method between different types by inheritance, why not using multiple class inheritance as C++?  Me, as a rookie in Scala, I doubt when using traits and abstract classes sometimes. I normally use abstract class when inheritance is very complex and is more about data than behavior and traits for applying implicits on scopes I want (for example, implicits for casting a type A to B directly for easy integration with a third-party library). Is that a good methodology or should I think about other things?

The second thing is about function and method combination. I come from Common Lisp and one of the features I love is the ability to inject code before and after any method known at compile time or runtime. It's very useful for security access injection on a service oriented architecture or simply logging. For example in CL we could do something as this:

(if logging-enabled-p (defmethod save :before ((repository repository) any-object) (log "inserting ~a via ~a~%" any-object (name repository))))


In Scala, would be lovely to do so, for example, as this:

trait Logging {
   
def name: String
   
def before save(o: Any) { log("inserting %s via %s", o.toString, name) }
}


And then doing something like this:

if (loggingEnabled) {
   fooRepository
= new FooRepository with Logging
}


This is useful because we can define a lot of logic that is easy to maintain using a declarative approach (as logging and security) and should be layered out of the main implementation of our system. For example:

abstract class FooService {
   
def someAdminAction(withData: Foo): Foo
}


class FooServiceImpl extends FooService {
 
def someAdminAction(withData: Foo): Foo = veryComplexLogic(withData)
}


trait
SecuredFooServiceAspect(val user: User) extends FooService {
 
def before someAdminAction(withData: foo): Foo = {
     
if (user.canDoThis) {
         someAdminAction
(withData) // delegates to the next implemetation
   
} else {
       
throw new InvalidAccessException(user)
   
}
 
}
}


Why something like this has not been implemented in Scala? Would be a good idea acquiring this tool in the language? Maybe it can be done using annotations resolved at compile-time.

Another thing I don't now why Scala does not support is constant parameter dispatching as does Erlang. For example, in Erlang we can do something like this:

fac(0) -> 1;
fac
(N) when N > 0 -> N*fac(N-1).

This is a very useful and expressive approach for function definition and sometimes can be optimized at compile time (p.e a fac of a constant). I know that Scala has pattern matching (very useful) but I must admit that sometimes I avoid it because it's very verbose and complex for a lot of common cases. I would love Scala if I could do something as:

def save(foo: Foo) = DB.save(foo)
def save(None) {}

Which is far better than:

def save(foo: Foo) = {
   
if (foo != None) {
      DB
.save(foo)
   
}
   foo
}


This approach of "do-nothing-if-null" is very useful and taken a lot in other languages. For example, in C, free(NULL) does nothing (also delete null in C++)

Well, that's all. I didn't learn all of Scala so I'm sure in a future I will have more questions. Any idea about something I did? Any objections?

And after all, sorry for my English, I'm not very fluent writing it and I did my best. Also I accept corrections on this :)

Thank you all and hack Scala! 

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 22 Jul 07:12 2014
Picon

Maybe braces really are parens


I find it mildly peeve-inducing when people say that braces and parens are somehow interchangeable, but here is more evidence in their favor:

def f() {}  // an empty procedure

gets rewritten to

def f() = ()

Also, it's certainly a measure of some degree of desuetude in the community that this is what passes for Scala debate these days.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Scala Mailing Lists | 21 Jul 15:32 2014
Picon
Picon

Mailing list reminder: Scala-debate

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe <at> googlegroups.com

Thank you!
The Scala Team

--

-- 
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Malte Isberner | 19 Jul 06:50 2014
Picon

Updated method for case classes

Hi,

I have been using Scala for about a month now, and what I like most about it is how it allows you to write very concise code - even more so since I almost exclusively used Java for the last couple of years. I'd like to discuss a pattern I found myself using frequently when working with immutable objects/case classes, and I wonder if this might be something general enough to be added to the language (as an additional synthetic, autogenerated method for case classes).

I often use case classes whose values are immutable collections, such as Maps. In many use cases, I need to "modify" (in an immutable fashion) exactly one of the instance fields, say a map. Of course I could write obj.copy(map = obj.map.updated(key, value)), which however is inconvenient if obj is not a val, but a more complex expression. My first solution was to introduce methods such as
def withUpdatedMap(key: K, value: V) = copy(map = map.updated(key, value))
but this gets tedious as the number of use cases grows: what about mapValues, remove (-) and so on?

I finally came up with this solution: https://gist.github.com/misberner/eec5e74f759353da3384 , which allows me to rewrite the above concisely by using the underscore symbol, as, e.g.,
obj.updated(map = _.updated(key, value)), or obj.updated(map = _.mapValues(-_))
It might be a little bit ugly to use the same parameter names for functions that are used for the fields, but I think this definitely contributes to the readability and descriptiveness of the updated() invocation.

I almost made a habit of adding this method to my case classes, and I actually use it more often than the copy method now. I think it'd be very useful if the compiler would autogenerate this method, as it does with copy (even though implementing it by hand is not that big of a deal, but neither would it be to implement copy).

Looking forward to hear your opinions.

Best regards,
Malte

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Rich Oliver | 10 Jul 17:57 2014
Picon

Do we need Collection[T <: Any] classes?

This is a question for both the general case of a high level language and the particular case of a high level language targeting the JVM. It is intended to stimulate debate and increase theoretical understanding but there is absolutely no intention on my part to imply criticism of Scala's past design choices. However I personally find it very helpful to understand the reason for design choices: Basic principle / interop with JVM / interop with Java / following established conventions etc.

I consider myself very pro Objected Orientated programming to the point of paranoia, always suspecting extreme functional types (of people) of seeking to abolish inheritance. In one sense no existing language is object oriented enough for me: providing strong static typing, fully constructor multiple inheritance and proper handling of variance. But having Collection classes that take a type parameter inherited from Any seems totally inappropriate.

So there should be a collection inheritance heirachy based on T <: AnyRef and then separate collection heirachies for say

8 byte values
16 byte values
24 byte values
32 byte values

arguably there should also be hierarchies for 4 and 12 byte values.

Some kind of Macros could generate the different hierarchies to keep the code DRY. Map functions could map between them, but they should not under any circumstances be connected by inheritance. I really can't see the need for having collections that contain both ref and value types, but even if there are people who would use them I don't think that justifies the great damage that over generic hierarchies create. The above could handle C# style structs. In similar vein there is the slogan "everything is an object". To which my reaction is: no its not and what on earth is gained by pretending that it is? I can see how there might be advantages for Dynamic languages but not for Static.

In an ideal world I don't think == should be inherited from Any either. Then a RefSet[+T <: AnyRef] class could be covariant.

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 5 Jul 02:37 2014
Picon

Softwear


I don't mean to start a language flame war, but Scala has better t-shirts, if only I knew how to get one.

http://blog.xamarin.com/run-a-f-sharp-app-get-a-f-sharp-shirt/


--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Som Snytt | 27 Jun 04:32 2014
Picon

Option Viktor


Sorry if this is an old one, but I just read this today.

http://unicode.org/reports/tr46/

For transitional use, the Compatibility Processing also allows domain names containing symbols and punctuation that were valid in IDNA2003, such as √.com (which has an associated web page). Such domain names containing symbols will gradually disappear as registries shift to IDNA2008.

The web site describes "option V", but it turns out that "option V" has nothing to do with Akka.

http://xn--19g.com/  <http://√.com/>

For that rare pernicious Akka bug...

"We can always deploy -- option √ !!!"




--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Alexandru Nedelcu | 26 Jun 14:22 2014

The Clash of Lambdas Benchmark

Hi,

There's an interesting benchmarks circulating lately:

The benchmark is sort of comparing libraries, rather than languages, but I think 2 things are sticking out of it in regards to the apparent poor performance of Scala:

1. collections really need specialization, as working with primitives is really common and the price paid for boxing primitives is a performance killer 
2. Scala's Views are really terrible - which is odd for a standard library of an FP language exposing immutable collections as the default 

I was wondering if there are plans to address the above.

--
Alexandru Nedelcu
www.bionicspirit.com

PGP Public Key:
https://bionicspirit.com/key.aexpk

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Dimitar Georgiev | 23 Jun 10:16 2014
Picon

real arguments in favor of dynamic typing

Hello,

Happily exploring the Scala  world for a couple of years now, and Haskell more recently, I'm now looking for some good piece of writing which advocates for dynamic typing in an objective manner. That is, I want to broaden my horizons by learning to write some Underscore , or some Clojure, but I can't find good arguments to invest this precious time.

Most of the stuff I find on the internet on this topic is disappointingly mediocre opinion pieces, or stuff that is just plain wrong. For an example of the latter, see the top-rated answer of
http://programmers.stackexchange.com/questions/122205/what-is-the-supposed-productivity-gain-of-dynamic-typing

Does there exist some piece of writing on the topic that at least tries to have a scientific approach? Maths will of course be best. I could also settle for a philosophical piece, if it is careful with opinions.

Regards, Dimitar

--
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Scala Mailing Lists | 21 Jun 15:32 2014
Picon
Picon

Mailing list reminder: Scala-debate

Welcome to the "Scala-debate" mailing list.

This automatic reminder is sent once a month to the list,
to keep subscribers up-to-date with the mailing list services,
and to help keeping the list on topic.

-------------------------------------------------------------------

The "Scala-debate" mailing list:

This list is a more relaxed forum for Scala discussions
that would probably be off-topic or too convoluted for
the other lists, but that may still be quite interesting
to follow for a selected readership.

In particular, the following are appropriate:

  * threads that evolved beyond their initial topic,
      and have become too long or convoluted to be
      of interest to most readers
  * threads discussing extremely specialized topics
  * threads that are mostly speculative in nature,
      out-of-the-box thinking, philosophical views
      (as long as they are still somehow related
      to Scala)
  * debates (of course)

The "Scala-debate" list is the natural destination of all
the threads that start on other mailing lists, but are no
longer on topic on their original list, or have turned
into an in-depth debate about something.

-------------------------------------------------------------------

Other information:

There are several Scala lists devoted to individual topics (and
more may be created in the future). For the full list, please
see: http://www.scala-lang.org/node/199

Try to avoid cross-posting whenever possible. If you can, select
the list that is closer to your topic and post in that list only.
In any case, never cross-post replies.

If you ever want to unsubscribe from this list, just visit this
page: http://groups.google.com/group/scala-debate/subscribe
or send an email to scala-debate+unsubscribe <at> googlegroups.com

Thank you!
The Scala Team

--

-- 
You received this message because you are subscribed to the Google Groups "scala-debate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to scala-debate+unsubscribe <at> googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Gmane