Responding to my name, not the "brighter" part.

Yes, there is compiled JavaScript though performance is questionable
so some would prefer Java.

There is also server-side JavaScript, though this is waning in favor
of PHP, Perl, and compiled languages. Microsoft still supports
JScript but I'd wonder for how long.

JavaScript itself is highly extensible and can call libraries just
like compiled languages, Java, etc. - much more than simply calling
subroutine/functions. So it has power, but no inherent database
access that I'm aware of. So it can be extended to do what Dawn's
talking about but I'd approach such a project cautiously. I'd feel
much better with Java on the server.

HTH
T

"Simon Verona" wrote:

"murthi" wrote:

Condescention wasn't intended but I do think it's a shame that one
would be so adamant on creating something from scratch that already
exists.

"Eating with these damned chopsticks is so hard, I think I'll put a
scoop at the end of one of them."
"Err, that's a spoon, want one?"
"I don't care about your newfangled gizmos. Hand me some paper and
string." ...

It is. I've proposed a couple ways it can be done using existing
tools, and suggested that there is no need to build something into MV
that doesn't belong in there in the first place.

<diplomatic mode temporarily switched off>
<maybe I need more (less?) coffee>
Let's get realistic. The only DBMS where this can happen is with
OpenQM and the project is already underway and being discussed
elsewhere. This rhetoric here in CDP is just idle chatter. Don't we
have more important things to do or areas of this market where we CAN
influence change, rather than wasting time on this topic as though it
will be of any benefit to a general MV community? An obvious response
to that is that I don't need to read a thread if I'm not interested.
I value comments by our colleagues, so I read them - people do me the
same courtesy. I just get frustrated when time is wasted in these
explorations into the impossible. We might as well be discussing
embedded MV in mobile devices or in-dash automobile computers.
<//>


That wasn't suggested. I said (more or less) we should be using
existing tools in conjunction with the environment rather than
creating new tools with the only goal that they eventually equal what
already exists.


I know you're not advocating building everything into MV, or that
external tools shouldn't be used with MV, but that's sure what it
looks like here. I think I understand your argument but these
comments just push it over the edge.


I had suggested using mv.NET which is exists expressly for the purpose
of facilitating .NET/OO development for people who come from a
DataBASIC background - and to facilitate the introduction of DataBASIC
to people coming from the OO world. There's nothing "inadvertent"
about that.


His comments are consistent - OO is generally good but an effort to
hardcode it into the MV model itself doesn't seem to be the best way
to derive the benefits. Do I need to "get" to someone for that sort
of statement to seem reasonable?
BTW Simon, u want yer 5 quid via mail or direct deposit?


Understood - wasn't sure where you were going with it... Most
discussions tend to start _and_ stop with file definitions. For as
long as I can remember people talk about the idea of using dict items
in code, though dict items don't represent business objects. The
"FILE" statement in D3 allows for Custome<Name> Syntax but also
includes no concept of business objects. Forge, the Update Processor,
and other screen generation utilities all did/do the same.


This thread began with little more than the assertion that MV object
orientation would result in syntax like:
CUSTMER = NEW CUSTOMER()
CUSTOMER.READ etc
That's not enough to justify adding OO to MV. It's certainly not
enough to get OO developers to feel comfortable with MV as though
they're working in a familiar environment.
We can already do this:
EQU CUSTNAME to 1
CUSTOMER<CUSTNAME> = "Bob"
I don't see this syntax as being superior:
CUSTOMER.CUSTNAME = "Bob"
And we can already do this:
COMMON CUSTOMER
CALL CUSTOMER.UPDATE
So why do we need this syntax:
CUSTOMER.UPDATE
Or:
APP.UPDATE(CUSTOMER)
etc... ?

"Objectification" of a language is more than changing syntax to do
common functions. Let's assume that part is already done. The real
meat is in creating multiple instance/objects of a given class type,
execution of constructors to prefabricate common objects, allowing a
class definition to encapsulate rules so that we can take common rules
out of application code ... and there are SO many other things to
object orientation outside of syntax.

What I'm saying is that if you are going to take it that far, why not
use what already works well rather than theorize about the concepts
(and only some of them at that) as though this is the first time this
has been thought out?


We're all here because we agree that the model is useful. Over time
the model has changed to make use of tools outside that
augment/supplement the code package. That doesn't mean we're giving
anything up, just admitting that there are other ways to accomplish
things. To wit:
- Pick used to be an operating system handling its own disk operations
and memory management. It's not a DBMS over existing OS platforms,
leaving the ultimate hardware interface to these other layers.
- While Coyote is a nice idea as a native web server it was never a
major success. Apache and IIS specialize in the tasks required of web
servers and developers tend to use these rather than Coyote.
- Most MV developers acknowledge at some level that they can send
e-mail directly from their MV envirnment, but prefer to shell out to
other common tools like sendmail and blat.
- For file transfer among environments we could write socket
interfaces for the various MV platforms, but the most commonly
accepted tools are outside of the box: FTP, Samba, AccuTerm FT, etc.
- People can use ED/AE/UP/vi and other tools for editing Pick items,
but a good number prefer to use external tools like wED which has a
Multiple Document Interface, colored syntax, etc.
- While some people have asked about encryption in MV, it's commonly
agreed that this should NOT be done in MV itself, but that we should
shell out to OpenSSH or other tools to use proper MD5 or other
standards.

This discussion of OO within MV is no different. I never advocate
replacement or giving up on MV, only errr, using the RT4tJ... figure
it out.


It still sounds like you're talking exclusively about OO only in terms
of data management with Dict items and File IO. Relational databases
have referential integrity imposed by stored procedures and file time
triggers. That's what we get by putting code into Dict-like
constructs. This is completely unrelated to object orientation of the
language we use to manage our code logic - not just the data
management but logic flow in general.

I apologize if I've missed your point.

(Off the wall comment) This all sounds so argumentative and while it
seems like that's all I'm doing here I assure you I don't enjoy it
when it gets like that. Sometimes I think we fail to maintain
civility because people commonly mis-interpret lack of understanding
as violent disagreement...


This is another advantage of using modern tools which assist with your
development by providing syntactical cues and even feature summaries
as you're typing your code. We could get this code completion for MV
and I believe there is some product that does this - outside of the
environment of course. As it's being discussed I see no difference
between MVOO development in ED and JavaScript development in Notepad.
This has nothing to do with the merits of OO itself, I think Simon was
just commenting that as long as we were using OO we might as well be
using an IDE for writing code that other OO developers use like :
Eclipse, Visual Studio, and a hundred others. Any OO developer who
tried to use ED for OO development would immediately feel like he
stepped back in time.


Sorry but this is the way OO works.

Huh? I didn't say do the write in a non-mv language. I'm saying if
you're going to use MVOO then you should invoke MVOO class functions
on MVOO objects and not manually write objects to files. Objects are
generally responsible for their own behavior. If you don't code it
like that then you're writing procedural code around objects being
used simply as "thick" variables. In OO this is just another data
type, often referred to as a Struct which includes properties only and
no behaviors.


What? We are SO disconnected here and once again I think this has to
do with your lack of understanding of the concepts being discussed.
Logic has nothing to do with the language being employed. The
language and its capabilities helps to determine where logic is
placed. If you're using procedural code then you branch to the logic
you need. If you're using object orientation then the logic is in the
class/object itself and you just tell the object to do whatever it is
that it needs to do. That's call encapsulation and that's the whole
point. When I'm writing application code I don't want to know how an
order is being written I just want to delegate the responsibility to
the component responsible and I expect the job to be done.
Coincidentally I might have written that code myself and I might be
intimately familiar with exactly what an order write operation does,
but at the moment I'm dealing a specific business function I don't
need to understand the mechanics of filing an order and related
records. This doesn't just apply to file write operations, it applies
to everything that one can do with or to an order. And this is at the
core of object oriented languages - it's not "consistently ignored".

Since you're advocating the use of object orientation it would help
for you to become familiar with these concepts. I happen to agree
object orientation is a good idea in general, and if applied properly,
for MV coding. My beef is with the linear thinking that's being
applied to this discussion of MVOO. It's like I don't object to the
idea of automobiles either, but 1) cars don't eat hay, and 2) get that
damned saddle off of there. LOL


It took a lot of time for people to write the libraries for products
like PDP.NET, mv.NET, D3 Class Library, InterCall, and
UniObjects/UO.NET. Do you really believe this was done with no
knowledge of MV? Have you ever looked at the documentation for a
single one of these libraries? Do you have any idea what you're
arguing for or against here?

ATTENTION: Whomever it is who stole Chandru Murthi's PC and is
pretending to be him... When you are found you will be tortured as you
are now torturing us. Give Chandru his PC back and leave us alone.


And I'm sure you don't know why you're arguing against .NET except
that it sounds like a politically correct thing to do... Chandru, I
know my limitations and I would be completely unarmed in a battle of
wits with you on the virtual assembler or the internals of this fine
system we love so dearly. Likewise, I'm getting a little tired of
arguing details of OOP with someone who has never used it. JavaScript
only provides a hint of object orientation. Find out what it is that
you're arguing about and we can try again sometime.

We agree that poor coding habits are independent of language and not
related to use or lack thereof of object orientation. I was referring
to your original post to this thread which didn't say anything new but
re-iterated the use of Customer.Read and Customer.CUST_NAME syntax.
This is why I said we see a lot of this sort of thing but very little
about the deeper non-syntactical aspects of OO. Syntactical parsers
are easy and can change quickly, let's get beyond that. For anyone
who is really interested in object orientation in MV, we need to
discuss "the rest of it". Without good answers for the other OO
concepts this is just a lot of wasted keystrokes.

I guess I owe you dessert now for the aggravation...

T

Glen, I see where you're going with your comments. It seems like the
OpenQM initiative is somehow being advertised as the beginning of a
general MV initiative when it's not that at all. I don't believe the
code going into QM will have any impact at all on the rest of this
market any more than btree indexing or selective file hash types in
other MV flavors. My lack of enthusiasm for MVOO/QMOO is based on:
- lack of perceived need by myself and some colleagues;
- lack of interest from the average MV developer (if Joe Developer
wanted OO he would have learned VB or Java 10 years ago);
- my lack of belief that this will translate into an industry-wide
standard;
- existence of other tools outside of MV that haven't been largely
adopted.

Other responses below:

"Glen B" wrote:


I guess I resemble that remark.


How did SOA come into this? N-tier architecture is fundamental to
modern IT. There's no arguing with it, it just _is_.


Yes. I created the n-dimensional data model in D3 on which TigerLogic
was based, but no one in the rest of the market seemed interested. I
funded development of an XML engine that turned out to be a major loss
for lack of interest. (It has to be FREE damnit!)
What has XML to do with OOP?


You mean calling to a Coyote server in QM, parsing requests,
processing, wrapping in XML, and returning to a client? What has that
got to do with OO? Why is it any better or worse inside MV than
outside? How does that effort help anyone but QM users?


I'm lost (as always in this thread). What "several commercial
software add-on hoops" are you talking about? Is this in reference to
SOA? How did the subject change to SOA and why does one need "several
commercial software add-on hoops" to do web services? This can be
done for free as many people in our market have done. Why does the
argument "it's all built into QM" now suddenly carry more weight than
"it has to be free and not from Microsoft" which is a club constantly
used around here to beat me over the head? I'm sorry, but aren't
people just shifting where they're buying their features and support
from?


Now that part I understand and I somewhat agree. We should be
investing in improving the core software products. However, I think
it's counter-productive to add yet more significant proprietary hooks
in the name of improving the market. You guys aren't improving QM for
the MV market, you're trying to add cool hooks to improve QM. It's
possible that one day all the other vendors will go out of business
and only QM will be left standing, so any effort for QM is an effort
for MV ... but not today.

Backing up a moment to embedding MV in multi-tiered solutions: I think
we're far better now that we can show integration with the rest of the
world than we were when everything was in the core package.
Email/messaging systems in MV died as soon as people started using
standard e-mail clients. Many MV systems were not sold due to lack of
integration capabilities. The fact that we can integrate MV with .NET
is a marketing bonus, not a loss. D3 allows similar integration with
Java but RD is afraid to tell anyone. I wish we had a third-party
cross-DBMS cross-OS Java libary so that people would stop whining
about freakin Microsoft and just deliver solutions. Fact is we don't,
and as I keep saying "tools are irrelevant", so grab what's available
and go sell some software. Yes, we should be enhancing the MV DBMS
with admin tools and better database capabilities. Adding OO to MV is
the oft-mentioned but unintentional red herring that doesn't really do
anything to improve our position in the mainstream IT marketspace.

At the risk of digressing into what sounds like my own plug:
One of the reasons why I support mv.NET over PDP.NET is that
it is cross-platform across the entire industry. I made a mistake in
supporting PDP.NET, one of the reasons is that the only reason it's
supported with U2 is because RD wants to stick it to IBM. If it was
supported across all MV platforms I might have never looked at mv.NET.
(As it is I'm glad I did.)
I support DesignBais partially for the same reason - I like
FlashCONNECT but it only works for RD products and that's not the
broad MV-market perspective I think we should be embracing.
I like Entrinsik Informer, based on Dawn's recommendation, but
I didn't get involved with it because it's not cross-platform.

For similar reasons I think the QMOO effort is interesting but it does
nothing for the rest of the market. I'm not criticizing your efforts,
not judging QM as a DBMS, not pushing buyware over freeware, etc.. I
just don't see any industry-wide value to the discussions or coding
efforts so far in relation to MVOO. I don't subscribe to the idea
that I should change databases if I want to use a product feature like
MVOO which at the moment is QM-only ... don't even get me started
about how confusing it is that this open source project still belongs
to LadyBridge and we wouldn't be able to use MVOO with any platform
except QM, and only in for-fee commercial systems at that.

I don't care how much passion is involved. Sometimes we need better
reasons to do things.

T

Hi
I would like to consider the Pick Basic OOP debate from a different angle
and would appreciate comment on the following.

I see Objects in two distinct areas.
The first area is interfacing with the outside world. In this area they are
imperative. What can be achieved with something like Briz objects is
mind-blowing and I see no reason why any other set of objects aimed at the
interface between Pick and Windows or even Apple for that matter should not
be embraced.

The second area is within Pick itself. This is the area where there is
considerable room for doubt and a lot of misconceptions. I wish to put
forward two items from within my own Application suite for comment taking
the view that these Pick objects are a viable concern and not just elegance
for the sake of it.

First I use a 3rd party btree handler for several reasons - cross platform
performance; reliability, unlike Universe which in my experience defoliates
at random; it is a far more elegant solution than the awful D3 algebraic
interface. I consider SuperB to be an object although it is called a
subroutine. WHY? Because I last looked at Btree theory circa 1988, I have
no idea which algorithm Ross Ferris used and even less interest. We send
his subroutines a set of parameters and it never fails to send back a proper
result set. SUrely this is all that an object does.

Second I am a great believer in standardisation, be it user interface or
programming method. Therefore all our programs use a standard common area
with all the application file handles available wherever needed; a standard
work area for passing information that is automatically allocated to named
variables at each call of the program; standard edit routines etc. Plus we
always refer to variables by name normally through the use of Dim and Equ.
We also use a standard subroutine wherever possible such as when setting up
for a print job. THe major part of an Oil Distribution system is pricing.
We have one standard routine which is used everywhere. The call passes some
30+ elements that any calling program has gathered as it checks the Debtor
controls, the delivery controls, the product and Pack controls etc. Some 45
elements are returned ranging from invoice value through price, taxes,
delivery charges, area margins etc. Nobody calling this routine needs to
know how the calculations are arrived at they just accept the result.
Surely this is an object. It needs to be superfast as effectively all
normal data entry is using it.

If I take the example of a business object that we have been given then as I
understand it. THe Price object will take it upon itself to gather again
the Debtor, Address, Product, Pack information that the calling program has
already gathered. Furthermore it will have to be embedded within the
calling program otherwise how will it retain its state and not recalculate
for every single item it needs to return - remembering there are 45. I am
ignoring the discussion of Dim versus String extraction as I am assuming
that within the object at least Dim will be the norm.

Please show me where I have misunderstood the concept of a Pick object
because if it is good I will use it.

Peter McMurray
"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Tony Gravagno wrote:
IIRC the jScript compiler only works server side, not out on the
client. Somewhat a "shame" when I discovered that (after hanging out
for 12 months)

I will wait for the inevitable shredding by other(s) to respond. Have you
got your flame suit on yet?

"Peter McMurray" <excalibur21 (AT) bigpond (DOT) com> wrote

I am most definitely not an authority on this but I'll have a go
anyway...

I would say that what you describe as an object is more of a "black
box". From what I read about objects, in the context of the Common
Object Request Broker Architecture and the Document Object Model, an
object is defined according to the framework in which it operates. All
objects within that framework are defined as having a subset of a
limited number of properties and methods. In the Pick context this is
like having a single "driver" program that can call any subroutine, but
always with the same number of arguments - a common interface. You
could liken this to a framework in which you tell the driver which
subroutines to call (the "methods"), which arguments to pass it (the
"properties") and whether the arguments are to be by reference or by
value. All of these "things" (parameters) can be defined for a "class"
- which is roughly equivalent to an extended dictionary. The
"by-reference" arguments are a bit like n(dictname) references in
A-correlatives and the "by-value" arguments are like "literal" values.

I'll stop there for now. It's very late, and I've a feeling that my
understanding of this subject is, as I said, somewhat less than
authoritative. Anyway - thinking of a dictionary item as a fledgling
"class" seems a reasonable starting point.



Cheers,
Mike.

PS. G'day Luke. How'm I doin'?


Peter McMurray wrote:

Tony:

As I've said before, it seems the communication difficulties here are about
OOP being described in OOP language instead of in English (pun). :-)

Many of us in the MV environment are business people who know what we are
doing (businesswise) and use Pick to computerize that which we know in order
to improve/maintain profitability. We are business people!

To this end, many applications that have been written by people like me have
deficiencies to one degree or another. Reading the MV coding critiques in
CDP over the years has done much to improve our understanding, and use, of
IT concepts and improved the code we use and maintain on a daily basis.

When you speak about OOP, and use business examples we all understand, like
you have in previous entries in this thread (remember the Order
header/detail, Customer, Products, Terms example) the first thing you
usually get is: "you can do the same thing in Pick if you do .....". This
is not, IMHO of course, an impolite response but one grounded in a common
human language. Pick is very good in translating its concepts back and
forth into our human language of business and English (in my case). OOP is
not, as you can tell!

I've noticed that, as with any relational debate, when the debate gets a
little heated the description of OOP always reverts to the language of OOP;
interitance, encapsulation, objects (everything is), etc. :-) It is
generally difficult to describe concepts we're all familiar with in a
language that doesn't use the logical constructs of our experience. We all
know what an order is. We all know what it takes to generate an order and
what that order needs to update. What is difficult is to understand,
sometimes, is what OOP gives us that creates a better way to generate and
update an order than what has already been created. Being business people
we're always looking at the "bottom line" and can't quite figure this out,
so, hopefully, my ignorance will be forgiven. :-)

From my perspective, as an MV toolset user, there are a number of things I'd
like to see improved in the MV environment by either the MV vendors or
others. Believe it or not, I think what you've been saying and what Chandru
has been saying is very similar to me in the sense that you both would like
to see improvements within the "core" MV environment and would like easier
access to external IT resources.

I'm mostly interested in a more "logical" mapping of IT concepts and
structures to the business environment so "I" can build solutions. For me,
that's what MV has been all about. Moving to "n-tier" architecture using
OOP languages and 3rd party implementations of this, that, and a lot more,
requiring me to hire dbms administrators, UI developers, network
administrators, etc, just to get an application developed and running, is
not the direction I'm interested in. You've noted this and so have a number
of others. Those items most interesting to me, but certainly not to others,
has been the leveraging of the MV structure, dictionaries and BASIC, to more
easily accomplish some of the concepts of OOP (or "good practices"
generally) by someone like me, who knows the business I'm trying to run.

As I work with .NET, I notice it's very difficult to accomplish simple
tasks, as many business process are simple tasks. Basic things like I'd
like to keep a variable in scope are mind-boggling complex within the OOP
structure (the layers and layers of abstraction seem more designed for
obfuscation than for clarity). So, for me anyway, keeping most of the
business rules on the dbms server, within the dbms, is the simplest. Using
external routines like encryption and email available on the server, rather
than rewriting in BASIC, seems the simplest. Using the UI, and its
attendant toolsets, to interface with users seems the simplest. Using some
kind of "core" MV connectivity, to tie the UI with the business tier, seems
the simplest.

This thread has been facinating and I wouldn't classify it as tilting at
windmills nor as a bunch of MV people disagreeing. I'm included to view it
as healthy debate. :-)

Bill

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Hi
After years as a volunteer bush firie I am immortal mate. I did forget to
say that Ido know about inheritance et al but we are talking about Pick
implementations which is not an OO language. I really do want someone to
show me how a real world situation can work in Pick.
Peter McMurray

"murthi" <c_xyz_murthi (AT) seeing_xyz_green (DOT) net> wrote

Hi Mike
You just described my 4gl approach. One driver with a standard interface to
standardised subroutines - everything in my suites is a subroutine
controlled by the driver the only difference I produce standard code so that
it is not hidden. It was interesting going through Cache I found myself
saying Oh! thats my global dictionary, or that's my process definition, or
that's my file definition etc. So I am getting somewhere I now have a CORBA
definition for what I do.
Peter McMurray
"Mike Preece" <michael (AT) preece (DOT) net> wrote