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

You said it above..."Programmers would then not access the customer file
directly but use this
object ", implying that it is possible to bypass the object strictures?

If so, what is the difference between this and what I (and many others) have
been saying "Programmers would then not access the customer file directly
but use the given Read/Write subroutines".

In both cases, it seems that the onus is on the programmer to follow orders,
else she can do anything she wishes. Is this true?

Further, in the case of tools like a web development front end, you'd never
have any of the code above at all. It's all implied, and the data movement
is automatic. Therefore, if the above uppercase rule were embedded in the
Write subroutine (via, say, a dictionary definition), is this just as
maintainable as above?

And, as an aside, its amusing (insert emoticon here) to see so much
disagreement on basic jargon in the last few posts.
..
Chandru Murthi

murthi wrote:
would think that the compiled version of the code would be very
similar.

The difference would be in implementation.

If I had a customer class, I would instantiate an instance from the
class, and then see that I had a read and write method along with the
other methods and properties - all of which belong to the class. Once
I create an instance of the object, I can refer to the read method by
the class name and method name such as :

Dim myCustomer as New Customer
Customer.Read ("123456")

The same could be done using subroutines but would be as follows:

MyCustomer=""
CALL CUSTOMER_READ(MyCustomer,"123")

etc..

The problem becomes that there is no way of grouping all the functions
for the databasic subroutines together..

So, for example, using subroutines I can make the following mistake:

MyCustomer=""
CALL CUSTOMER_READ(MyCustomer,"123")
....
....
....
CALL INVOICE_WRITE(MyCustomer,"456")

I have written away a different customer than I had written...

With the object notation, I could write code such as :

Dim myCustomer as New Customer
myCustomer.Read("123")

.....
....
myCustomer.Write

Note that the Write method doesn't need to be told the Item Id because
the object can "remember" it from the read method. The key importance
is that the Object has it's own "internal" memory which you can't do in
the same way using the subroutine methodology.

So, yes.. in object methodology you have to tell the programmers not
to do read/writes directly but to use the existing object library but
this is *all* you have to tell them.. The rules for using the object
are tied up in the object definition - I can't for example, call the
Invoice Objects Write method passing a variable which has a Customer
data record in it!

Does this clarify how I'm thinking a liitle more?

I'm not saying that all this can't be done using subroutines and
function calls - nor that you can't duplicate some of this
functionality using common variables, but using OO and classes etc
provides much more structure, definition and more strictly defines what
is allowed.

*puts on flame proof jacket to protect from all the inevitable
corrections to the above* <B IG SMILEY>

Regards
Simon

Simon wrote:
If the same programmer was writing the code, then I'd sggest that the
final line could just as easily be mis-typed as :

myInvoice.Write

as the

CALL INVOICE_WRITE(MyCustomer,"456")

You have suggested. The difference of course is that a"real" OO
compiler may pick up on he fact that the "myInvoice" object was never
created.

However, as the "Basic" I use doesnt support OO, the point is mute for
most readers. I don't see any of the Basics we use today becoming
"really OO" - we an simulate up to a VERY USEFUL point, either through
extensions ala QM Basic, or smart pre-processors like the Snippet
Technology and Object structure we make available with Visage, but we
will not get the whole shooting match ... and formost readers it
probably doesn't matter a great deal either way :-(E)

You are correct in saying that myInvoice.write shouldn't compile ... and
even if it did would generate a runtime error as myInvoice doesn't exist.
The subroutine based equivalent would go merrily away and corrupt the
database.

OpenQM are adding some OO based sytnax to the code to what looks like good
affect (I should note here that I've not used the OO in OpenQM but have read
discussions and descriptions). Being able to at least build and use objects
is a start - and for me the key starting point!

So, I would disagree that we won't see OO in databasic... Whether people
will use it is another issue! As others have commented, many won't use it
because that will "lock" them to OpenQM. I find this a little sad, as MV
generically won't move forward - I don't ever see a MV standards committee
ever being reformed to ensure that all MV products implement stuff like this
in the same way....


Regards
Simon

--
================================
Simon Verona
Dealer Management Service Ltd
Stewart House
Centurion Business Park
Julian Way
Sheffield
S9 1GD

Tel: 0870 080 2300
Fax: 0870 735 0011

"Ross Ferris" <rossf (AT) stamina (DOT) com.au> wrote

Ross Ferris wrote:
[snip]

http://dictionary.reference.com/browse/mute

http://dictionary.reference.com/browse/moot

Since the point is moot I'll remain mute...

Doh! I already clicked the "Post" button!

*grins*

Mike Preece wrote: