This page is no longer maintained — Please continue to the home page at www.scala-lang.org

is there a term for "immutable objects with functions"?

2 replies
Tim P
Joined: 2011-07-28,
User offline. Last seen 1 year 4 weeks ago.
HiI'm doing a paper where I need to contrast a mixed-integer linear programming formulation of an optimisation problem with one that is based on immutable objects "manipulated" (i.e. transformed) by functions. Is there a term for this hybrid approach? I don't want to call it OOP because we're not using methods to change the objects, but the fact that the objects (or entities) are "parcels" of data is crucial to the distinction - because I'm claiming that the entity-based formulation provides a clearer expression of the problem to non-mathematicians (ubiquitous language and all that sort of stuff from DDD).Since this is the way that lots of scala software appears to be evolving (as we OOP guys become infected with functional zeal) have we a decent name for this paradigm? If so, any citable references (you know how it's true if you can cite it :-) )
Tim
Kevin Wright 2
Joined: 2010-05-30,
User offline. Last seen 26 weeks 4 days ago.
Re: is there a term for "immutable objects with functions"?
I just call it "object oriented programming".  There's nothing about the paradigm that demands mutability!

We still have objects, they still have methods that can work through encapsulated information (possibly by returning an updated form of the object they exist on, such as the :+ method on a seq), they can still be passed around as first class entities.


On 25 October 2011 21:47, Tim Pigden <tim [dot] pigden [at] optrak [dot] com> wrote:
HiI'm doing a paper where I need to contrast a mixed-integer linear programming formulation of an optimisation problem with one that is based on immutable objects "manipulated" (i.e. transformed) by functions. Is there a term for this hybrid approach? I don't want to call it OOP because we're not using methods to change the objects, but the fact that the objects (or entities) are "parcels" of data is crucial to the distinction - because I'm claiming that the entity-based formulation provides a clearer expression of the problem to non-mathematicians (ubiquitous language and all that sort of stuff from DDD). Since this is the way that lots of scala software appears to be evolving (as we OOP guys become infected with functional zeal) have we a decent name for this paradigm? If so, any citable references (you know how it's true if you can cite it :-) )
Tim


H-star Development
Joined: 2010-04-14,
User offline. Last seen 2 years 26 weeks ago.
Re: is there a term for "immutable objects with functions"?
side effect free oop
Am 25.10.2011 22:53, schrieb Kevin Wright:
CABHxxC1V20YsXRyX_nFFxAxjUxSp3326a-NDk1ogCTAmQg6mFg [at] mail [dot] gmail [dot] com" type="cite">I just call it "object oriented programming".  There's nothing about the paradigm that demands mutability!

We still have objects, they still have methods that can work through encapsulated information (possibly by returning an updated form of the object they exist on, such as the :+ method on a seq), they can still be passed around as first class entities.


On 25 October 2011 21:47, Tim Pigden <tim [dot] pigden [at] optrak [dot] com" rel="nofollow">tim [dot] pigden [at] optrak [dot] com> wrote:
Hi I'm doing a paper where I need to contrast a mixed-integer linear programming formulation of an optimisation problem with one that is based on immutable objects "manipulated" (i.e. transformed) by functions. Is there a term for this hybrid approach? I don't want to call it OOP because we're not using methods to change the objects, but the fact that the objects (or entities) are "parcels" of data is crucial to the distinction - because I'm claiming that the entity-based formulation provides a clearer expression of the problem to non-mathematicians (ubiquitous language and all that sort of stuff from DDD). Since this is the way that lots of scala software appears to be evolving (as we OOP guys become infected with functional zeal) have we a decent name for this paradigm? If so, any citable references (you know how it's true if you can cite it :-) )
Tim



Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland