Style question: declarative vs procedural

Hi,

Marcus Downing asked:
> The second certainly reads more easily, but it has a downside: the class has
> now become mutable, something I'm doing my best to avoid. So is the syntactic
> niceness of the second worth the tradeoff of making the code procedural rather
> than declarative?
>

 
I'd say: no.
 
Is Feature a trait or a class? If it's a class, why not ask for name, required,
before and after as constructor parameters?
 
class Feature(val name: String, val required: Seq[Any])(val before: Seq[Any] =
required, val after: Seq[Any] = required)
 
(I took Any (and some other assumptions) here because I have no idea about the
type constraints of your methods.) 
 
Then you could say:
 
class Foo extends Feature("Foo", Seq(...))(Seq(...), Seq(...))
 
or
 
class Foo extends Feature(
  name = "Foo",
  required = Seq(...)
)(
  before = Seq(...),
  after = Seq(...)
)
 
or leave after as default
 
class Foo extends Feature(
  name = "Foo",
  required = Seq(...)
)(
  before = Seq(...) 
)
 
I hope that helped a bit.
 
Kind regards
Andreas 

if you want to keep the syntax and the immutability:

class Foo extends Feature {//feature has an abstract val called meta
val meta = Meta(
name = "i am sonic",
requires = List(a,b),
before = a,
after = b)
}

class Meta(name, require, before, after) {
}

-------- Original-Nachricht --------
> Datum: Tue, 13 Dec 2011 01:54:32 -0800 (PST)
> Von: Marcus Downing
> An: scala-user@googlegroups.com
> Betreff: [scala-user] Style question: declarative vs procedural

> I'm designing a library and need
> to
> provide a way for implementing classes to state certain facts about
> themselves. At the moment this looks like:
>
> class Foo extends Feature {
> val name = "Foo"
> def require = List(Bar, Qux)
> override def before = List(Qux)
> override def after = List(Bar)
> }
>
>
> An alternative is to declare these things using methods:
>
> class Foo extends Feature {
> val name = "Foo"
> require(Bar, Qux)
> before Qux
> after Bar
> }
>
>
> The second certainly reads more easily, but it has a downside: the class
> has now become mutable, something I'm doing my best to avoid. So is the
> syntactic niceness of the second worth the tradeoff of making the code
> procedural rather than declarative?

I'm designing a library and need to provide a way for implementing classes to state certain facts about themselves. At the moment this looks like:

class Foo extends Feature {  val name = "Foo"   def require = List(Bar, Qux)  override def before = List(Qux)  override def after = List(Bar) }

An alternative is to declare these things using methods:

class Foo extends Feature {  val name = "Foo"  require(Bar, Qux)   before Qux  after Bar}

The second certainly reads more easily, but it has a downside: the class has now become mutable, something I'm doing my best to avoid. So is the syntactic niceness of the second worth the tradeoff of making the code procedural rather than declarative?

No.

I'm designing a library and need to provide a way for implementing classes to state certain facts about themselves. At the moment this looks like:

class Foo extends Feature {  val name = "Foo"   def require = List(Bar, Qux)  override def before = List(Qux)  override def after = List(Bar) }

An alternative is to declare these things using methods:

class Foo extends Feature {  val name = "Foo"  require(Bar, Qux)   before Qux  after Bar}

The second certainly reads more easily, but it has a downside: the class has now become mutable, something I'm doing my best to avoid. So is the syntactic niceness of the second worth the tradeoff of making the code procedural rather than declarative?

I'm designing a library and need to provide a way for implementing classes to state certain facts about themselves. At the moment this looks like:

class Foo extends Feature {  val name = "Foo"   def require = List(Bar, Qux)  override def before = List(Qux)  override def after = List(Bar) }

An alternative is to declare these things using methods:

class Foo extends Feature {  val name = "Foo"  require(Bar, Qux)   before Qux  after Bar}

The second certainly reads more easily, but it has a downside: the class has now become mutable, something I'm doing my best to avoid. So is the syntactic niceness of the second worth the tradeoff of making the code procedural rather than declarative?

Hi,

isn't that pretty much exactly like my first answer in this thread? :)

Kind regards
Andreas

Josh Suereth wrote:

> What about:
>
> abstract class Feature(val name: String, val require: Seq[Feature] = Seq.empty, val before: Seq[Feature] = Seq.empty, val after: Seq[Feature] = Seq.empty) {}
>
> class Foo extends Feature(
> name = "Foo",
> require = Seq(Bar, Quz)
> // No more needed if I don't need different values.
> ) {
>
> // Normal overrides here....
> }
>
> On Tue, Dec 13, 2011 at 4:54 AM, Marcus Downing wrote:
> I'm designing a library and need to provide a way for implementing classes to state certain facts about themselves. At the moment this looks like:
>
> class Foo extends Feature {
> val name = "Foo"
> def require = List(Bar, Qux)
> override def before = List(Qux)
> override def after = List(Bar)
> }
>
> An alternative is to declare these things using methods:
>
> class Foo extends Feature {
> val name = "Foo"
> require(Bar, Qux)
> before Qux
> after Bar
> }
>
> The second certainly reads more easily, but it has a downside: the class has now become mutable, something I'm doing my best to avoid. So is the syntactic niceness of the second worth the tradeoff of making the code procedural rather than declarative?
>

Hi,

isn't that pretty much exactly like my first answer in this thread? :)

Kind regards
Andreas

Josh Suereth wrote:

> What about:
>
> abstract class Feature(val name: String, val require: Seq[Feature] = Seq.empty, val before: Seq[Feature] = Seq.empty, val after: Seq[Feature] = Seq.empty) {}
>
> class Foo extends Feature(
>   name = "Foo",
>   require = Seq(Bar, Quz)
>   // No more needed if I don't need different values.
> ) {
>
>   // Normal overrides here....
> }
>
> On Tue, Dec 13, 2011 at 4:54 AM, Marcus Downing <marcus.downing@gmail.com> wrote:
> I'm designing a library and need to provide a way for implementing classes to state certain facts about themselves. At the moment this looks like:
>
> class Foo extends Feature {
>   val name = "Foo"
>   def require = List(Bar, Qux)
>   override def before = List(Qux)
>   override def after = List(Bar)
> }
>
> An alternative is to declare these things using methods:
>
> class Foo extends Feature {
>   val name = "Foo"
>   require(Bar, Qux)
>   before Qux
>   after Bar
> }
>
> The second certainly reads more easily, but it has a downside: the class has now become mutable, something I'm doing my best to avoid. So is the syntactic niceness of the second worth the tradeoff of making the code procedural rather than declarative?
>

class Foo extends Feature(  name = "Foo",  required = List(...))(  before = List(...) )

class Foo extends Feature(  name = "Foo",  required = List(...),  before = List(...) )

Hi,

the default arguments of the second parameter list can use the ones from the
first, e.g. the default value for "before" is whatever was given to "required"
in my example. I just wanted to show you that this is possible, in case you'd
need it.
 
Kind regards
Andreas 
 

Marcus Downing wrote:

> Named, default arguments does look like a nice way of doing it, that has
> reasonable syntax as well as immutability. Feature is currently a trait, but
> can be a class for the sake of getting this configuration right. 
> Why the split parameter list though?
>  
>
> > class Foo extends Feature(
> >   name = "Foo",
> >   required = List(...)
> > )(
> >   before = List(...) 
> > )
> >
 
> vs
>  
>
> > class Foo extends Feature(
> >
> >   name = "Foo",
> >
> >   required = List(...),
> >
> >   before = List(...) 
> >
> > )
> >
> >