Re: A new paradigm

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:
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@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:gkmdc25lhgdeosnmefaiqo7df8kfadttgp@xxxxxxxxxx
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:


There sure are a lot of market biased opinions on this thread. It seems
like there is a struggle here, which I thought I'd never see. For once, in
several decades, there is an open and commercially supported effort to
extend and enhance the MV environment. However, it seems like the biggest
supporters I would have betted on are whining(not worth calling it
arguing)
about how useless OOP is in BASIC.

I guess I resemble that remark.


If you think that SOA is going to
continue to run happily along side of the current MV BASIC, then think
again.

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


Has anyone given any thought of XML processing _within_ and outside
of BASIC?

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?


It makes a lot of sense, to me anyway, that OOP in MV BASIC will
greatly ease the move from tiered SOA to direct SOA.

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?


Does that mean
circumventing all of Microsoft's toys? No, it just means that no one will
need to jump through several commercial software add-on hoops to make
those
things work directly with core programs.

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?


Yes, this definately means a shift
in our software market. No, it isn't going to happen over night. However;
the more we forcefully embed our market into multi-tiered solutions, the
more reluctant we will be to enhance our own root product. That's truely a
shame. It's also a large reason why we're still not the "preferred brand"
of
database.

Glen

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

.

Relevant Pages

  • Re: A new paradigm
    ... First I use a 3rd party btree handler for several reasons - cross platform ... Therefore all our programs use a standard common area ... but no one in the rest of the market seemed interested. ... people just shifting where they're buying their features and support ...
    (comp.databases.pick)
  • Re: A new paradigm
    ... One driver with a standard interface to ... standardised subroutines - everything in my suites is a subroutine ... First I use a 3rd party btree handler for several reasons - cross ... but no one in the rest of the market seemed interested. ...
    (comp.databases.pick)
  • Re: Tiger Stock
    ... Agreed but small thinking is what is killing this market. ... and Reality scale easily for enterprise ... particularly for vendors who only want to support one DBMS. ... and I'm citing the many reasons for doing so. ...
    (comp.databases.pick)
  • Re: IEEE support
    ... I think the purpose of IEEE support in standard languages ... is to support whatever the hardware supports in a standard way. ... market could have ignored them. ...
    (comp.lang.fortran)
  • RE: 24 bits WAV file
    ... and every format on the market but not one of the most basic, standard WAV? ... > The fact that MP doesn't support standard 24 bit WAV is really strange. ...
    (microsoft.public.windowsmedia)
Loading