Why not use colon instead of "extends"?

[Fiery]

Just one of my thinking being around there for quite a while about extending the concise style of other part of Scala language specs, "extends" just looks verbose and I personally took it as one typical Java expression.
I admit that I got too tried of Java's verbosity and I feel very much excited about making changes thru Scala's expressiveness and simplicity.

Just take a look at languages that considered more modern, like Python:

class sub_class(super_class) .....

like Ruby:
class SubClass < SuperClass .....

these are languages from which Scala get some of the syntax inspiration.

Plus, using colon makes it look more consistent with Scala's type system:

val word: String = "Hello"
var iter : Int = 1
def func : String = "I am a string"
val func : Int = { num : Int => num }

and take a look at what it will be like if use colon to replace extends:

class MoreString(val more : String, val count : Int) : String {.........}

I like using "with" to differentiate trait from class, here is how to mixin traits.
class MoreStrongString(val more : String, val count : Int) : String with StrongFeature {.........}


I understand that colons in Scala means slightly differently as what I suggest with class inheritance, but look at function result type, it's also a little different from the type for val/var. So there is nothing to lose with a more beautifully simple and clean world.

[Hanns Holger Rutz]

You can do this with traits:

trait Foo

trait Bar <: Foo

I'm not exactly sure about its nature, I think it's called virtual
classes, because:

class Baz <: Foo

<console>:1: error: classes are not allowed to be virtual
class Baz <: Foo
^

On 01/14/2015 09:08 PM, Fiery wrote:
> Just one of my thinking being around there for quite a while about
> extending the concise style of other part of Scala language specs,
> "extends" just looks verbose and I personally took it as one typical
> Java expression.
> I admit that I got too tried of Java's verbosity and I feel very much
> excited about making changes thru Scala's expressiveness and simplicity.
>
> Just take a look at languages that considered more modern, like Python:
>
> class sub_class(super_class) .....
>
> like Ruby:
> class SubClass < SuperClass .....
>
> these are languages from which Scala get some of the syntax inspiration.
>
> Plus, using colon makes it look more consistent with Scala's type system:
>
> val word: String = "Hello"

> var iter *:* Int = 1
> def func *:* String = "I am a string"
> val func *:* Int = { num *:* Int => num }

>
> and take a look at what it will be like if use colon to replace extends:
>

> class MoreString(val more *:* String, val count *:* Int) *:* String

> {.........}
>
> I like using "with" to differentiate trait from class, here is how to
> mixin traits.

> class MoreStrongString(val more *:* String, val count *:* Int) *:*

> String with StrongFeature {.........}
>
>
> I understand that colons in Scala means slightly differently as what I
> suggest with class inheritance, but look at function result type, it's
> also a little different from the type for val/var. So there is nothing
> to lose with a more beautifully simple and clean world.
>

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

[Fiery]

Hi,
I learn <: and >: as the type parameter bounds of inheritance. And this is another reason to make me think of colon is a better way to express inheritance in Scala since it's more consistence with these bounding notations.

> <mailto:scala-language+unsub...@googlegroups.com>.

[Jon Pretty]

Hi Fiery,

Of academic interest is that the syntax you describe was previously the syntax to indicate a self-type in Scala, before it got changed to the `requires` syntax, and subsequently the current style.

You could write it like that, but I think it introduces two potential (but arguable) ambiguities. The first is a minor visual one: It can already be difficult to parse, when reading a long class signature, without reading the whole thing for context. `extends` is often one anchor point you can use to see if, for example, you're reading the definition, or the parameter list of the class you're extending. If you take that away, you're left hunting for the single-character parentheses, or inferring it from the presence (or not) of type ascriptions on the parameters.

The other is that `T: TypeName`, when appearing in a type parameter definition, already means "treat `TypeName` as a type constructor, and require an implicit of type `TypeName[T]`.

Neither of these are massive issues in the grand scheme of things, but I don't think just making the syntax terser and more regular is a good enough reason to change Scala, if that comes at the cost of more overloaded syntax. I should say that this isn't something I feel especially strongly about, and if Scala had gone with `:` instead of `extends` at the very beginning, then I'd probably be arguing the opposite way, but it's the disproportionate extra hassle to change everyone's code that makes it not worthwhile.

Cheers,
Jon

--

You received this message because you are subscribed to the Google Groups "scala-language" group.

To unsubscribe from this group and stop receiving emails from it, send an email to scala-languag...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Jon Pretty | @propensive

[Fiery]

I agree with you and I knew the impact that will bring to parsing the code as you mentioned. I am actually being criticizing about it since I found other parts are very seamlessly and elaborately created. :)
I ignored the type parameter context bound and now that expression looks pretty awkward in my point of view... :(

[Fiery]

Oh so your first point is about readability for human beings, well I do think there may make it a bit more complex while the compiler goes to split and parse the line, I don't see any problem with human eyes as left hunting of parentheses would be only glimpse back a column or two.

OK I am just being criticizing....I am not a Java type of person so whenever I have to type 5+ characters keyword I feel sick!

On Wednesday, January 14, 2015 at 1:04:35 PM UTC-8, Jon Pretty wrote:

[Jon Pretty]

Yeah, Scala does go a long way towards unifying ideas into a single syntax where other languages might choose to treat them as separate concepts. The most extreme example of syntax reuse is the underscore, but there are others. But it's very difficult to get these sorts of decisions right, as the expectations of a variety of different users with different backgrounds have to be taken into account... ;)

Cheers,
Jon

[Adriaan Moors]

Hi,

On Wed, Jan 14, 2015 at 12:08 PM, Fiery <fie...@gmail.com> wrote:

Plus, using colon [instead of extends] makes it look more consistent with Scala's type system:

Being classified by a type "(x: Int)" and being a subtype of a type "(String <: Any)" are different things, though.

(E.g., subtyping is transitive whereas this doesn't make sense for the is-type-of relation, which is stratified.

 Concretely, 1 : Int, and Int : *. We don't talk much about *, but you can think of it as the "type", or rather: "kind", of the types that classify values.)

When it comes to "<:" versus "extends", subtyping and inheritance are related, but not the same thing (extends is also about code reuse, whereas subtyping does not imply sharing of code).

cheers

adriaan

[Rex Kerr]

For long signatures, having a word really simplifies style.

class Foo(thisIsAReallyLongParameterName: OfATypeWithAVeryLongName)

extends Bar(thisIsAReallyLongParameterName, "This is here just to take up more space") {

  def foo = "foo"
}

If you used :, in addition to the other points people have made, this sort of thing would be much harder to parse.  Even if you went to some style with indentation, having no key word to lead the line to tell you what is going on makes it less readable.

  --Rex

[Rex Kerr]

On Wed, Jan 14, 2015 at 2:07 PM, Adriaan Moors <adr...@typesafe.com> wrote:

Hi,

On Wed, Jan 14, 2015 at 12:08 PM, Fiery <fie...@gmail.com> wrote:

Plus, using colon [instead of extends] makes it look more consistent with Scala's type system:

Being classified by a type "(x: Int)" and being a subtype of a type "(String <: Any)" are different things, though.

Welllll, it's a lot less clear when you have value types and dependent types.  x: Int is essentially x: x.type extends Int {}, at which point the distinction is minimal at best.  x is, after all, reusing the (all of the) code for Int.  That you haven't decided to override any of the behavior is interesting but not essential to the is-a relationship logic.

So technically I agree, but it's a somewhat artificial limitation of the type system that makes it true.

 --Rex

 

[Fiery]

I agree, is-a relationship is one of the latent point that support my thinking of using colon.
However, you made a valid point about readability. I haven't been doing complex coding with Scala yet. Interesting thing is this makes me wondering how Rubyists deal with their ReallyLongParameter. :_

[Fiery]

Realized that Ruby doesn't have parameter initialization at declaration.... makes sense then. :D