newbie question about hiding class definition from implementation

i prefer to use traits for the specification

trait Model {
def dictionary: List[ String ]
def entityNames: List[ String ] // use camel-case style instead of underscores!
def aliases: IndexedSeq[ List[ String ]] // shouldn't use a mutable type unless absolutely necessary
def tokenize( tokens: List[ String ]) : List[ Int ]
}

class ModelImpl( val dictionary: List[ String ], val entityNames: List[ String ], val aliases: IndexedSeq[ List[ String ]])
extends Model {
private val tokenProbGivenEntity = ? // don't know what you actually want to do with this??
def tokenize( tokens: List[ String ]) : List[ Int ] = { ... }
}

the last question: no, it's not possible to define methods 'naked' outside a class or module (you can use an object or package object if they aren't associated with a class, but that seems to be the case here)

On 7 Dec 2011, at 22:03, Kevin Murphy wrote:

> Hi
>
> I'm coming to Scala from C++, where I am used to defining a class
> specification in a .h file and implementing it in a .cc file.
> I am not sure what the canonical way to do this separation in scala
> (I've been reading the staircase book but have not yet found
> the answer)
>
> Currently I use an abstract class to define the interface, and then I
> extend it with the implementation, as in this example:
>
> // specification
> abstract class ModelTemplate(val dictionary: List[String], val
> entity_names: List[String], val aliases: Array[List[String]]) {
> // methods
> def tokenize(tokens: List[String]): List[Int]
> ...
> }
>
> // implementation
> class Model( dictionary: List[String], entity_names: List[String],
> aliases: Array[List[String]])
> extends ModelTemplate(dictionary, entity_names, aliases) { // code
> smell!
> // constructor
> val token_prob_given_entity = ...
> // methods
> def tokenize(tokens: List[String]): List[Int] = {
> ...
> }
> }
>
> This seems pretty ugly - eg. the repeated arg passing to the abstract
> class in the line marked 'code smell'.
>
> Also, the computation of token_prob_given_entity is rather complex;
> I'd rather have this code inside
> a constructor function, rather than floating around 'naked' at the
> beginning of the class file.
> Is there a way to do this? (If I redefine the 'this' method with the
> same arguments, I presumably
> will get into an infinite loop?) Finally, is there a way to define
> methods using C++-style
> ClassName::method_name() syntax,
> rather than having to embed it inside the class {} scope (which wastes
> horizontal space)?
>
> Thanks!
> Kevin

I think the best answer here is: you don't do that in Scala.

The separation of header files and definition files in C++ is an
inheritance from how C worked long ago, where object files just did
not have the necessary information about the function signatures, when
there were no IDEs with pop-up helps for their definition, and, in
fact, the header file was often pretty much all of the documentation,
etc.

This is not the case where JVM is concerned. A compiled "class" file
contains everything necessary to interface with that class, and the
tooling automatically generate documentation about the API from
comments formatted in a particular way. There's no need to "hide" the
class because no one will see the class to begin with.

That said, you can separate the API into a trait and implement it with
either a trait or a class. The benefit here is to enable multiple
implementations of the same trait, which is rather different than the
separation of .h and .cc.

On Wed, Dec 7, 2011 at 20:03, Kevin Murphy wrote:
> Hi
>
> I'm coming to Scala from C++, where I am used to defining a class
> specification in a .h file and implementing it in a .cc file.
> I am not sure what the canonical way to do this separation in scala
> (I've been reading the staircase book but have not yet found
> the answer)
>
> Currently I use an abstract class to define the interface, and then I
> extend it with the implementation, as in this example:
>
> // specification
> abstract class ModelTemplate(val dictionary: List[String], val
> entity_names: List[String], val aliases: Array[List[String]]) {
>  // methods
>   def tokenize(tokens: List[String]): List[Int]
>   ...
> }
>
> // implementation
> class Model( dictionary: List[String], entity_names: List[String],
> aliases: Array[List[String]])
>  extends ModelTemplate(dictionary, entity_names, aliases) {  // code
> smell!
>  // constructor
>  val token_prob_given_entity  = ...
>   // methods
>   def tokenize(tokens: List[String]): List[Int] = {
>    ...
>   }
>  }
>
> This seems pretty ugly - eg. the repeated arg passing to the abstract
> class in the line marked 'code smell'.
>
> Also, the computation of token_prob_given_entity is rather complex;
> I'd rather have this code inside
> a constructor function, rather than floating around 'naked' at the
> beginning of the class file.
> Is there a way to do this? (If I redefine the 'this' method with the
> same arguments, I presumably
> will get into an infinite loop?) Finally, is there a way to define
> methods using C++-style
> ClassName::method_name() syntax,
> rather than having to embed it inside the class {} scope (which wastes
> horizontal space)?
>
> Thanks!
> Kevin

Yeah, Separating a no-implementation trait from traits/classes with implementation corresponds exactly to "pure virtual" classes in C++ rather than to .h headers which are the peculiar way C and C++ expose information needed during compilation.

Sent from my iPhone

On Dec 7, 2011, at 4:36 PM, Daniel Sobral wrote:

> I think the best answer here is: you don't do that in Scala.
>
> The separation of header files and definition files in C++ is an
> inheritance from how C worked long ago, where object files just did
> not have the necessary information about the function signatures, when
> there were no IDEs with pop-up helps for their definition, and, in
> fact, the header file was often pretty much all of the documentation,
> etc.
>
> This is not the case where JVM is concerned. A compiled "class" file
> contains everything necessary to interface with that class, and the
> tooling automatically generate documentation about the API from
> comments formatted in a particular way. There's no need to "hide" the
> class because no one will see the class to begin with.
>
> That said, you can separate the API into a trait and implement it with
> either a trait or a class. The benefit here is to enable multiple
> implementations of the same trait, which is rather different than the
> separation of .h and .cc.
>
> On Wed, Dec 7, 2011 at 20:03, Kevin Murphy wrote:
>> Hi
>>
>> I'm coming to Scala from C++, where I am used to defining a class
>> specification in a .h file and implementing it in a .cc file.
>> I am not sure what the canonical way to do this separation in scala
>> (I've been reading the staircase book but have not yet found
>> the answer)
>>
>> Currently I use an abstract class to define the interface, and then I
>> extend it with the implementation, as in this example:
>>
>> // specification
>> abstract class ModelTemplate(val dictionary: List[String], val
>> entity_names: List[String], val aliases: Array[List[String]]) {
>> // methods
>> def tokenize(tokens: List[String]): List[Int]
>> ...
>> }
>>
>> // implementation
>> class Model( dictionary: List[String], entity_names: List[String],
>> aliases: Array[List[String]])
>> extends ModelTemplate(dictionary, entity_names, aliases) { // code
>> smell!
>> // constructor
>> val token_prob_given_entity = ...
>> // methods
>> def tokenize(tokens: List[String]): List[Int] = {
>> ...
>> }
>> }
>>
>> This seems pretty ugly - eg. the repeated arg passing to the abstract
>> class in the line marked 'code smell'.
>>
>> Also, the computation of token_prob_given_entity is rather complex;
>> I'd rather have this code inside
>> a constructor function, rather than floating around 'naked' at the
>> beginning of the class file.
>> Is there a way to do this? (If I redefine the 'this' method with the
>> same arguments, I presumably
>> will get into an infinite loop?) Finally, is there a way to define
>> methods using C++-style
>> ClassName::method_name() syntax,
>> rather than having to embed it inside the class {} scope (which wastes
>> horizontal space)?
>>
>> Thanks!
>> Kevin
>
>
>

Yeah - same questions I had more than a decade ago when moving to Java - It
works quite nicely once you get used to it...

If you're worried about mixing implementation and 'header' or 'outline' of a
class - that's why we have the "outline" view in eclipse and javadocs...
sorry, scaladocs - that gives you the equivalent outline of the class
without the actual code complicating the view.

Don't confuse traits/interfaces versus classes with .h versus .c

Cheers,
Razie

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
Behalf Of Daniel Sobral
Sent: December-07-11 7:36 PM
To: Kevin Murphy
Cc: scala-user
Subject: Re: [scala-user] newbie question about hiding class definition from
implementation

I think the best answer here is: you don't do that in Scala.

The separation of header files and definition files in C++ is an inheritance
from how C worked long ago, where object files just did not have the
necessary information about the function signatures, when there were no IDEs
with pop-up helps for their definition, and, in fact, the header file was
often pretty much all of the documentation, etc.

This is not the case where JVM is concerned. A compiled "class" file
contains everything necessary to interface with that class, and the tooling
automatically generate documentation about the API from comments formatted
in a particular way. There's no need to "hide" the class because no one will
see the class to begin with.

That said, you can separate the API into a trait and implement it with
either a trait or a class. The benefit here is to enable multiple
implementations of the same trait, which is rather different than the
separation of .h and .cc.

On Wed, Dec 7, 2011 at 20:03, Kevin Murphy wrote:
> Hi
>
> I'm coming to Scala from C++, where I am used to defining a class
> specification in a .h file and implementing it in a .cc file.
> I am not sure what the canonical way to do this separation in scala
> (I've been reading the staircase book but have not yet found the
> answer)
>
> Currently I use an abstract class to define the interface, and then I
> extend it with the implementation, as in this example:
>
> // specification
> abstract class ModelTemplate(val dictionary: List[String], val
> entity_names: List[String], val aliases: Array[List[String]]) {
>  // methods
>   def tokenize(tokens: List[String]): List[Int]
>   ...
> }
>
> // implementation
> class Model( dictionary: List[String], entity_names: List[String],
> aliases: Array[List[String]])
>  extends ModelTemplate(dictionary, entity_names, aliases) {  // code
> smell!
>  // constructor
>  val token_prob_given_entity  = ...
>   // methods
>   def tokenize(tokens: List[String]): List[Int] = {
>    ...
>   }
>  }
>
> This seems pretty ugly - eg. the repeated arg passing to the abstract
> class in the line marked 'code smell'.
>
> Also, the computation of token_prob_given_entity is rather complex;
> I'd rather have this code inside a constructor function, rather than
> floating around 'naked' at the beginning of the class file.
> Is there a way to do this? (If I redefine the 'this' method with the
> same arguments, I presumably will get into an infinite loop?) Finally,
> is there a way to define methods using C++-style
> ClassName::method_name() syntax,
> rather than having to embed it inside the class {} scope (which wastes
> horizontal space)?
>
> Thanks!
> Kevin

--
Daniel C. Sobral

I travel to the future all the time.

Thanks for these helpful replies. As you can tell, I have not used
Java before,
nor eclipse (I'm currently using emacs...). But I like the solution
with traits (since I may have different implementations)
I'll give it a shot.

Kevin

On Dec 7, 6:41 pm, "Razvan Cojocaru"

wrote:
> Yeah - same questions I had more than a decade ago when moving to Java - It
> works quite nicely once you get used to it...
>
> If you're worried about mixing implementation and 'header' or 'outline' of a
> class - that's why we have the "outline" view in eclipse and javadocs...
> sorry, scaladocs - that gives you the equivalent outline of the class
> without the actual code complicating the view.
>
> Don't confuse traits/interfaces versus classes with .h versus .c
>
> Cheers,
> Razie
>
>
>
>
>
>
>
> -----Original Message-----
> From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
>
> Behalf Of Daniel Sobral
> Sent: December-07-11 7:36 PM
> To: Kevin Murphy
> Cc: scala-user
> Subject: Re: [scala-user] newbie question about hiding class definition from
> implementation
>
> I think the best answer here is: you don't do that in Scala.
>
> The separation of header files and definition files in C++ is an inheritance
> from how C worked long ago, where object files just did not have the
> necessary information about the function signatures, when there were no IDEs
> with pop-up helps for their definition, and, in fact, the header file was
> often pretty much all of the documentation, etc.
>
> This is not the case where JVM is concerned. A compiled "class" file
> contains everything necessary to interface with that class, and the tooling
> automatically generate documentation about the API from comments formatted
> in a particular way. There's no need to "hide" the class because no one will
> see the class to begin with.
>
> That said, you can separate the API into a trait and implement it with
> either a trait or a class. The benefit here is to enable multiple
> implementations of the same trait, which is rather different than the
> separation of .h and .cc.
>
> On Wed, Dec 7, 2011 at 20:03, Kevin Murphy wrote:
> > Hi
>
> > I'm coming to Scala from C++, where I am used to defining a class
> > specification in a .h file and implementing it in a .cc file.
> > I am not sure what the canonical way to do this separation in scala
> > (I've been reading the staircase book but have not yet found the
> > answer)
>
> > Currently I use an abstract class to define the interface, and then I
> > extend it with the implementation, as in this example:
>
> > // specification
> > abstract class ModelTemplate(val dictionary: List[String], val
> > entity_names: List[String], val aliases: Array[List[String]]) {
> >  // methods
> >   def tokenize(tokens: List[String]): List[Int]
> >   ...
> > }
>
> > // implementation
> > class Model( dictionary: List[String], entity_names: List[String],
> > aliases: Array[List[String]])
> >  extends ModelTemplate(dictionary, entity_names, aliases) {  // code
> > smell!
> >  // constructor
> >  val token_prob_given_entity  = ...
> >   // methods
> >   def tokenize(tokens: List[String]): List[Int] = {
> >    ...
> >   }
> >  }
>
> > This seems pretty ugly - eg. the repeated arg passing to the abstract
> > class in the line marked 'code smell'.
>
> > Also, the computation of token_prob_given_entity is rather complex;
> > I'd rather have this code inside a constructor function, rather than
> > floating around 'naked' at the beginning of the class file.
> > Is there a way to do this? (If I redefine the 'this' method with the
> > same arguments, I presumably will get into an infinite loop?) Finally,
> > is there a way to define methods using C++-style
> > ClassName::method_name() syntax,
> > rather than having to embed it inside the class {} scope (which wastes
> > horizontal space)?
>
> > Thanks!
> > Kevin
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.

With emacs, you should use Ensime - it does the same thing: outline, content
assist etc

https://github.com/aemoncannon/ensime

cheers,
Razie

-----Original Message-----
From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com] On
Behalf Of Kevin Murphy
Sent: December-08-11 12:56 PM
To: scala-user
Subject: [scala-user] Re: newbie question about hiding class definition from
implementation

Thanks for these helpful replies. As you can tell, I have not used Java
before, nor eclipse (I'm currently using emacs...). But I like the solution
with traits (since I may have different implementations) I'll give it a
shot.

Kevin

On Dec 7, 6:41 pm, "Razvan Cojocaru"

wrote:
> Yeah - same questions I had more than a decade ago when moving to Java
> - It works quite nicely once you get used to it...
>
> If you're worried about mixing implementation and 'header' or
> 'outline' of a class - that's why we have the "outline" view in eclipse
and javadocs...
> sorry, scaladocs - that gives you the equivalent outline of the class
> without the actual code complicating the view.
>
> Don't confuse traits/interfaces versus classes with .h versus .c
>
> Cheers,
> Razie
>
>
>
>
>
>
>
> -----Original Message-----
> From: scala-user@googlegroups.com [mailto:scala-user@googlegroups.com]
> On
>
> Behalf Of Daniel Sobral
> Sent: December-07-11 7:36 PM
> To: Kevin Murphy
> Cc: scala-user
> Subject: Re: [scala-user] newbie question about hiding class
> definition from implementation
>
> I think the best answer here is: you don't do that in Scala.
>
> The separation of header files and definition files in C++ is an
> inheritance from how C worked long ago, where object files just did
> not have the necessary information about the function signatures, when
> there were no IDEs with pop-up helps for their definition, and, in
> fact, the header file was often pretty much all of the documentation, etc.
>
> This is not the case where JVM is concerned. A compiled "class" file
> contains everything necessary to interface with that class, and the
> tooling automatically generate documentation about the API from
> comments formatted in a particular way. There's no need to "hide" the
> class because no one will see the class to begin with.
>
> That said, you can separate the API into a trait and implement it with
> either a trait or a class. The benefit here is to enable multiple
> implementations of the same trait, which is rather different than the
> separation of .h and .cc.
>
> On Wed, Dec 7, 2011 at 20:03, Kevin Murphy wrote:
> > Hi
>
> > I'm coming to Scala from C++, where I am used to defining a class
> > specification in a .h file and implementing it in a .cc file.
> > I am not sure what the canonical way to do this separation in scala
> > (I've been reading the staircase book but have not yet found the
> > answer)
>
> > Currently I use an abstract class to define the interface, and then
> > I extend it with the implementation, as in this example:
>
> > // specification
> > abstract class ModelTemplate(val dictionary: List[String], val
> > entity_names: List[String], val aliases: Array[List[String]]) {
> >  // methods
> >   def tokenize(tokens: List[String]): List[Int]
> >   ...
> > }
>
> > // implementation
> > class Model( dictionary: List[String], entity_names: List[String],
> > aliases: Array[List[String]])
> >  extends ModelTemplate(dictionary, entity_names, aliases) {  // code
> > smell!
> >  // constructor
> >  val token_prob_given_entity  = ...
> >   // methods
> >   def tokenize(tokens: List[String]): List[Int] = {
> >    ...
> >   }
> >  }
>
> > This seems pretty ugly - eg. the repeated arg passing to the
> > abstract class in the line marked 'code smell'.
>
> > Also, the computation of token_prob_given_entity is rather complex;
> > I'd rather have this code inside a constructor function, rather than
> > floating around 'naked' at the beginning of the class file.
> > Is there a way to do this? (If I redefine the 'this' method with the
> > same arguments, I presumably will get into an infinite loop?)
> > Finally, is there a way to define methods using C++-style
> > ClassName::method_name() syntax,
> > rather than having to embed it inside the class {} scope (which
> > wastes horizontal space)?
>
> > Thanks!
> > Kevin
>
> --
> Daniel C. Sobral
>
> I travel to the future all the time.