The ramblings of a yorkshire tyke » cobol.net

Method Chaining

spgennard — Thu, 27 May 2010 23:50:09 +0000

Creating objects with a complex constructor can be a bit of a pain in any language. One technique I have used is method chaining. It is not applicable to every type of class but it can be useful.

Method chain can help simply the use class and allows more complex object initialisation without having to worry about the order of the parameters and be done inline.

Consider the use of an “Account” class that takes Name, Address, Telephone and Country. All of which are strings, the constructor with four strings would not be a great constructor.

So you could have a simple constructor and four properties/methods.. however so set up the object would mean you have spread the setup over multiple lines.

Using method chain you can overcome this and even space in the “value” area of the object in your storage area.

set x to new type Account::Name("xx")::Address("yy") ::Telephone("yy")
::Country("zz")::World("Earth")

The trick of the pattern is to provide methods that always return this/self, so we can change the invokes together… For example:

This technique could even be used to build up a series of items required, for example, the preparation and execution of a sql statement comes to mind… in a similar fashion to Linq.

So… lets look at an example:

$set ilusing"System.Collections.Generic"
program-id. Program1 as "MethodChaining1.Program1".
data division.
working-storage section.
01 accounts type List[type Account] value new type List[type Account].
01 jAccount type Account value
new type Account::Name("Mr Johnson")::Address("Somewhere, some place")
::Telephone("+44 1234 4321").
01 sAccount type Account value
new type Account::Name("Mr Smith")::Address("Nowhere place")
::Telephone("+44 1234 4321")::Country("Wales").
01 lAccount type Account.
procedure division.
invoke accounts::Add(jAccount)
invoke accounts::Add(sAccount)

perform varying lAccount through accounts
display lAccount
end-perform

goback.
end program.

WIth the class being:

class-id Account.

working-storage section.
01 wName string property as "Name".
01 wAddres string property as "Address".
01 wCountry string property as "Country".
01 wTelephone string property as "Telephone".
01 wEmail string property as "Email".

method-id New.
local-storage section.
procedure division.
set wCountry to type System.Globalization.RegionInfo::CurrentRegion::DisplayName
end method.

method-id Name public.
procedure division using uName as string
returning ret as type Account.
set self::Name to uName
set ret to self
end method.

method-id Address public.
procedure division using uAddress as string
returning ret as type Account.
set self::Address to uAddress
set ret to self
end method.

method-id Telephone public.
procedure division using uTelephone as string
returning ret as type Account.
set self::Address to uTelephone
set ret to self
end method.

method-id Email public.
procedure division using uEmail as string
returning ret as type Account.
set self::Address to uEmail
set ret to self
end method.

method-id Country public.
procedure division using uCountry as string
returning ret as type Account.
set self::Country to uCountry
set ret to self
end method.

method-id ToString public override.
procedure division returning ret as string.
set ret to String::Format("Name:{0}, Address:{1}, Telephone:{2}, Email:{3}, Country:{4}",
self::Name, self::Address, self::Telephone,
self::Email, self::Country)
end method.
end class.

Which when run with Visual COBOL gives:

Name:Mr Johnson, Address:+44 1234 4321, Telephone:, Email:, Country:United Kingdom
Name:Mr Smith, Address:+44 1234 4321, Telephone:, Email:, Country:Wales

Visual COBOL @ Microsoft Teched

spgennard — Mon, 29 Mar 2010 21:23:17 +0000

The last couple of weeks have been very busy and it has unfortunately affected the amount of blog entries I have done but the good news I have plenty of new material..

So, what’s my excuse.. Well we have been counting down the internal builds of Visual COBOL and we are pretty much ready to ship which is a relief since we are going to launching it at the Microsoft’s Visual Studio launch parties in Las Vegas and TechEd in Bangalore April 12-14.

Personally for me I am quite excited because I will be going to Teched in Bangalore to help show off Visual COBOL.

If would like a look at some of the Visual Studio 2010 integration Micro Focus has is about to release, pop along to http://vs2010.microfocus.com/ and see for yourself. Better still, have a visit to teched

I will finish the silly little blog with a link to a demo of Visual COBOL. Just because I’m proud of it…

ref: http://www.microsoftteched.in/
and http://www.microsoft.com/visualstudio/en-gb/products/2010/default.mspx

Reflection and COBOL

spgennard — Sat, 13 Feb 2010 22:56:01 +0000

For the last couple of months I have working on Visual Studio 2010 and this include Microsoft CLR v4 and I was recently asked how to write a test that determines at runtime which CLR is being used and what assemblies it uses. I replies would use reflection. So I dropped my friend a mega simple demo… and here it is.

$set ilusing"System.Reflection"

01 myAssembly type "Assembly".
01 usedAssemblyName type "AssemblyName".

set myAssembly to type "Assembly"::"GetExecutingAssembly"

display "My exe is " myAssembly::"FullName"
display "and is using CLR " myAssembly::"ImageRuntimeVersion"
display "and is loaded from " myAssembly::"Location"
display "the initial method of this program was "
myAssembly::"EntryPoint"::"Name"

display "This assembly references -> "
perform varying usedAssemblyName
through myAssembly::"GetReferencedAssemblies"
display "-> " usedAssemblyName
end-perform

And the output of the program is:

My exe is clrver, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
and is using CLR v2.0.50727
and is loaded from d:\clrver.exe
the initial method of this program was _MF_ENTRYThis assembly references ->
-> mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
-> MicroFocus.COBOL.Runtime, Version=3.6.0.0, Culture=neutral,
PublicKeyToken=0412c5e0b2aaa8f0

A Comparison Of .Net COBOL, Visual Basic and C#

spgennard — Tue, 15 Dec 2009 12:35:44 +0000

Today my collegues Robert and Alex have finally decided to publish a document that compares Visual Basic, C# and COBOL for .Net under The Creative Commons Attribution-ShareAlike 2.5 License.

Rather than doing a cut-paste job, here is a quote from alex, along with a link to the “real” article itself.

Enjoy.

Alex Turner said:

A Comparison Of .Net COBOL, Visual Basic and C#

Introduction

If you are a COBOL programmer wanting to learn C# or a VB programmer wanting to learn COBOL as a .net language (or any other combination of VB.net, C# and COBOL) then this is a good place to start.

Background

If you are a COBOL programmer wanting to learn C# or a VB programmer wanting to learn COBOL as a .net language (or any other combination of VB.net, C# and COBOL) then this is a good place to start.

It has often been noted that the richness of the COBOL language in its Micro Focus .net implementation is not well known. Robert Sales and I have worked on this document to help bring the language to peoples’ attention and to help people who need to work with COBOL on the .net platform.

Click here to continue reading the rest of the article…

Free compiler for non-commercial use.

spgennard — Tue, 08 Dec 2009 08:38:25 +0000

If you are interested in trying out some of my examples with a modern COBOL compiler.. let me give you a quote from a friend.

From: Twitter “Scot Nielsen said: Micro Focus COBOL for .NET and Visual Studio available here FREE for non-commercial.

The development environment/compiler can be downloaded from the Micro Focus Shop.

More information can be picked up from the Microsoft Visual Studio Gallery

Factory Method Pattern in COBOL

spgennard — Mon, 07 Dec 2009 20:49:24 +0000

Continuing my series on design patterns for the COBOL, the next one on my list is the “Factory method” pattern.

The pattern is useful, as it helps you hide the real implementation/creation mechanism of your classes. I you are fond of uml… here is the actual uml (from wikipedia).

Factory Method Pattern from Wikipedia!

So… lets see the COBOL code…

interface-id. "Base".
method-id. "DoIt".
end method "DoIt".
end interface "Base".

class-id. "Derived1Impl".
object. implements type "Base".
method-id. "DoIt" public.
display "Derived1Impl from DoIt".
end method "DoIt".
end object.
end class "Derived1Impl".

class-id. "Derived2Impl".
object. implements type "Base".
method-id. "DoIt" public.
display "Derived2Impl from DoIt".
end method "DoIt".
end object.
end class "Derived2Impl".

class-id. "Factory".
object.
method-id. "GetObject".
linkage section.
01 obj-base type "Base".
procedure division using by value oType as binary-long
returning obj-base.

evaluate oType
when 1
set obj-base to new type "Derived1Impl"()
when 2
set obj-base to new type "Derived2Impl"()
when other
set obj-base to null
end method "GetObject".
end object.
end class "Factory".

class-id. "FactoryDemo".

method-id. "Main" static.
local-storage section.
01 obj-factory type "Factory".
01 base-obj type "Base".

linkage section.
01 args string occurs any.
procedure division using by value args.
set obj-factory to new type "Factory"()

set base-obj to obj-factory::"GetObject"(1)
invoke base-obj::"DoIt"()

set base-obj to obj-factory::"GetObject"(2)
invoke base-obj::"DoIt"()

end method "Main".
end class "FactoryDemo".

That was pretty straight forward… not too much pain…

And finally the code produces…

d:\> FactoryDemo.exe
Derived1Impl from DoIt
Derived2Impl from DoIt
Hello world

Time to sign off for today.. but if you would like me to continue the series on code patterns or have a particular pattern you need… drop us a line!