Rambling thoughts.
Simon Verona" <nomail (AT) nomail (DOT) zzz> wrote


Rather than blindly go down the road that OOP, which, after all, has been
the purview of non-application-specialists (aka computer scientists) who
have only a tenuous, abstract and somewhat adversarial connection with
reality, I'd rather see the following.

1- Syntax. Allow the use of properties and methods with the ubiquitous
".xxxx" syntax. This is an innocuous step towards appearing to be in synch
with "modern" languages. I say this because it will make the new breed of
programmers comfortable and remove one of their complaints, not
because it makes life easier. If anything, those of us comfortable with the
period as part of a variable will have a learning curve. But just like
everything else in the world, appearances are everything. So eliminate the
first visual roadblock to modernity.

2- What is the major advantage of the class structure? Has been explained
before - the inheritance, re-instantiation, etc. Let me agree that there is
merit to this. Personally the scenarios mentioned by Simon and others
(calling Invoice write with Customer data or calling Customer write with the
wrong id, are extreme and grasping at straws; even assuming they as
mis-coded this way, the error would be caught immediately on any kind of
test; in fact, many of the errors mentioned as impossible under OOP are just
not credible in a real-life system, they are meant to prove a point.)

The example given by Anthony (as many) on logging is a classic use of a
hammer to kill an ant description. He says:
So? What exactly is the matter with being specific with where you want
logging to occur? If you need another instance, add that line of code. In
our complex RAD system, I can determine the instances of logging just by
doing a Search on the (one) program file for the log subroutine call. Is
this difficult? Or error-prone?

which is not their primary concern.

Eh? How is adding a call to the logger "tangling up"? By what standard-only
by the overly-theoretical approach evinced by Anthony and others. The
rest of us would just add that line of code and go on. And if there's no
Common variables between the main code and the subroutine, you'd have to
actually explicitly code to tangle up anything.

3) That said, what would be the major advantage of such a structure in the
mvBasic world? We are not typically writing real-time code, mathematical
modeling, or stock futures analysis. mvBasic is meant to do the mundane,
everyday, ordinary things that allow you to run a business. This is where
much of the arguments on this thread fall down, or at least are overblown.
Business data processing is, at its core, pretty simple, and that's why the
simplicity of the Pick "model" did and continues to serve so well. Pick
never pretended to be anything more than a business (string data)
manipulator par excellence. And that continues to be its strength.

So the classes in this new mvBasic should follow the lead of
what's there- the Dictionary definitions. Why would you want to "code" the
class definition in*each program* when you can "code" it once? This one
fact - having to define things in programs (in the context of business data
processing) is where I totally disagree with a lot of what's going on here.
We don't need the OOP constructs in the program, we need to define and
enforce them in the Dictionary. You'd only to say something like:

Customer = new CUSTOMER [equivalent to OPEN]
Customer.Read(id) else [hopefully, I don't see too many
"elses"
in others' OOP
examples; I guess:
if Customer.Read(id) else [error] would satisfy the purists.
CName = Customer.CUST_NAME
etc.

Such things as storing the name in uppercase would be defined in the Dict
CUST_NAME and enforced by the runtime. This has been done many times (by
Ross, by me and others) more or less successfully. We (or maybe QM as they
seem to be only innovators here) need to exploit this potential success and
create a new paradigm of what "objects" could be in mvBasic.

Obviously, you could have Today= new Date
CRT Today.oconv('D2/')
etc.

4- Rigorously enforce the Dictionary as the class definition. They cannot
be edited by any editor, only by a given utility.

5- OpenQM objects are not, I suspect, anything like this, from the QMBasic
docs I read. It is not clear to me whether you can establish any link to a
Dictionary type definitio without going through an elaborate class
definition (Read method calls a subroutine which you have to code, for
example).I may be wrong.

Chandru Murthi

murthi wrote:


Open QM has rudimentary objects. Now being updated to include
inheritance. However, because of the "." syntax being so prevalent in
current MV programming, the QM object syntax is simlar to C++, that is

object->property
object->method

For me, the advantage is structure in data definitions, customer,
invoice, etc. This can be done with equates, but I find classes a
little more "elegant".

It's true that something as "simple" as logging can be put into a
common subroutine, but there really is a lot more flexibility in a
class/object. I know this becaue I'm currently implementing a
"logging" class in QM right now.

While there is basically only one method, "WriteLog", there are a
number of properties to control many aspects of the logging. Doing
this with a subroutine would not only require the passing of many
parameters, but would require passing them every single time you called
the subroutine. With the class, this "state" data may be set only
once, because it is maintained througout the lifetime of the logging
class.

He probably means if you weren't even using a subroutine, you would be
adding many lines of code within each of your file update routines. I
don't think anyone would really do this. They would use a single line,
subroutine call.

As I mentioned above, for me, it's the maintaince of "state" within an
object rather than passing parametres to a subroutine that I like. I
think using objects for data structures keeps code more consistent and
readable.

OpenQM notation

Customer->FirstName
Customer->LastName
Customer->PhoneNo

Rather than

rec<1> = First.name
rec<2> = lname
rec<3> = x

This could be a nice touch. Tie the dicts to classes. Unfortunately,
dicts only really define the data structure (properties) not much in
the way of methods. I wouldn't want to see classes based completely on
dict structure alone.

Why? It's no different than what happens in most systems today.
Blocks of $Include or Common that are full of equates. Isn't this
basically re-definition of file structure as already seen in the
dictionaries?


While I think your idea has value, I just don't think the dicts can
provide enough.

You are correct. There is no link to dictionaries.

--
Kevin Powick

Kevin:

As a side note,

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote in message ...
[snipped]

The simple solution is to create a common work variable (e.g. WORKVALUE)
then use that to pass all properties via an array. This overcomes your
hesitation and keeps everything really simple. It also has the advantage
that you can change the number of variables passed without affecting any
other calls to the log program.

It's interesting that Pick Systems, with their Update Processor, was trying
to do just this. All Input and output structure was contained in the
dictionaries and, of course, pre and post processing was happening in them
too.

Bill

Banging this out quickly, hope it makes sense. As usual I'm not
advocating some position, just pointing out the possibilities...

It's interesting and not surprising that these descriptions of the
OOPification (no, not in OED) of MV BASIC all closely resemble what's
already been done in "real" OO languages that support MV syntax.
What's happening is that creative people who aren't familiar with what
already exist are "inventing" something that others of a similar mind
have already created. The other day my mother "invented" an electric
fork that twirled spaghetti, and she was disappointed when I told her
it's already been done. I see the same sort of thing happening in
these OOP for BASIC discussions.

For example, the notion of using Dict items as a base for class
objects is at the core of mv.NET and PDP.NET:
This is the sort of syntax for example that's already in place:
Customer = CustomerFile.Read("123")
Customer["FirstName"] = "Bob"
Customer.Write
or ... CustomerFile.Write(Customer,"123")

It's occurred to me quite often that if we wanted to convert MV BASIC
to OOP, all we'd need to do is edit VB.NET code (or any of over 30
other languages) from directly within MV and then replace the Compile
command with the proper build command for the language. The result
would be EXE's for main programs and DLL's for subroutines. Of course
this is what jBASE does anyway after it precompiles jBASIC. For *nix
platforms Mono (VB and C#) can be used, or the code can be edited in
*nix with Web Services used to compile and run code on a remote
Windows box.

I really don't give a rats arse about the language or topology but I
know some idiot is going to jump on the mention of .NET. We could do
the exact same thing with VB, Perl, PHP, C++, Java, COBOL, Fortran,
etc... Except that these other languages (except for their .NET
variants) don't "natively" support MV Syntax and access to the DBMS
like their .NET counterparts. The point is that we don't need to
modify or supplement the existing BASIC language in order to show that
MV can do OOP, we already have the libraries! While it looks like all
the work is being done in MV, these days we run on top of other
operating systems - let them do the work, we don't need to do
everything "inside" the VME.

Using ED or UP or AE or WED on external program files is just as easy
as working on something in a local "BP" file. These external
libraries operate outside the MV environment and need to login to
accounts - if I were to do this for myself I would have a pre-compiler
that adds an init routine to the code, so that the code is run in
whichever account is launching the code, and for systems that support
a User concept, the right User ID/permissions would be used.

Someone might say it's inelegant to write code that's being executed
outside of the environment. jBASE has been doing this for years and
it's considered a product advantage! What's the big deal with writing
and executing code in the VME anyway? MV is the only environment that
I know of where this is done - with other DBMS envionments code is
written and (perhaps) compiled outside, and then run on the database
as a separate entity. This concept of running from within the machine
doesn't exist elsewhere. We only stick to it because at our roots MV
was originally an operating system. Now that we've left memory
management, disk access, and other functions to the OS underneath us,
why not make use of the compilers and run-time environments under the
DBMS as well?

Anyway, it seems to me that rather than modifying the already
esotheric MV BASIC language that we can just use existing tools, and
integrate them into the MV environment. In particular, mv.NET is
already cross-platform compatible, which completely eliminates the
problem of portability. Want to call to existing non-OO code? Easy:
result = Account.CallProg("progname", params...)

So you don't lose existing code, you get the features and benefits of
external libraries, you get a ton of features not available in MV
BASIC, you get cross-platform compatibility, the ability to hire new
people who immediately "speak the language"... Too many benefits to
pass up if you're inclined to do this sort of thing. Who would really
do it? I dunno, there's probably a lot more people who twirl
spaghetti on their fork.

If someone would care to commission a prototype I'd be happy to do it.

Tony
TG@ removethisNebula-RnD.com

Completely different response than my other one in this thread (also
banging this one out and hoping it makes some sense):

I also see that when people talk about object orientation, that it's
commonly assumed that objects directly correspond to files, which is
why we see notes related Dict items to field references.

Of course it's nice to refer to a file item as an object, but true
object orientation needs to extend beyond the confines of how data is
physically stored on disk. For example, getting Order Detail is not a
function/method which should be implemented on an Order Header record.
When you create an Order class, it may get its data from OrderHeader
and OrderDetail files, as well as the Customer file, Products, Terms
tables and elsewhere. Most apps don't have both Header and Detail
files _plus_ a higher level Orders file which coordinates the others.
So an Order is really an abstraction, a Business Object, which
encapsulates other object types which are in fact defined by
dictionaries.

Any attempt at object orientation needs to include provision for this
sort of higher-level business object, and not rely too heavily on the
dictionary as the base for its properties.

FYI: mv.NET is being enhanced to generate business object classes, a
tedious function commonly done by hand. Higher-level classes will
still probably need to be done by hand.

Another reason why I make this distinction... When people talk about
object orientation related to Pick code, we see examples like
Customer->Name = "Joe"
Customer.Write
etc
What we don't see too much of is recognition that fundamental coding
principles need to change when one starts objectifying ones code. For
example, current order entry code will read existing orders, allow
data entry, file the header and detail items, update the customer
master, update product available quantities, and perhaps handle
billing, shipping, forecasting, and other functions. An
object-oriented application wouldn't do this. Each object is
responsible for its own business function - your order entry people
don't assemble goods on the shop floor, pull stock, drive the trucks,
and negotiate with vendors too, do they? No, each object is given
just as much info as required and the responsibility is delegated for
them to accomplish their task.

This is where design patterns and coding habits become as much a part
of OOP as the syntax we use. If you're using OO syntax in
linear/procedural logic then you aren't really accomplishing much, and
you certainly aren't making your application any more attractive to OO
programmers that you hope to attract to our market or some specific
project.

Regards,
T

Bill H wrote:

Well, I didn't think there was a "problem" looking for a solution.
There are usually multiple ways to achive the same goal.

My hesitation?

but cannot ensure consistency throughout the codebase.

Of course this would entail updating your logger subroutine to handle
these new variables.

The same is easily achived with a logging class. New properties are
added to the class and one does not have to worry about updating
existing code that calls the class with existing properties. No
difference.

However, maybe a logging class wasn't a good example to support the
idea of classes/objects.

Anything you can do with classes/objects can probably be imitated to a
degree with existing methods in many MV BASIC systems.

I don't think the issue is trying to prove that classes/objects let you
do things that you can't already. I think what classes give you is a
different approach to development that *can* be more elegant,
efficient, and results in code with better asthetics.

Of course, this is entirely subjective. The same could be said of CASE
statements vs IF/THEN/ELSE :-)

--
Kevin Powick

(Warnng - long and rambling!)
Tony Gravagno wrote:
Tony,

I hear and understand what you say - and as a dotnet advocate know
where you are coming from. I still believe that whilst languages such
as vb.net, c#, java etc can be used to develop in MV (and perhaps
should be used these days) that Data-Basic is the in-built language of
the database and should be developed independently.

OO is the natural development for Databasic. If somebody (Martin from
Ladybridge) is willing to do the work, then it should be commended.

The example that Chandru gives (of databinding to a file within
databasic) is his thought on what OO should be (an object being simply
a representation of a file), then he has missed the point. Building a
class that provides databinding can be a example of how OO can assist.

Data-binding to the dictionary could be reasonably easily engineered -
though personally I would prefer to extend the dictionary to add to the
existing definition as well as compiling it to more easily processed
metadata (does mv.net already do this ?). This could in turn use a
whole host of other classes that provide the data typing (Date, Time,
Currency, Int, String etc).

Higher level Business classes could then use these databinding and
datatype classes to expose higher level methods and objects.

One thing that always strikes me is that the logical extension to
having OO in databasic is the requirement for extensions to the editor
to make the classes much easier to use. One of the key things I like
about using vb.net in visual studio is the fact that as soon as you
type an object name in and press the dot a drop down list of all the
available properties and methods appear. For me, this demonstrates
another major aim of OO (grouping all the "subroutines" (sic -
referring to Chandru's comments) relevant to an object together). At
the moment, there isn't a great deal to differentiate Chandru's
advocation of using subroutines with the new QM OO because in both you
need to *know* the names of the methods and properties by utilising
existing documentation. The Objects in OpenQM are not (asaik) self
descripting or usable in this way.

Maybe I've talked my way round in a circle, and perhaps should be
advocating the replacement of Databasic with vb.net for example! Though
to be cohesive, OpenQM would need to be bundled with a dotnet (as well
as perhaps a java) class library which provides "databasic" services.
Perhaps Martin needs to discuss bundling mv.net with OpenQM in the same
way that products like Accuterm and Coyote are! There is certainly
lots of room in the competitive pricing of QM to increase the price to
absorb this.

Having reread what I've written, I'm now confused as to exactly what
i'm advocating.

As a vb.net programmer as well as a databasic programmer (I write in
both all day using vb.net for the client code and databasic for the
business rules) maybe I just want to see databasic be able to have some
of the benefits that I see in vb.net....

Not sure I've actually come to any conclusions with this post!

Regards
Simon

Tony:

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote in message ...
It seems the implementation is different but the concept is the same. We
all have dictionaries that accomplish this, so the file object (the data and
dictionaries) is also the Business Object abstraction which encapsulates
other file data through the dictionaries (we can use translates and virtual
attributes). The abstraction is logical through the object of interest, so
we do end up getting Order data as well as Customer, Products, Terms, and
other data from the MV Order class. Abstracting beyond this, creating a
class of dictionaries that all files use, is often a level of abstrations
most of us are unwilling to use because of its inherent obfuscation.

Is the Order set of dictionaries the same as a Order class library in OOP.
Not really, but this is more because of the rigid definition of OOP classes
than the fault of the dictionary structure. Remember, relational defines MV
as bad, therefore most relational people find this as "prima facia" evidence
of the undesirability of multi-values. So, one must be careful of viewing
other business structures through the "colored" glasses of the OOP
framework.

This seems to be true from within an OOP framework. Since many languages
use the OOP paradigm they also restrict development to this pre-defined
framework. A dictionary set (both data and virtual processing) seems more
like another way, comfortable in our case, of structuring a real business
object than an abstracted OOP construct.

Would a dictionary called "AddrBookName" in the Customer file better exist
in the (VOC), and be inherited by any file object needing the property or
method? Maybe, but we always have the problem of flooding the (VOC), so
some MV use a (DICT.DICT) which would create a more OOP abstraction.

This isn't always true. Some business processes are unique and, therefore,
don't require this level of abstraction. The process can be easy to
construct and easy to maintain. When you build an addition to your house,
do you need water, sewer, 220V, a foundation, basement, garage, etc? It's
not always necessary to completely integrate into the original house
framework (but you could).

I can't seem to find too much wrong with what you're talking about regarding
OOP techniques. What I do find difficult, however, is OOP scope. There
seems to be way too much. :-) Public, private, protected, friend,
protectedfriend, session, a block, a procedure, a module, a class. You know
what I mean. A little less abstraction would be helpful.

Kevin:

Didn't mean to offend. I was just pointing out simplicity is itself a
defined consistency; and, IMHO of course, is always more desired than an
artificial construct. :-)

Bill

"Kevin Powick" <nospam (AT) spamless (DOT) com> wrote

murthi wrote:
Given that OOP has been out there a while, I agree we don't need to go
blindly down that road -- we can see it, touch it, use it and adjust
it. There is a lot of Java code, for example, that works with MV
databases. What works? What doesn't? What needs adjustment?

If we swapped out DataBASIC for some other language, what features
would be missing in those languages for them to work effectively and
with the best bang for the buck with MV databases? Could they be added
in as components based on that language rather than having to tweak the
language. What would we need to do to Java (running in a JRE), C#
(running in .NET), or Ruby (running in the native OS IIRC), as some
examples, to make these languages better than DataBASIC as the standard
language for the database? What about a functional language like
Haskell or even JavaScript? Why do we need a separate database
language?

I don't have a warm feeling about extending DataBASIC for OO as if that
would excite anyone outside of MV, but it could help extend the life of
DataBASIC longer if that is the goal.

Laughing. I once thought that at least Computer Scientist and app
developers focussed on best practices were striving, at least to some
extent, for the same thing, but, yup, I agree.

I don't think we just want to take what we see as reality and make it
better, however. There is some good to thinking abstractly about what
would make for better s/w dev without being tied to, uh, reality. It
seems a good idea to inform our choices from both reality and theory.
But we do need to solve real problems. With the biggest issues in data
processing apps being in the mapping between the problem space
(reality) and a solution -- requirements gathering, determining a
design that optimizes for the machine/people combination, along with
the introduction of a solution into reality (people & processes needing
to adjust, for example), the mathematical theories hit a very small
part of what we are doing. It can help with some of the innards,
however.

Providing an effective way to package and work with nouns (objects) as
well as verbs (functions), perhaps? --dawn