Search Results

Search found 119 results on 5 pages for 'trait'.

Page 3/5 | < Previous Page | 1 2 3 4 5  | Next Page >

• scala: defining a tratit and referencing the corresponding companion object

  - by opensas

  I'm trying to define a trait that uses the corresponding companion object, that is, the componion object of the class using the trait. for example, I have: :paste class Parent { def callMyCompanion = print(Parent.salute) } object Parent { def salute = "Hello from Parent companion object" } class Child extends Parent { } object Child { def salute = "Hello from Child companion object" } And then I create a parent object: scala> val p = new Parent() p: Parent = Parent@1ecf669 scala> p.callMyCompanion Hello from Parent companion object But with a child: scala> val c = new Child() c: Child = Child@4fd986 scala> c.callMyCompanion Hello from Parent companion object I'd like to get: Hello from Child companion object How can I achieve it???

  Read the article

• Possible to not use ID field but another column name? in Lift

  - by bstevens90

  I am connected to a oracle database from a scala/lift webapp. I have been able to successfully pull information from the database as I wished but am having one issue. For each table I want to access I am required to add an ID field so that the app will work with the trait IdPK. What mapper class or trait can I use to override this? I have been trying to find one but been unable to locate it. Figured people have not always had an ID field on every table they make that is just called ID... class DN_REC extends LongKeyedMapper[DN_REC] with IdPK { def getSingleton = DN_REC object dn_rec_id extends MappedInt(this){ } This is what I am talking about. I would like to use the dn_rec_id as my primary key as it is on the table. Thanks

  Read the article

• Icons of external devices not appearing on Desktop in 12.04

  - by harisibrahimkv

  In 10.04 and all, when a pen drive or as for that matter, when any external devices are connected, their icons are shown on the desktop and nautilus pops up automatically too. But in my 12.04 Gnome classic, when I connect an external device, nothing happens. I have to open nautilus manually and then click on the icon in the left panel to access the folder of the device. Is there any way to rectify this and restore the old trait as in 10.04?

  Read the article

• The Courage to Screw Up: Why DIY Is Good for You

  <b>Huffington Post:</b> "And while no two DIYers are alike, in general they're an upbeat and friendly group that shares a special trait: the courage to screw up."

  Read the article

• Macro access to members of object where macro is defined

  - by Marc Grue

  Say I have a trait Foo that I instantiate with an initial value val foo = new Foo(6) // class Foo(i: Int) and I later call a second method that in turn calls myMacro foo.secondMethod(7) // def secondMethod(j: Int) = macro myMacro then, how can myMacro find out what my initial value of i (6) is? I didn't succeed with normal compilation reflection using c.prefix, c.eval(...) etc but instead found a 2-project solution: Project B: object CompilationB { def resultB(x: Int, y: Int) = macro resultB_impl def resultB_impl(c: Context)(x: c.Expr[Int], y: c.Expr[Int]) = c.universe.reify(x.splice * y.splice) } Project A (depends on project B): trait Foo { val i: Int // Pass through `i` to compilation B: def apply(y: Int) = CompilationB.resultB(i, y) } object CompilationA { def makeFoo(x: Int): Foo = macro makeFoo_impl def makeFoo_impl(c: Context)(x: c.Expr[Int]): c.Expr[Foo] = c.universe.reify(new Foo {val i = x.splice}) } We can create a Foo and set the i value either with normal instantiation or with a macro like makeFoo. The second approach allows us to customize a Foo at compile time in the first compilation and then in the second compilation further customize its response to input (i in this case)! In some way we get "meta-meta" capabilities (or "pataphysic"-capabilities ;-) Normally we would need to have foo in scope to introspect i (with for instance c.eval(...)). But by saving the i value inside the Foo object we can access it anytime and we could instantiate Foo anywhere: object Test extends App { import CompilationA._ // Normal instantiation val foo1 = new Foo {val i = 7} val r1 = foo1(6) // Macro instantiation val foo2 = makeFoo(7) val r2 = foo2(6) // "Curried" invocation val r3 = makeFoo(6)(7) println(s"Result 1 2 3: $r1 $r2 $r3") assert((r1, r2, r3) ==(42, 42, 42)) } My question Can I find i inside my example macros without this double compilation hackery?

  Read the article

• Accessing type members outside the class in Scala

  - by Pekka Mattila

  Hi, I am trying to understand type members in Scala. I wrote a simple example that tries to explain my question. First, I created two classes for types: class BaseclassForTypes class OwnType extends BaseclassForTypes Then, I defined an abstract type member in trait and then defined the type member in a concerete class: trait ScalaTypesTest { type T <: BaseclassForTypes def returnType: T } class ScalaTypesTestImpl extends ScalaTypesTest { type T = OwnType override def returnType: T = { new T } } Then, I want to access the type member (yes, the type is not needed here, but this explains my question). Both examples work. Solution 1. Declaring the type, but the problem here is that it does not use the type member and the type information is duplicated (caller and callee). val typeTest = new ScalaTypesTestImpl val typeObject:OwnType = typeTest.returnType // declare the type second time here true must beTrue Solution 2. Initializing the class and using the type through the object. I don't like this, since the class needs to be initialized val typeTest = new ScalaTypesTestImpl val typeObject:typeTest.T = typeTest.returnType // through an instance true must beTrue So, is there a better way of doing this or are type members meant to be used only with the internal implementation of a class?

  Read the article

• Closures and universal quantification

  - by Apocalisp

  I've been trying to work out how to implement Church-encoded data types in Scala. It seems that it requires rank-n types since you would need a first-class const function of type forAll a. a -> (forAll b. b -> b). However, I was able to encode pairs thusly: import scalaz._ trait Compose[F[_],G[_]] { type Apply = F[G[A]] } trait Closure[F[_],G[_]] { def apply[B](f: F[B]): G[B] } def pair[A,B](a: A, b: B) = new Closure[Compose[PartialApply1Of2[Function1,A]#Apply, PartialApply1Of2[Function1,B]#Apply]#Apply, Identity] { def apply[C](f: A => B => C) = f(a)(b) } For lists, I was able to get encode cons: def cons[A](x: A) = { type T[B] = B => (A => B => B) => B new Closure[T,T] { def apply[B](xs: T[B]) = (b: B) => (f: A => B => B) => f(x)(xs(b)(f)) } } However, the empty list is more problematic and I've not been able to get the Scala compiler to unify the types. Can you define nil, so that, given the definition above, the following compiles? cons(1)(cons(2)(cons(3)(nil)))

  Read the article

• Case class copy() method abstraction.

  - by Joa Ebert

  I would like to know if it is possible to abstract the copy method of case classes. Basically I have something like sealed trait Op and then something like case class Push(value: Int) extends Op and case class Pop() extends Op. The first problem: A case class without arguments/members does not define a copy method. You can try this in the REPL. scala> case class Foo() defined class Foo scala> Foo().copy() <console>:8: error: value copy is not a member of Foo Foo().copy() ^ scala> case class Foo(x: Int) defined class Foo scala> Foo(0).copy() res1: Foo = Foo(0) Is there a reason why the compiler makes this exception? I think it is rather unituitive and I would expect every case class to define a copy method. The second problem: I have a method def ops: List[Op] and I would like to copy all ops like ops map { _.copy() }. How would I define the copy method in the Op trait? I get a "too many arguments" error if I say def copy(): this.type. However, since all copy() methods have only optional arguments: why is this incorrect? And, how do I do that correct? By making another method named def clone(): this.type and write everywhere def clone() = copy() for all the case classes? I hope not.

  Read the article

• Overloading generic implicit conversions

  - by raichoo

  Hi I'm having a little scala (version 2.8.0RC1) problem with implicit conversions. Whenever importing more than one implicit conversion the first one gets shadowed. Here is the code where the problem shows up: // containers class Maybe[T] case class Nothing[T]() extends Maybe[T] case class Just[T](value: T) extends Maybe[T] case class Value[T](value: T) trait Monad[C[_]] { def >>=[A, B](a: C[A], f: A => C[B]): C[B] def pure[A](a: A): C[A] } // implicit converter trait Extender[C[_]] { class Wrapper[A](c: C[A]) { def >>=[B](f: A => C[B])(implicit m: Monad[C]): C[B] = { m >>= (c, f) } def >>[B](b: C[B])(implicit m: Monad[C]): C[B] = { m >>= (c, { (x: A) => b } ) } } implicit def extendToMonad[A](c: C[A]) = new Wrapper[A](c) } // instance maybe object maybemonad extends Extender[Maybe] { implicit object MaybeMonad extends Monad[Maybe] { override def >>=[A, B](a: Maybe[A], f: A => Maybe[B]): Maybe[B] = { a match { case Just(x) => f(x) case Nothing() => Nothing() } } override def pure[A](a: A): Maybe[A] = Just(a) } } // instance value object identitymonad extends Extender[Value] { implicit object IdentityMonad extends Monad[Value] { override def >>=[A, B](a: Value[A], f: A => Value[B]): Value[B] = { a match { case Value(x) => f(x) } } override def pure[A](a: A): Value[A] = Value(a) } } import maybemonad._ //import identitymonad._ object Main { def main(args: Array[String]): Unit = { println(Just(1) >>= { (x: Int) => MaybeMonad.pure(x) }) } } When uncommenting the second import statement everything goes wrong since the first "extendToMonad" is shadowed. However, this one works: object Main { implicit def foo(a: Int) = new { def foobar(): Unit = { println("Foobar") } } implicit def foo(a: String) = new { def foobar(): Unit = { println(a) } } def main(args: Array[String]): Unit = { 1 foobar() "bla" foobar() } } So, where is the catch? What am I missing? Regards, raichoo

  Read the article

• How do I implement a collection in Scala 2.8?

  - by Simon Reinhardt

  In trying to write an API I'm struggling with Scala's collections in 2.8(.0-beta1). Basically what I need is to write something that: adds functionality to immutable sets of a certain type where all methods like filter and map return a collection of the same type without having to override everything (which is why I went for 2.8 in the first place) where all collections you gain through those methods are constructed with the same parameters the original collection had (similar to how SortedSet hands through an ordering via implicits) which is still a trait in itself, independent of any set implementations. Additionally I want to define a default implementation, for example based on a HashSet. The companion object of the trait might use this default implementation. I'm not sure yet if I need the full power of builder factories to map my collection type to other collection types. I read the paper on the redesign of the collections API but it seems like things have changed a bit since then and I'm missing some details in there. I've also digged through the collections source code but I'm not sure it's very consistent yet. Ideally what I'd like to see is either a hands-on tutorial that tells me step-by-step just the bits that I need or an extensive description of all the details so I can judge myself which bits I need. I liked the chapter on object equality in "Programming in Scala". :-) But I appreciate any pointers to documentation or examples that help me understand the new collections design better.

  Read the article

• Interesting Scala typing solution, doesn't work in 2.7.7?

  - by djc

  I'm trying to build some image algebra code that can work with images (basically a linear pixel buffer + dimensions) that have different types for the pixel. To get this to work, I've defined a parametrized Pixel trait with a few methods that should be able to get used with any Pixel subclass. (For now, I'm only interested in operations that work on the same Pixel type.) Here it is: trait Pixel[T <: Pixel[T]] { def mul(v: Double): T def max(v: T): T def div(v: Double): T def div(v: T): T } Now I define a single Pixel type that has storage based on three doubles (basically RGB 0.0-1.0), I've called it TripleDoublePixel: class TripleDoublePixel(v: Array[Double]) extends Pixel[TripleDoublePixel] { var data: Array[Double] = v def this() = this(Array(0.0, 0.0, 0.0)) def toString(): String = { "(" + data(0) + ", " + data(1) + ", " + data(2) + ")" } def increment(v: TripleDoublePixel) { data(0) += v.data(0) data(1) += v.data(1) data(2) += v.data(2) } def mul(v: Double): TripleDoublePixel = { new TripleDoublePixel(data.map(x => x * v)) } def div(v: Double): TripleDoublePixel = { new TripleDoublePixel(data.map(x => x / v)) } def div(v: TripleDoublePixel): TripleDoublePixel = { var tmp = new Array[Double](3) tmp(0) = data(0) / v.data(0) tmp(1) = data(1) / v.data(1) tmp(2) = data(2) / v.data(2) new TripleDoublePixel(tmp) } def max(v: TripleDoublePixel): TripleDoublePixel = { val lv = data(0) * data(0) + data(1) * data(1) + data(2) * data(2) val vv = v.data(0) * v.data(0) + v.data(1) * v.data(1) + v.data(2) * v.data(2) if (lv > vv) (this) else v } } Now I want to write code to use this, that doesn't have to know what type the pixels are. For example: def idiv[T](a: Image[T], b: Image[T]) { for (i <- 0 until a.data.size) { a.data(i) = a.data(i).div(b.data(i)) } } Unfortunately, this doesn't compile: (fragment of lindet-gen.scala):145: error: value div is not a member of T a.data(i) = a.data(i).div(b.data(i)) I was told in #scala that this worked for someone else, but that was on 2.8. I've tried to get 2.8-rc1 going, but it doesn't compile for me. Is there any way to get this to work in 2.7.7?

  Read the article

• scala 2.8 CanBuildFrom

  - by oxbow_lakes

  Following on from another question I asked, I wanted to understand a bit more about the Scala method TraversableLike[A].map whose signature is as follows: def map[B, That](f: A => B)(implicit bf: CanBuildFrom[Repr, B, That]): That Notice a few things about this method: it takes a function turning each A in the traversable into a B it returns That and takes an implicit argument of type CanBuildFrom[Repr, B, That] I can call this as follows: > val s: Set[Int] = List("Paris", "London").map(_.length) s: Set[Int] Set(5,6) What I cannot quite grasp is how the fact that That is bound to B (i.e. it is some collection of B's) is being enforced by the compiler. The type parameters look to be independent in both the signature above and in the signature of the trait CanBuildFrom itself: trait CanBuildFrom[-From, -Elem, +To] How is the scala compiler ensuring that That cannot be forced into something which does not make sense? > val s: Set[String] = List("Paris", "London").map(_.length) //will not compile EDIT - this question of course boils down to: How does the compiler decide what implicit CanBuildFrom objects are in scope for the call?

  Read the article

• La rubrique Conception devient « ALM » sur Developpez.com, et couvre désormais toutes les phases du cycle de vie des applications

  Bonjour, L'équipe de rédaction a l'honneur de vous annoncer une importante amélioration au sommet des rubriques de Developpez.com. Pour lui donner plus d'importance et un plus grand impact, la méga-rubrique Conception devient « ALM » (Application lifecycle management). Ce sigle ne vous dit rien ? C'est pourtant l'unique terme consacré par les professionnels de l'informatique pour désigner tout ce qui a trait au cycle de vie des applications, à savoir : analyse des exigences, rédaction de cahier des charges, architecture, conception, méthodes, tests, gestion des mises en production, etc. Il n'existe malheureusement pas d'équivalent en français et Conception est un terme bien réducteur que nous ne p...

  Read the article

• Le futur du jeu vidéo occupera-t-il tout votre salon ? Oui, d'après Microsoft qui a déposé un brevet très intéressant

  La 2D, puis la 3D, des graphismes quasiment photoréalistes, la reconnaissance de mouvements, tout cela tend dans une même direction : rendre le jeu vidéo encore plus immersif. Une demande de brevet déposée par Microsoft montre que l'entreprise a décidé d'aller encore plus loin. Selon le site Patentbolt, qui suit et piste les brevets ayant trait à la high-tech, Microsoft vient de se voir accorder un brevet pour « un environnement d'affichage immersif qui est proposé à l'utilisateur humain par projection d'une image périphérique sur les surfaces de son environnement. Les images périphériques servent d'extension aux images affichées sur l'écran principal. ...

  Read the article

• How does one manage perfectionism in programming? [closed]

  - by Craige

  Possible Duplicate: Where do you draw the line for your perfectionism? First of - I'm a perfectionist; I know and accept this. Problem is, this really is a counter-productive programming trait. It's a never-ending endeavor that hinders productivity as you find a new and "better" way you should be doing something. To me, if you're not doing it right, then don't do it at all. How does one manage such a characteristic in programming?

  Read the article

• Deals Well With Ambiguity

  A while ago I was talking with my manager at the time about traits that we value in a Program Manager. He related an anecdote about an interview he gave where it became clear that the candidate did not deal well with ambiguity. This is an important trait for nearly every job, but especially for PMs as projects can often change on a dime and its important understand how to make progress amidst ambiguity and eventually drive towards resolving ambiguity. Lately, Ive been asking myself the question,...Did you know that DotNetSlackers also publishes .net articles written by top known .net Authors? We already have over 80 articles in several categories including Silverlight. Take a look: here.

  Read the article

• Does Scala's BigDecimal violate the equals/hashCode contract?

  - by oxbow_lakes

  As the Ordered trait demands, the equals method on Scala's BigDecimal class is consistent with the ordering. However, the hashcode is simply taken from the wrapped java.math.BigDecimal and is therefore inconsistent with equals. object DecTest { def main(args: Array[String]) { val d1 = BigDecimal("2") val d2 = BigDecimal("2.00") println(d1 == d2) //prints true println(d1.hashCode == d2.hashCode) //prints false } } I can't find any reference to this being a known issue. Am I missing something?

  Read the article

• Sealed alternative

  - by Jeriho

  According to "Programming in scala" a sealed class cannot have any new subclasses added except the ones in the same ?le. In the same book was described a way to enumerate classes that can extend class or trait in multiple files. I have forgotten it and can't find again. Remind it to me, please.

  Read the article

• Scala traits and implicit conversion confusion

  - by pr1001

  The following lines work when I enter them by hand on the Scala REPL (2.7.7): trait myTrait { override def toString = "something" } implicit def myTraitToString(input: myTrait): String = input.toString object myObject extends myTrait val s: String = myObject However, if I try to compile file with it I get the following error: [error] myTrait.scala:37: expected start of definition [error] implicit def myTraitToString(input: myTrait): String = input.toString [error] ^ Why? Thanks!

  Read the article

• Parser that accepts Scala Identifiers?

  - by Mirko Stocker

  I was wondering whether the standard Scala parser combinators contain a parser that accepts the same identifiers that the Scala language itself also accepts (as specified in the Scala Language Specification, Section 1.1). The StdTokenParsers trait has an ident parser, but it rejects identifiers like empty_?. (If there is indeed no such parser, I could also just instantiate the Scala parser itself, but that wouldn't be as lightweight anymore.)

  Read the article

• how to define a structural type that refers to itself?

  - by IttayD

  I want to create a method sum that I can call on different types, specifically sum(1,2). def sum[A](a1: A, a2: A) = a1 + a2 This fails because the compiler can't tell if A has a method '+' I tried to define a structural type: type Addable = {def +(a: Addable)} This fails because of an illegal cyclic reference How can I achieve this in a type safe way without requiring A to extend a specific trait?

  Read the article

• automatic xml conversion in scala

  - by Jeff Bowman

  Let's say I have the following class: class Person(val firstName:String, val lastName:String) Is there an automatic way to generate xml from this class without having to hand create a toXml() method? Ideally the output would be something like: <Person <firstNameJohn</firstName <lastNameSmith</lastName </Person It seems like there should be a way to do this without having to write all that out manually. Perhaps there is a trait I haven't found yet?

  Read the article

• implementing java interface with scala class - type issue

  - by paintcan

  Why on earth won't this compile? Scala 2.8.0RC3: Java public interface X { void logClick(long ts, int cId, String s, double c); } Scala class Y extends X { def logClick(ts: Long, cId: Int,sid: java.lang.String,c: Double) : Unit = { ... } } Error class Y needs to be abstract, since method logClick in trait X of type (ts: Long,cId: Int,s: java.lang.String,c: Double)Unit is not defined

  Read the article

• Is scala's cake pattern possible with parametrized components?

  - by Nicolas

  Parametrized components work well with the cake pattern as long as you are only interested in a unique component for each typed component's, example: trait AComponent[T] { val a:A[T] class A[T](implicit mf:Manifest[T]) { println(mf) } } class App extends AComponent[Int] { val a = new A[Int]() } new App Now my application requires me to inject an A[Int] and an A[String], obviously scala's type system doesn't allow me to extends AComponent twice. What is the common practice in this situation ?

  Read the article

• The Incremental Architect&acute;s Napkin - #1 - It&acute;s about the money, stupid

  - by Ralf Westphal

  Originally posted on: http://geekswithblogs.net/theArchitectsNapkin/archive/2014/05/24/the-incremental-architectacutes-napkin---1---itacutes-about-the.aspx Software development is an economic endeavor. A customer is only willing to pay for value. What makes a software valuable is required to become a trait of the software. We as software developers thus need to understand and then find a way to implement requirements. Whether or in how far a customer really can know beforehand what´s going to be valuable for him/her in the end is a topic of constant debate. Some aspects of the requirements might be less foggy than others. Sometimes the customer does not know what he/she wants. Sometimes he/she´s certain to want something - but then is not happy when that´s delivered. Nevertheless requirements exist. And developers will only be paid if they deliver value. So we better focus on doing that. Although is might sound trivial I think it´s important to state the corollary: We need to be able to trace anything we do as developers back to some requirement. You decide to use Go as the implementation language? Well, what´s the customer´s requirement this decision is linked to? You decide to use WPF as the GUI technology? What´s the customer´s requirement? You decide in favor of a layered architecture? What´s the customer´s requirement? You decide to put code in three classes instead of just one? What´s the customer´s requirement behind that? You decide to use MongoDB over MySql? What´s the customer´s requirement behind that? etc. I´m not saying any of these decisions are wrong. I´m just saying whatever you decide be clear about the requirement that´s driving your decision. You have to be able to answer the question: Why do you think will X deliver more value to the customer than the alternatives? Customers are not interested in romantic ideals of hard working, good willing, quality focused craftsmen. They don´t care how and why you work - as long as what you deliver fulfills their needs. They want to trust you to recognize this as your top priority - and then deliver. That´s all. Fundamental aspects of requirements If you´re like me you´re probably not used to such scrutinization. You want to be trusted as a professional developer - and decide quite a few things following your gut feeling. Or by relying on “established practices”. That´s ok in general and most of the time - but still… I think we should be more conscious about our decisions. Which would make us more responsible, even more professional. But without further guidance it´s hard to reason about many of the myriad decisions we´ve to make over the course of a software project. What I found helpful in this situation is structuring requirements into fundamental aspects. Instead of one large heap of requirements then there are smaller blobs. With them it´s easier to check if a decisions falls in their scope. Sure, every project has it´s very own requirements. But all of them belong to just three different major categories, I think. Any requirement either pertains to functionality, non-functional aspects or sustainability. For short I call those aspects: Functionality, because such requirements describe which transformations a software should offer. For example: A calculator software should be able to add and multiply real numbers. An auction website should enable you to set up an auction anytime or to find auctions to bid for. Quality, because such requirements describe how functionality is supposed to work, e.g. fast or secure. For example: A calculator should be able to calculate the sinus of a value much faster than you could in your head. An auction website should accept bids from millions of users. Security of Investment, because functionality and quality need not just be delivered in any way. It´s important to the customer to get them quickly - and not only today but over the course of several years. This aspect introduces time into the “requrements equation”. Security of Investments (SoI) sure is a non-functional requirement. But I think it´s important to not subsume it under the Quality (Q) aspect. That´s because SoI has quite special properties. For one, SoI for software means something completely different from what it means for hardware. If you buy hardware (a car, a hair blower) you find that a worthwhile investment, if the hardware does not change it´s functionality or quality over time. A car still running smoothly with hardly any rust spots after 10 years of daily usage would be a very secure investment. So for hardware (or material products, if you like) “unchangeability” (in the face of usage) is desirable. With software you want the contrary. Software that cannot be changed is a waste. SoI for software means “changeability”. You want to be sure that the software you buy/order today can be changed, adapted, improved over an unforseeable number of years so as fit changes in its usage environment. But that´s not the only reason why the SoI aspect is special. On top of changeability[1] (or evolvability) comes immeasurability. Evolvability cannot readily be measured by counting something. Whether the changeability is as high as the customer wants it, cannot be determined by looking at metrics like Lines of Code or Cyclomatic Complexity or Afferent Coupling. They may give a hint… but they are far, far from precise. That´s because of the nature of changeability. It´s different from performance or scalability. Also it´s because a customer cannot tell upfront, “how much” evolvability he/she wants. Whether requirements regarding Functionality (F) and Q have been met, a customer can tell you very quickly and very precisely. A calculation is missing, the calculation takes too long, the calculation time degrades with increased load, the calculation is accessible to the wrong users etc. That´s all very or at least comparatively easy to determine. But changeability… That´s a whole different thing. Nevertheless over time the customer will develop a feedling if changeability is good enough or degrading. He/she just has to check the development of the frequency of “WTF”s from developers ;-) F and Q are “timeless” requirement categories. Customers want us to deliver on them now. Just focusing on the now, though, is rarely beneficial in the long run. So SoI adds a counterweight to the requirements picture. Customers want SoI - whether they know it or not, whether they state if explicitly or not. In closing A customer´s requirements are not monolithic. They are not all made the same. Rather they fall into different categories. We as developers need to recognize these categories when confronted with some requirement - and take them into account. Only then can we make true professional decisions, i.e. conscious and responsible ones. I call this fundamental trait of software “changeability” and not “flexibility” to distinguish to whom it´s a concern. “Flexibility” to me means, software as is can easily be adapted to a change in its environment, e.g. by tweaking some config data or adding a library which gets picked up by a plug-in engine. “Flexibiltiy” thus is a matter of some user. “Changeability”, on the other hand, to me means, software can easily be changed in its structure to adapt it to new requirements. That´s a matter of the software developer. ?

  Read the article

< Previous Page | 1 2 3 4 5  | Next Page >