Interesting certainly, but i am not sure it is a path i would go down.
I, like many mv developers, have employed oo like techniques in
databasic for some years, but i remain to be convinced that there is a
need for a fully oo databasic language. If you need oo use an oo
language, if you need an ide there is an eclipse plug in, the
unidebugger etc ...

Symeon wrote:
That's my position as well. Adding objects to standards-compliant (or
sorta standards-compliant) languages is the way to go. Code in Java (or
C++ or C# or ...) with objects to handle all the MV structures.

Cheers,
Luke

SteveB wrote:


It depends what you mean by retaining the "flavour" of MV. If you just
mean BASIC-like syntax then why not user another variant of BASIC (e.g.
Visual Basic).

If, however, you want to move to a more contemporary language, but be
able to program rapidly, then why not use one of the dynamically typed
scripting languages such as Ruby or Python. I am sure you will find
them more expressive than Pick-BASIC - for example they support much
more powerful collections than the delimiter separated strings that are
in Pick-BASIC - and they are also relatively easy to learn.

Cheers
Anthoyn

Symeon wrote:

How do you do that? I am curious - since I use Pick BASIC a lot, and
find it to be a very productive scripting language, but its complete
lack of user defined data types (including encapulation and
inheritance) make me tear my hair out sometimes.

The OpenQM product has OO programming as part of the standard QMBasic
language. This is therefore fully integrated, fully debuggable with the
same tools, and can use all the same language concepts that are used in
non-OO programs.

No retraining, no need for extra skills but some really interesting
possibilities for simplified application design.


Martin Phillips, Ladybridge Systems

None wrote:

I just took a look at the QMBasic documentation. If I understand
correctly, it supports two concepts:

(1) Encapsulation of state and behaviour in a CLASS declaration
(2) Creation and deletion of CLASS instances

This is a good start, but there is a lot of stuff missing that is
essential to OO development. Notably:

(1) I could not see support for inheritance, which is a serious
omission
(2) I could not see any form of type-determination for a given
"object". There are two ways to do this: [i] Static type declarations
of variables; [ii] Reflection - wherein you can ask a variable its
concrete type

Cheers
Anthony

I think many of us see Databasic as more than just a scripting language
- on the oo front we use oo principles within our design. One example
is i have a standard routine for all file operations
(open,read,write,delete,select etc), this includes BCI (i.e. MySQL),
XML, Sequential and U2. I then have an include per file (table, xml
instance) that equates {filename.method} to call the function
e.g. EQU CUSTOMER.open TO FileOperation("CUSTOMER",O,BLAH,BLAH) etc.
we can then add properties like CUSTOMER.name as equates.

This means we can really standardise our code, no one does any opens,
reads,writes, refering to records using attribute numbers etc and the
programer does not care if it is an xml file, a database file, a SQL
file etc. Code looks like
IF CUSTOMER.open THEN
CUSTOMER.id = "0001"
IF NOT(CUSTOMER.record.read) THEN blah ELSE CRT CUSTOMER.name

You can also do other eqates for derived properties say for encryption
EQU CUSTOMER.decryptPassword TO CryptFunc(CUSTOMER.password)

Just one example of a few techniques you can use to make your code look
more oo. IT also gets the developers into the mode of talking of
methods and properties so they can converse easier with the oo guys
doing the ui etc. - NO we are not doing true oo here, NO there is not
particularly inheritance polymorphism etc. However you are at the end
of the day reading and writing MV data and applying business logic to
it. oo has limited use in that environment especially as databsic has
all the tools you need to extract and analyse such data.

Steve - You may want to talk to some of the old SB+ guys about a
project they did a while back called "DATA C" I believe it was C with
extensions for MV and databasic. IT was never marketed and only ever
used internally (to develop SB Client perhaps) I used to have some docs
on it but that was several hard disks ago...


rgds
Symeon.

Symeon wrote:

I use scripting language not in the older meaning of a shell-scripting
language in unix, but in the more contemporary meaning of a
non-statically typed high-level language that is low on ceremony and
high on productivity.

Yikes ! OO brings tremendous advantages at the business application
level, since you can build a domain model in the OO language that
reflects the language the business folk use when talking about their
business domain. The main emphasis being on reflecting the abstractions
therein. You are right that you can use code without direct reflection
of domain-specific abstractions, but then the mental burden of mapping
between the business domain and its reflection in code is much greater.

I like Pick very much - it is an extemely simple filing system and easy
to use programming language - and for many situations these are
sufficient. Without more direct support for abstraction, though, your
system architecture become shaped around the solution implementation
rather than the business domain it supports.

I studied a number of large scale application as part of my PhD (which
focused on how to tackle legacy systems) and found that many Pick
applications were very quick to develop but over the years aged
disgracefully. The main problem I found with Pick applications is that
folks were unable to distinguish in the application code (apart from
random explicit comments) how the implementation mapped to the business
domain. This encouraged waves of hacking (localised changes violating
implicit abstractions) which over time made the systems unmaintainable
(other than by a fearless few).

One of my big disappointments is that folks often talk about how
quickly they can develop an application in Pick - and I have seen this
to be true. At the same time, the lack of contemporary language and
database principles explicitly supported in Pick I worry deeply about
Pick applications lacking the malleability need to reflect ongoing
requirements changes. Typically, I see Pick-based applications falling
further and further behind the evolving requirements, until most of the
developers' time is spent on "fire fighting" and little on moving their
applications forward.

Symeon wrote:

For many years, I was in charge of the development of UniVision. This
was developed in C++, and naturally we included all the Pick-BASIC like
features directly in C++. This meant it was possible to develop
business applications in C++ quite readily, however, it demanded a much
higher level of competence that programming in Pick-BASIC. In short,
the folks who could cope with C++ didn't need the concepts we added,
and the folks who needed the concepts we added couldn't cope with C++.