Bank transfer example revived

[Trygve Reenskaug]

Hi all,
Morten Jacobsen, husband of my wife's niece, is heavily into accounting theory and systems. (A successful product + chairman of int'l. standardization committee, etc.). He read through my draft article on full/restricted and had the usual complaint about the bank example: The ledger, rather than accounts, are at the heart of accounting. He is currently working on a core vocabulary of accounting and a short discussion lead to an acceptable story behind our bank example:

The core of a ledger is a collection of transactions where one transaction documents the transfer of a value from one account to another (or "transfer a quantity from one resource to another" in modern parlance). The breakthrough in our discussion was when we recognized that transactions are immutable by law and international conventions. Like any database record, a transaction has no behavior. An interesting system behavior (use case) is the construction of a transaction from raw data. This behavior is not part of the ledger (what the system IS), but of the accounting application (what the system DOES).

The account objects in our example are derived from the ledger (e.g., in the Context mapping algorithm). Our accounts can be seen as caches on the ledger collection of transactions. Our use case is to construct a new transaction while applying the appropriate checks, update the account caches, and add the new transaction to the ledger. Software transaction management (BEGIN WORK, COMMIT or ROLLBACK statements) is easy to add but can be disregarded i our simple example. This story fits in both my simple and Morten's complex mental models. Our example is OK!

Morten is working on a new accounting application. He wants to publish it as an Apple app. He believes this means that he has to write it in Objective C, a language he finds complex and hard to use. So he wants to write the code in Ruby on Rails and automatically translate the code to Objective C. More interesting (to us): He favours readable code and wants to use DCI and will appreciate any advice about how to proceed. Is Maroon ready for product development, Rune?

--Trygve

[Jim Gay]

I've been reading through the maroon library but I haven't used it yet.
There is a new rubygem I've released called "casting" which helps
apply methods from a module (role) temporarily (for the life of the
context) https://github.com/saturnflyer/casting

> --
> You received this message because you are subscribed to the Google Groups
> "object-composition" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to object-composit...@googlegroups.com.
> To post to this group, send email to object-co...@googlegroups.com.
> Visit this group at http://groups.google.com/group/object-composition?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
Write intention revealing code #=> http://www.clean-ruby.com

Jim Gay
Saturn Flyer LLC
571-403-0338

[Marc Grue]

On Friday, May 31, 2013 5:47:36 PM UTC+2, trygve wrote:

Morten is working on a new accounting application. He wants to publish it as an Apple app. He believes this means that he has to write it in Objective C, a language he finds complex and hard to use. So he wants to write the code in Ruby on Rails and automatically translate the code to Objective C. More interesting (to us): He favours readable code and wants to use DCI and will appreciate any advice about how to proceed. Is Maroon ready for product development, Rune?

FWIW, a few google searches didn't reveal any easy ways of translating Scala to C (or otherwise use Scala to make Apple Apps). But apart from that I would say that my Scala macro in it's simplicity for doing pure DCI is ready for production. If there is a way to translate JVM byte code to C this could be an option too...

Cheers,

Marc

[James O Coplien]

I have done quite a bit of looking into how to inject roles into objects in objective-c. The good news is that objective-c doesn't seem to have the "sticky injection" problem of most languages. The bad news is that the exploration is only partial at this point. I'd recommend doing it in native Objective-C.

[rune funch]

Den 31/05/2013 kl. 17.47 skrev Trygve Reenskaug <try...@ifi.uio.no>:

> Is Maroon ready for product development, Rune

I believe so. There's a few shortcomings featurewise but it seems
stable. Maroon is 100% written using maroon. I've not tried it
together with rails though. The only bug I know of is actually a bug
in one of the gems maroon is based on, which is why I haven't worked
on it (it has been fixed in the current release candidate of that
gem). I released a new version of maroon yesterday that makes it
possible to generate a graph of the interconnected roles in a context
ie a dependency graph between roles. It uses the dot language and can
be visualised with graphviz.

I'd gladly help using it if Morten decides to go that way

-Rune

[James O Coplien]

Ooo!  Interesting point.

BTW, the Lean Arch book has an Account example that moves in this direction. It's DCI-ish at the high level but probably needs some work to articulate the transaction logic in terms of the roles. But it's faithful to transaction / immutable semantics.

[Matthew Browne]

Interesting post...having little knowledge of accounting, I found this background informative and useful for understanding the less trivial implementations of the Money Transfer example.

As to creating an iOS app, the idea of using Ruby on Rails to compile down to native Objective-C seems a little strange to me. Rails is designed to have most of the application logic on the server side whereas in a mobile app almost all the code should be on the client side; I would think of Rails more of a tool for creating web services that the app could use, if there's a need to retrieve data from a server (or persist it to the server).

Depending on how many native phone features he plans to use (like geolocation or interaction with the camera), I would recommend that he look into PhoneGap and Titanium.

Both tools allow mobile apps to be written using web technology (HTML5, CSS, JavaScript). With PhoneGap, if you want a native look and feel, you have to emulate it using CSS, whereas with Titanium you can actually use native UI controls and menus, but still interact with them using Javascript and in the end it will all be compiled down to native code. A major advantage of using these tools is that your app will work not only on iOS, but also on Android, Blackberry, etc.

In my opinion Javascript is an underrated language, but it's also true that it's not nearly as mature as Ruby for application development. However, there's CoffeeScript, which has a good bit of Ruby-like syntax, which compiles down to Javascript, and there's also TypeScript from Microsoft which allows you to write strongly-typed Javascript (or not; it's always up to the programmer) that also includes some of the newer ECMAScript features that aren't yet available in browsers.

Obviously method injection is very easy in Javascript, and it's also relatively simple to do basic source transformation for injectionless DCI, as Egon demonstrated in this thread. I personally have an interest in further pursuing source transformation in Javascript and TypeScript, but it will probably be a little while before I have time to work on it.

[Serge Beaumont]

Martin Fowler's Analysis Patterns book has a bunch of patterns that describes accounting in this way. I'd have a look at those, there's more in there as well, like posting rules.

Sent from my iPhone

[thir...@gmail.com]

I'm not sure where you guys rank C#'s support for DCI (I'm guessing not near the top) but Xamarin has excellent support for iPhone apps.  Unfortunately it's not a free tool.

[Benjamin Scherrey]

We've done mobile/tablet development for iOS & Android using C++. iOS supports wrapping this code in Objective-C++ and Android now has some native code support built in (the rest being done via JNI). Since you can do DCI in C++ it seems to be a good way to go if he wants his app to be more portable. Only UI system need be done in the platform's native widget model but all the business logic can be done in C+ with a DCI architecture. Most important thing we've found is that C++ offers complete resource control which is critical for a long running app on a memory limited device. Frankly Apple's own libraries leak resources and java in android has lots of difficult (impossible?) to predict memory reclamation holes. Still can't comprehend how such languages with these clear problems were selected for these kinds of devices but that's a rant of an entirely different nature... The good news is that it's quite straightforward to do real C++ under iOS.

 -- Ben

--
You received this message because you are subscribed to the Google Groups "object-composition" group.
To unsubscribe from this group and stop receiving emails from it, send an email to object-composit...@googlegroups.com.
To post to this group, send email to object-co...@googlegroups.com.
Visit this group at http://groups.google.com/group/object-composition?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Chief Systems Architect Proteus Technologies

Chief Fan Biggest Fan Productions

Personal blog where I am not your demographic.

This email intended solely for those who have received it. If you have received this email by accident - well lucky you!!