New CodePlex project: a simple Undo/Redo framework

re: New CodePlex project: a simple Undo/Redo framework

JimK — Wed, 01 Jul 2009 12:20:26 GMT

It's useful for me,

can you put a demo project to the source code?or some unit tests,just for understand how to use it

re: New CodePlex project: a simple Undo/Redo framework

Anandarajeshwaran — Thu, 02 Jul 2009 12:09:37 GMT

Hi,

I am looking for a application framework/architecture for winforms applications. I am planning to develop very small applications like customer address management/to do list etc., mostly they will be using access as back end and single user only.the framework/architecture i see in msdn suits for enterprise level development not for an hobbyist. can u guide on this perspective

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Thu, 02 Jul 2009 22:24:18 GMT

Hi JimK,

I added a couple of demo projects:

http://blogs.msdn.com/kirillosenkov/archive/2009/07/02/samples-for-the-undo-framework.aspx

Anandarajeshwaran:

to be frank, I'm unaware of a good guidance for creating small scale WinForms client applications. Use your common sense, general design guidelines, design patterns and you'll be successful.

re: New CodePlex project: a simple Undo/Redo framework

Stefan — Sat, 04 Jul 2009 03:16:49 GMT

There is no need for undo-redo framework.

All you need is purely functional

data structures which provide

multiple versions with efficient

representation and update operatations.

You history is then a list of

(action-name, current-version).

Design patterns are the wrong way

to attack many problems.

re: New CodePlex project: a simple Undo/Redo framework

David Myers — Mon, 06 Jul 2009 11:17:23 GMT

I agree with Stefan...I am afraid you have just suffered death by patterns.

Using the command pattern is a good start but not in the way you used it. A much better approach would be to use two stacks. The first stack contains the operations to be executed, whilst the second has undo operations. When adding a command to be executed, the undo method is also specified. Initially the undo stack would be empty whilst the execution stack contains the operations to be executed.

When a command is executed sucessfully the undo operation is added to the undo stack. In the event of an exception, all methods in the undo stack would be executed ensuring the undo is in the same order as the normal execution.

Of course to make this work you need to ensure that you have undo operations where required and that the undo methods work in the same order as the normal execution.

I have some sample code if anyone is interested.

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Mon, 06 Jul 2009 22:12:37 GMT

Stefan:

I agree, immutability is the way to go. Undoing then is just bringing back a snapshot of your data-structure from back then.

However there are a couple of points to keep in mind.

1. There are existing projects out there that are not built in a functional way. A LOT of them. And they need guidance on how to implement Undo in their mutable world. I've seen applications where v1 allows undoing 1 step, and v2 is well advanced - it allows undoing 5 steps!!! Forget immutability, let's just start with not copying the whole world and being explicit about your operations.

2. I believe that design patterns are something that every developer should know well. After getting to know them, one can decide for oneself - whether to use them or not, but this decision has to be conscious and weighted. I see that you probably know patterns very well and have chosen against them for "many problems". OK. Good for you. However my point is that one can't become a good developer (in the .NET world) without having a solid knowledge of patterns. If you decide to dump them in favor of functional style, LISP, DSLs, meta-programming or anything else - you're welcome. What I don't like is when someone critisizes patterns and doesn't know a thing about them (again, I'm sure you know your patterns well).

David:

That very well may be the case. I didn't promise my implementation is the best one.

I'm very interested in your sample code :) Go ahead and share your experience with the rest of the world. http://code.msdn.com, or http://codeplex.com

re: New CodePlex project: a simple Undo/Redo framework

Kevin — Tue, 07 Jul 2009 06:30:51 GMT

David Myers: I am interested in your code. Do you have somewhere you could post it?

Thanks

Kevin

Design Patterns

Stefan — Wed, 08 Jul 2009 01:03:53 GMT

Its corporations and business who want you to think in design patterns, so that they can make money. In functional style a design pattern is simply a higher order function. Everything is much much much more light weight. Design patterns are not extensible

and often non composable. One you choose to use one of them you are stuck, for the rest of the life of the application. Design patterns are top-down approach and therefore they "claim" they know the "future" of the application. Since no one can predict how an application will evolve, forget about top-down design and software architects. Software arichtects means incompetence. Use bottom-up and no-patterns. If you want to have persistance then simply use persistent data structures -- and you have a provable guarantee which you don't have an undo-redo framework. Persistance is composable -- undo-redo is not. You don't copy the whole structure upon update -- this is very important. Here is where algorithmics come into play. Simply google for "Purely functional data strucutres", read it and you

have learned much much more than reading any design pattern book -- and you have learned something right.

Using purely functional data structures, you simply don't have to solve any problem. Its very simple, all you effort is in algorithmic thinking -- how to design such a structure. But most of the purely functional data structures are out there -- simple lists, double ended queues, hash tables, trees -- the slow down and memory usage are usually logarithmic, in the size of the data structure -- which is nothing. Simply to keep a list of n operations is O(n). If one operation does an O(1) incremental update then you pay O(log(n)) in total -- its nothing compared to O(n) to keep a list of the names of the operations.

The problem is not if your or mine code is good -- here the problem is fundamental -- it is what COMPUTING is all about -- coming up with simple solutions to complicated problems.

Design patterns are complicated solution to compicated problems. I'm going to show you in a minute how design patterns are subsumed by functional programming.

Design Patterns vs. Func. Prog.

Stefan — Wed, 08 Jul 2009 03:13:22 GMT

Design Patterns is Software Developmment Done Wrong

Design Patterns arise in the Object Oriented Programming Way

The problem with OO style is first

- mutability (small problem)

- objects have multiple methods, this means that they are not built from the smallest attomic pieces (functions). Sometimes it is necessesary to have something like an OO-class (e.g. monads in functional programming -- a monad needs 3 functions), but in 90% it is not. This usually creates tight couping

especially when combined with interfaces. Try changing the interface of IEnumerable for example and you have to change 90% of existing applications substantially.

- top-down design (you need to draw your diagram before you begin coding -- need to know all about your application's future, but who can predict it?)

- Object are non-composable (because of state and multiple methods and interfaces) without significant plannig -- this is the killer. A small change in the behavior of the program will imply a large change in the code)

- Tight-copling -- this is also a killer

- Non-cooperative components

The biggest evil is on object-oriented thinking. Object orientedness lacks the following properties

-- composability. Fix: use only simple functions. Use well-though-out and composable type-classes.

-- non-intrusiveness: fix: templates (like C++) and generics, also static type classes

Most design pattern solution actually propose either classes with state + multiple methods.

Let's take a look at some desing patterns from wikipedia and

show that those are either features of functional languages or

a higher order function

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Encapsulation and information hiding

FP Solution: a closure

Inheritance or subclassing

A type class

Many of those patterns are basically features of OO languages. They are not really design patterns...

Let's look here: http://userpages.umbc.edu/~tarr/dp/fall00/cs491.html

The observer pattern:

Java example: a database connected to a graph view and a table view

Solution: message passing Erlang-style

Factory Pattern:

Java Example: CreateDocument with methods open/close/save/revert

Best solution is by type classes (in Haskell)

However, this is not the best example for the factory pattern in func. prog. The best use case is a function returning a function

Iterator Pattern:

For example lists/streams with get_next()

Solution: cons lists/delayed cons lists(streams)/yield (syntactic sugar)/higher order functions generating and consuming streams

Facade Pattern

Java Example: seal classes together

Functional approach: modules

The state pattern:

A gui: object has a state and depending on actions and state change the state

Functional approach: message passing with pattern matching. Also ability to pass closures and state, Best is to keep purely functional.

Now those are the best:

The Composite pattern: simply a dot in haskell and >> in F#

Functors: a special type class in haskell (called Functor).

Addapter patterns: a simple function, e.g. List.of_seq, Seq.of_list in (example in F#)

The Decorator pattern: a function which wraps another function, e.g. read_only(takes as input a list) returns a read only list

In conclusing, I would think again if I have to use OO and with it patterns.

Recomendations: 1. avoid OO and especially OO design as much as possible. No big class diagrams, no UML, no type hierarchies.

If you have to design your program before you start coding

it then after a point the code will crumble against its weight. You cannot design against future/unknown requirements

so there is no point to try. Just make sure your code has two features: COMPOSABILITY and NON-Intrusiveness

2. Start simple. Usually programs are simply tranformations from one representations to another.

Use a library of higher order functions which can be composed together to make complicated transformations

Make a library of your own transformations if you want to avoid boiler plate code

3. Pass state around. Try to keep mutable state within a single function. For user interfaces use message

passing and monads(Haskell)/computation expressions(F#)/engines(Scheme)

Gui Example (not compiled, but possible to write in this style):

let db = open_db("...")

let rec mygui = gui{

let state = get_state()

let t = state.num_tries

if (t > 0) then

do! mk_label "You tried too many times"

let! usernamebox = mk_textbox "User name:"

let! passwrdbox = mk_passwordbox "Password:"

do! button (fun msg ->

match msg with

| ButtonClicked -> let username = get_text usernamebox

let passwrd = get_text passwrdbox

if (lookup_db query{

let! users = table db "users"

filter(users, fun (this_user,this_passwrd -> username = username &&

this_passwrd = passwrd))

|> count

}) = 1 then

//continue gui simply runs the next screen

continue_gui nextgui (update_state state{user=username})

else

continue_gui mygui (update_state state{num_tries = state.num_tries + 1})

}

//run the initial screen

continue_gui mygui mk_init_state()

re: New CodePlex project: a simple Undo/Redo framework

NSFW — Wed, 08 Jul 2009 09:49:44 GMT

"Its corporations and business who want you to think in design patterns, so that they can make money."

If that's true then thank you for warning me away from this functional stuff. I'd hate to find myself using an approach that didn't lend itself to writing software that customers actually want to pay for.

re: New CodePlex project: a simple Undo/Redo framework

Farid Zakaria — Wed, 08 Jul 2009 19:52:57 GMT

There are two sides to this coin and the discussion seems to have diverted largely from the original intention of undo/redo.

I think design patterns are a great tool such as a hammer however it is important that not everything is a nail.

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Wed, 08 Jul 2009 21:56:56 GMT

Farid: you NAILED it!!! :)

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Thu, 09 Jul 2009 04:48:10 GMT

Stefan: this deserves a separate blog post. Do you blog?

re: New CodePlex project: a simple Undo/Redo framework

Khurram — Thu, 09 Jul 2009 11:10:35 GMT

Stefan:

I completely agree with you. I had been scratching my head with patterns before I came to know about functional world.

I agree that the fundamental problem isn't that your code is good or mine, what should be the ideal pattern for a problem but The problem is how we think about problems and choose an appropriate solution. Functional programming is a natural way of computing. On the other hand, oop and design patterns give you a vocabulary at very high level to communicate about the problems and there solutions. I haven't seen anything like this in functional world. There are tradeoffs in each of the world. I'm still looking for some standard ways in functional world to design large scale systems and a higher level language to model (like design patterns).

re: New CodePlex project: a simple Undo/Redo framework

M. Wernig — Thu, 09 Jul 2009 18:30:59 GMT

Kirill: Stefan's posts regarding design patterns really should be a separate post/discussion. I would definitely be interested in hearing some of the opinions on both sides of the issue. I tend to agree with Stefan regarding design patterns, having seen them being misused repeatedly and turning relatively simple systems into a bloated, hard-to-maintain, ones. (p.s. I also hate the term "software architects" :-)

re: New CodePlex project: a simple Undo/Redo framework

Dave — Thu, 09 Jul 2009 19:02:53 GMT

Stefan:

It looks like you apply the monolithic paradigm very well. I'm sure the work you do has never made it beyond academia where everything is about the algorithms used in implementations, but in the real world, be it enterprise development, game development, or device driver development, the type of spaghetti code that your style of functional programming leads to never produces a complete solution that is useful or maintainable.

Even your example does not provide a solution on target with the Undo/Redo framework, instead providing a trite example of how much garbage you can shove into a function. If you want to illustrate how much better functional programming can be, you should create a functional version of Kirill's solution so we can understand the downfall of our foolish OO ways that we somehow managed to produce maintainable software. This means you have to create a complete, buildable solution, not just throw up some theoretical code. I would love to see it, rather than an academic example that is missing your functional tenants of simple and composable, even for the basic task of validating a login.

re: New CodePlex project: a simple Undo/Redo framework

Dave #2 — Thu, 09 Jul 2009 21:11:33 GMT

@Dave:

My thoughts exactly. I want to like functional software, but everything I see about it being "superior" is theoretical.

Show me an enterprise level, distributed system, and then I can take you seriously.

re: New CodePlex project: a simple Undo/Redo framework

Bruce Pierson — Thu, 09 Jul 2009 22:52:34 GMT

@Dave:

Beautiful. Everything I've read on FP is academic, and they spend all their time trying to figure out how to make something like a Queue immutable. WTH!? Convince me of the BUSINESS VALUE of something, then I'll look at it.

re: New CodePlex project: a simple Undo/Redo framework

Ben — Fri, 10 Jul 2009 01:32:07 GMT

Don't EVER listen to a compsci major / phd about anything real world..

re: New CodePlex project: a simple Undo/Redo framework

Christian — Fri, 10 Jul 2009 12:47:53 GMT

@Bruce

try to weigh everything with business value and you are stuck in repetition because looking outside the box is costly at first and who knows whether you are being rewarded.

@Ben

It is those majors/phds who add to the existing body of knowledge - or inversely without them you wouldn't even be programming using punch cards. Clearly, not every aspect of theory has a direct application in the non-academic world but as Jeff Atwood has demonstrated recently, there is even practical value in the P=NP problem (http://www.codinghorror.com/blog/archives/001270.html).

Now, I agree with that before before touting something without proof one should think carefully about the word one uses. However, I believe this form of discussion repeats itself (Assembler vs. C, C vs. C++, ...). Clearly, (at the moment) functional programming languages can be used more efficiently (lines of code per hour/$) for certain classes of problems ("number crunching" if you will, etc.). For example, banks use FP in the development of risk assessment programs, chemical companies use FP in the development of gene/molecule sequencing programs. Routing algorithms, Spam filter, Machine Learning utilizing apps, ...

Now, if you consider the above type of applications as something of pure theoretical/ academic value, you are certainly right (but I believe then we might have a different interpretation of academic/theoretic).

To make a long story short, if boundaries are not pushed there is no progress - and clearly I wouldn't want to be a developer in a world where the same type of applications are developed using the same old-style methods (remember before the invention of quicksort there was only linear sort).

re: New CodePlex project: a simple Undo/Redo framework

Stefan — Fri, 10 Jul 2009 17:05:45 GMT

Actually, all the possible project mentioneds:

-- Kiril's live geometry project

-- Distributed systems

have simpler (and beatiful) solutions by Functional Programming (that are more

likely to work).

Let me give you challenge: implement

a parallel/distributed version of

K-means clustering algorithm in 10 lines

of code in OOP. Then we can talk.

I choose this problem because it is just

10 lines (matching my implementation). Kiril's system would be more lines, that's why I propose this.

re: New CodePlex project: a simple Undo/Redo framework

Dave #2 — Fri, 10 Jul 2009 18:16:48 GMT

@Stefan,

You prove my point exactly. An algorithm is the same kind of example I always see. An academic, but useless example.

I issued the challenge initially:

Show ME a an n-tier enterprise solution implemented with a functional language, then we can talk.

re: New CodePlex project: a simple Undo/Redo framework

Dave — Fri, 10 Jul 2009 18:22:06 GMT

I'm not trying to pit OO against FP or C# against Lisp. I think whatever technique and toolset makes the most sense for the solution is the best, and I'm sure there are some scenarios where FP makes great sense - I'm just not seeing it here. Instead, I've seen a usable OO solution by Kirill for an Undo / Redo framework, followed by a diatribe by Stefan on how OO is terrible and an FP solution would be so much better. But I don't see an FP solution, and in my C# OO mind, or even in an IronPython blend of OO and FP, I'm having trouble conceptualizing how an FP solution would be better.

Again, I'd really like to see a complete FP solution to this problem, because I'm always a fan of applying different techniques. I really don't think Kirill posted this blog entry to discuss the merits of OOP, but rather to present an implementation of an Undo/Redo Framework using a design pattern. The point of a design pattern isn't to show off OOP skills but rather to communicate a software design using generally understood programming techniques. I'm willing to bet there are FP design patterns as well, right?

Stephan - rather than continuing to come up with new algorithmic challenges, why don't you just take on the challenge Kirill did (staying with the topic of this blog) and create an FP version of the Undo/Redo Framework. I'm sure if a parallel K-means clustering algorithm can be done in 10 lines of FP, then the Undo/Redo Framework is what, 3 or 4? It sounds great! Show me!

re: New CodePlex project: a simple Undo/Redo framework

Marjan — Sat, 11 Jul 2009 18:20:32 GMT

FP is good for trying algorithms in a quick way. If you want to build system that will be extendable and modular FP fails.

Also correcting mistakes and bugs is quite harder in FP than in OO, not to say communication between scenarios, n-tier architectures.

re: New CodePlex project: a simple Undo/Redo framework

Rajesh — Sun, 12 Jul 2009 00:57:06 GMT

I gone though both the aspects of OO and FP. It all depends upon the organisation and implementation along with the past experince. Approach should be to make it workable and maintainable

re: New CodePlex project: a simple Undo/Redo framework

Catto — Mon, 13 Jul 2009 00:48:49 GMT

Hey Now Kirill,

That sure is a good project.

Thx 4 the info,

Catto

re: New CodePlex project: a simple Undo/Redo framework

Danny P — Mon, 13 Jul 2009 14:09:27 GMT

A Design Pattern is not the way you should do things, but merely the way people do things already, but formally documented. This is why they don't say you "invented" a pattern, but instead you "discovered" a pattern.

I do agree there is a number of people out there trying use the wrong design pattern for their problems, or even using design patterns where none are required (just for the sake of using it). A good understanding of Design Patterns in the OOP world is crucial for good software design, for it provides you with toolset of solutions for problems you (we) oftenly bump into when building enterprise application.

I believe FP has it's applicability as much as Design Patterns. It all depends on the problem you're trying to solve.

I would also like to re-iterate the challange, and have the FP-defenders (that claim FP is "better" than Design Patterns), to come up with a better solution for the Undo/Redo problem. Also, please let us know on which aspects it tops the rival (performance, maintenability, testability, reusability, etc).

If anyone is creating a forum discussion or a blog post based on the OOP x FP debate, please post the link here so we all can participate (and learn from it).

re: New CodePlex project: a simple Undo/Redo framework

Garry McGlennon — Tue, 14 Jul 2009 01:30:15 GMT

Kirill:

Thanks for sharing your work, its truely unfortunate that people have decided to turn your work in to a debate about FP vs OOP. I know how much effort it takes to prepare your work for public consumption, and I find it objectionable that its been turned into a meaningless debate and an attack on your work. Seriously if you dont like the implementation then dont use it.

Its this type of mindless debate and criticism that prevents people posting their work.

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Tue, 14 Jul 2009 02:16:39 GMT

Garry: thanks! To be frank, I totally don't mind this discussion. It's interesting to watch and it provokes thought. I might not agree with everything that has been said, but that's fine. I only regret that I haven't created a separate blog post in time to discuss FP vs. OOP - but I thought that would become just another holy war.

Also I don't perceive anything here as an attack - people can write whatever they want in a common process of "finding the truth". As long as there are a couple of people who find this framework/approach useful - I consider my job fulfilled.

I'm also not afraid that Design Patterns critisism will scare people away from projects like these - one should be able to judge for oneself - if one likes it, one will use it regardless of what others say :)

In any case, I might post a separate article on FP vs. OOP, but I'm not sure if it's going to be fruitful.

Take care,

Kirill

re: New CodePlex project: a simple Undo/Redo framework

Bruce Pierson — Tue, 14 Jul 2009 08:39:48 GMT

@Christian:

What's really funny about the "looking outside the box is costly" comment is that I remember back in the 90's when managers and such were against OOP because it was costly and required more analysis, etc. This was back when I was programming configuration systems in Lisp, ironically. The pendulum truly does swing...

re: New CodePlex project: a simple Undo/Redo framework

Christian — Wed, 15 Jul 2009 00:44:23 GMT

@Bruce

must be interesting to have this kind of experience (enables one to smile some sort of when some people jump overly excited on the train of buzzwords and almost self-fulfilling prophecies).

Now, with the recent convergence of functional and object-oriented languages (F# + OO constructs <--> C# + lambdas, ...) there isn't really one one beats it all programming language. Also, since many OO languages offer nothing more than syntactic suggar to coat the simple message sender-receiver paradigm, one may implement OO atop a lot languages (clearly not as beautiful and safe). For example, if one looks at the source code of Quake 1 one finds OO concepts embedded into C code.

Lastly, thanks to Kirill for providing brain-food, because this is what it should be about (as it has been mentioned) get the mind to think about something beautiful - solving a problem (in one of many ways)!

re: New CodePlex project: a simple Undo/Redo framework

edmund yau — Wed, 15 Jul 2009 04:59:54 GMT

very very good framework, i am using it, thank you for your great affort

@@@@@@@@@@@@@@@@@@@@

係IT super manager, 唔係super IT manager

http://www.geocities.com/it_super_manager

IT界最強技術王, 名字擬似:edmund yau

re: FP vs OO

Matt Ellen — Wed, 15 Jul 2009 17:06:59 GMT

Hi Stephan,

I'm not entirely sure you've grasped OO programming.

The whole point is to allow programmers to think like people when writing programmes, rather than having to think like a computer.

OO may take more code than FP code, but it is better code in terms of readability and maintainability.

Anyone can think like a person (generally speaking ;) ) but it takes a lot more restraint to think like a computer. Why restrain yourself like this when at the same time trying to be creative?

Maybe you've been trying to apply OO techniques where they aren't appropriate, and have come to the conclusion that FP trump OO in all cases.

That said - I'd be very interested to see a FP version of undo/redo. If you have an example please post it so we can evaluate what you say.

Regards,

Matt

re: New CodePlex project: a simple Undo/Redo framework

MAMA Jack — Sat, 18 Jul 2009 15:08:54 GMT

coolo, just what I might need if i was writing a professional app. A killer app, many would say it were.

re: New CodePlex project: a simple Undo/Redo framework

Brian — Mon, 20 Jul 2009 22:00:13 GMT

Funniest quote of this whole thread:

"Stefan:Its corporations and business who want you to think in design patterns, so that they can make money."

I work for a software development services company. More often than not the companies we develop for have us maintain the apps we've written for them. I can take a kid fresh out of college, plop him down in front of visual studio and with minimal instruction (though obviously heavy supervision for one fresh out of college) I can get him maintaining one of our customers apps.

As Matt said, "OO may take more code than FP code, but it is better code in terms of readability and maintainability."

I've said in my blog, "Writing code is easy. Writing code cleanly, efficiently so it’s easy to maintain, now that takes some skill."

From a business perspective FP doesn't make a lot of sense. I'm not saying FP doesn't have it's applications. I'm saying that team development of large scale applications and the maintenance of those applications become so complex that I suspect a company wouldn't make much money off of them. With OO we can develop large scale applications and turn around a nice profit from the development and maintenance of those applications.

FP might be fine for small projects with small maintenance tails and small teams. The problem with large projects is that, though we tend to have low turn-around, turn-around happens. With OO I can lead a team of ten engineers, lose one or two, drop one or two back in and there is minimal impact to the project.

@Stefan: What middle or large scale projects (which I would define as being developed by a team of 5 or more engineers, 100 person or more user base and a three to five year maintenance tail) are out there that are developed in FP and turning a profit for the company that developed it?

I'm not opposed to the idea of FP, just this idea that is seems like you want to replace all OO with FP and that just seems like a bad application of FP.

Back on topic, thanks for this code Kirill. I've looked at both of the samples and everything seems fairly straight forward. This will make my life easier. Though the project I'm working on now is too far along in development to integrate your framework I'll make sure whatever architect I'm working with on our next application is aware of the framework. Integration from the beginning design phases seems key to any core framework.

Thanks,

Brian

re: New CodePlex project: a simple Undo/Redo framework

Randy — Mon, 20 Jul 2009 23:26:37 GMT

Kirill, this is a nice implementation of undo/redo for mutable data structures. I don't want to throw fuel on the language/abstraction war, but immutable data structures do provide an easier/safer way to build undo/redo. Given the use of a garbage collected language like c#, it is fairly easy to build immutable data structures, and is a technique that can be applied independently of functional programming. Indeed it works quite well in an object-oriented design, too.

For those who haven't built large applications with undo/redo, a significant challenge is ensuring that your do/undo methods are perfect mirrors. One helpful approach is to create a small library of "actions", and everything else is built as a combination of these small, proven actions, and therefore undoing a larger action is simply undoing the set of sub-actions in reverse order.

The final plug for immutable data structures is if you have background processes that will operate on the document in parallel with the users changes (think text editor with background compilation or something similar). With an immutable system, this can be done easily and safely (just restart the background process periodically if the document changes). With mutable documents, all of the foreground (user) mutations must be synchronized with the background process.

-Randy

re: New CodePlex project: a simple Undo/Redo framework

Spaceus — Wed, 22 Jul 2009 20:45:57 GMT

Evolution is a bad thing or how am I to read this... A pattern well applied should as I see it hide the complexity of the problems your application handles. A way of getting to the core problem ( The part we get paid for). A pattern like the command pattern applied correctly would limit you app in anyway eventhough it evolves in ways you've never thought of..

Just my 2 cents

re: New CodePlex project: a simple Undo/Redo framework

Philips — Thu, 13 Aug 2009 18:00:23 GMT

I made the following change in TransactionBase. The problem is that if you rollback the transaction inside a using statement then it crashes.

public virtual void Rollback()

{

if (ActionManager != null)

{

ActionManager.RollBackTransaction();

Aborted = true;

}

public bool Aborted { get; set; }

public void Dispose()

{

if(!this.Aborted)

Commit();

}

re: New CodePlex project: a simple Undo/Redo framework

Philips — Fri, 14 Aug 2009 17:46:10 GMT

I think that inside public void RecordAction(IAction existingAction) the following two lines must be added:

if (this.History.CurrentState.NextAction != null)

this.History.Clear();

i.e. if you are back to history and record a new action the history must be cleared

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Tue, 18 Aug 2009 07:09:33 GMT

Thanks Philips, I've checked in your first change.

About the second point though, if you're back in history and record a new action, the old next action will get dereferenced and will be garbage collected. So no need for this code.

If you still believe that there is bug in the code around RecordAction and clearing history, please provide a repro in terms of the MinimalConsole sample.

Thanks!

P.S. I should really add unit tests to this project.

re: New CodePlex project: a simple Undo/Redo framework

Anwar — Tue, 08 Sep 2009 22:45:16 GMT

Hello,

Can you post the Silverlight Application for this.

I converted the existing winformsample application to Silverlight and the Redo functionality is not working as it working in winforms.

Thanks,

Anwar

re: New CodePlex project: a simple Undo/Redo framework

Ramesh — Fri, 11 Sep 2009 10:03:05 GMT

Hi Kirill,

i have used your Undo framework in my Application.

I have one doubt....Actually my application is Big one, whether it gives me any issue iwth memory...if Actions are more

re: New CodePlex project: a simple Undo/Redo framework

Ramesh — Fri, 11 Sep 2009 13:02:54 GMT

Hi Kirill,

i have used your Undo framework in my Application.

I have one doubt....Actually my application is Big one, whether it gives me any issue iwth memory...if Actions are more

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Fri, 11 Sep 2009 21:47:16 GMT

Hi Ramesh,

indeed, the Undo stack will keep references to your domain model's old state, so the Garbage Collector will not collect them. This is something to be aware of.

However any other Undo framework implementation will have the same limitation. You can use the profiler to measure the impact of keeping the undo history in memory.

I'm afraid that the rest is specific to your particular application and there is no general advice that I can give. Just use the profiler when in doubt.

One final point is that I found that Undo buffer in two of my projects contributed only insignificantly to the memory consumption, but it's still worth checking.

Thanks,

Kirill

re: New CodePlex project: a simple Undo/Redo framework

Vikas — Mon, 14 Sep 2009 16:22:08 GMT

Hi Kirill,

What all I have to do if I want to limit 10 actions for Undo-Redo?

re: New CodePlex project: a simple Undo/Redo framework

Vikas — Thu, 17 Sep 2009 00:56:50 GMT

Hi Kirill,

Nevermind. I'm not sure why I asked that. I am not a baby. I do not need you to hold my hand through every trivial thing. You gave me an example and I should use my own brain to learn how to build upon that to create my own implementation.

re: New CodePlex project: a simple Undo/Redo framework

AliPST — Thu, 17 Sep 2009 13:59:23 GMT

Hi Kirill

Great work, thank you for sharing it and the participant in Informative discussion about it.

I have some questions about details:

1-In RecordAction function, the CheckNotRunningBeforeRecording(existingAction) called 2 times: first directly and second in RunActionDirectly(existingAction) function.

Why?

2-If I want to use this frame work in a composite application (like MS CAB+SCSF), what will be it's role? As I understand it will become a central point that all the modules and work items should pass their command/action to it! this is not good, is it?

re: New CodePlex project: a simple Undo/Redo framework

AliPST — Thu, 17 Sep 2009 14:37:14 GMT

And about memory:

I run the winformsample, it start with about 18 mb memory, and after a few changing in name & age field, consumed memory grow up to 21 mb! and I think it is relatively a big number, for one int and one string field!

on the other hand, if you know Autodesk AutoCAD software, I run some test on it too, and I can not detect this behavior! it seems there is no growing in memory consumption or it's very small.

Can you help me on this?

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Fri, 18 Sep 2009 06:32:13 GMT

Hi Vikas,

sorry for the delayed reply, I'm currently on vacation. No, the issue you mention is actually great feedback, so no worries here. I definitely need to look into adding a property to ActionManager saying MaxHistoryLength or something. BTW if you came up with a solution for this, you can send me a patch or a shelveset, if you feel like :)

AliPst: this is a good find and is most likely a bug :) I'm now on vacation but once I get back I definitely will look into this. As for your second question, ActionManager should be a service that everyone consumes on an as needed basis. If you're using a dependency injection container such as MEF, wherever you need to track undo changes, import an ActionManager or make it a singleton. It's OK if a lot of things reference it. But of course, I can't tell more without looking at your particular implementation. If you use this framework in a large project, I'd be happy to hear any reports or feedback.

Also a note to everyone - the project is open source and if you'd like to send in an improvement, you're welcome to do so. After one or two quality contributions I can add you as a developer to the project.

AliPST, regarding your second message, it looks like a memory leak. I'll take a look sometime later.

Thanks,

Kirill

re: New CodePlex project: a simple Undo/Redo framework

Kirill Osenkov — Fri, 18 Sep 2009 06:36:36 GMT

Thanks all, I've logged 3 bugs in the project bug tracker: http://undo.codeplex.com/WorkItem/List.aspx

I'll deal with them whenever I have some time. Keep the great feedback coming!

Thanks,

Kirill

re: New CodePlex project: a simple Undo/Redo framework

Sergey Arhipenko — Tue, 20 Oct 2009 06:24:01 GMT

Hi, Kirill

Thanks for referencing to my DejaVu project.

It exists for a long time but not many people know about it. DejaVu uses different approach and I am happy that I did not choose Command Pattern.

Actually, I would not recomend to anyone to use Command Pattern for Undo/Redo implementation.

The general point is: it should not be solved on business logic level - it should be solved on data level. If you use Command Pattern, complexity will grow exponentially when number of commands/data entities increased. Solving undo/redo on data level tames complexity on the same level - no matter how many commands/data do you have.