Nothing as elaborate - But we have a skeleton for something less
sophisticated :
define new type a1 as record
tabid integer,
tabname char(18),
nrows integer,
rowsize integer
end record
define a as a1
When I just tried it - it didn't work - so I'll need to check why...
As for the comparisons etc. - these are a lot more difficult and I can't
really see the point for complex types.
Anyway - if you head down that route then you'll have OO4GL by default...
You could have something along the lines of :
define new type a1 as record
tabid integer,
tabname char(18),
nrows integer,
rowsize integer
end record
function aaa ()
..
end function
end type
etc if you want to move to a more OO system..
define a as a1
Anything along these lines will probably have to wait quite a while though....
(One thing I would like to introduce though is the ability to add datatypes
at some point. I'd love to add the GMP datatypes/functions in (see
http://www.gnu.org/directory/gnump.html ).
On Saturday 20 April 2002 1:45 am, Andrej Falout wrote:
> Hi *,
>
> here is something that might be of interest in context of RPC-XML.
>
> It can be considered FYI, or as provocation for discussion, you choose.
>
> I'm forwarding it with authors kind permission.
>
> Yours, Andrej Falout, http://www.falout.com/disclaimer.html
> Visit the OpenSource alternative, Aubit 4gl:
> http://aubit4gl.sourceforge.net PLEASE NOTE: All HTML email sent to me WILL
> BE DELETED AUTOMATICALLY WITHOUT READING.
>
> -----Original Message-----
> From: owner-fourjs-users@... [mailto:owner-fourjs-users@...
> Behalf Of Gerald Keil Sent: Friday, 19 April 2002 22:12
> To: fourjs-users@...
> Subject: Re: [fourjs-users] Howto Handle XML-Files??
>
>
> Hello David,
>
> I am beginning to understand (and appreciate) your point of view.
>
> First, to clear up a possible misunderstanding: when you mentioned
> "pointers" in textual proximity to "dynamic arrays" in your email of
> 10.04, you were apparently merely listing the things you, as
> power-programmer, missed in the BDL. When I read your list, I glued
> these together into "pointers to dynamic arrays" and construed a horror
> scenario of half-trained programmers creating ephemeral storage entities
> (without knowing it), retrieving pointers to them (disguised for example
> as "unsuspicious" integers), and inadvertently redeploying these later
> to access structure which had in the meantime ceased to exist.
>
> What I now think you mean is external "typedefs", the objects of which
> can be administered by the BDL but the details of whose content is of
> relevance only to an external library. Now, THAT is an idea which
> deserves the due respect which I have withheld in my last two emails.
>
> Allow me to play a while in your sand-pit: because it's fun, and because
> you can then let me know if I have really understood what you are after.
> However, I wish to turn the idea on its head and make the external types
> visible, albeit strictly in a "BDL sense".
>
> Let us assume a BDL statement such as
>
> IMPORT TYPE monoglitch [AS thing] FROM glitchlib
>
> to make an external type [and its internal alias] known to the BDL
> source code. (Beware: I am inventing syntax out of the top of my head).
> Of course it would possible to do this "invisibly" with appropriate
> wrapper conventions, but I for one would not like to write programs in a
> language whose vocabulary changes without notice. This import statement
> is (ideally) the SOLE EXTENSION to the BDL syntax.
>
> The TYPE of such an entity is logically primitive, even if in (external)
> reality it consists of a structure of arbitrary complexity. Thus
>
> DEFINE one_thing,
> another_thing THING,
>
> thing_array array [50] of THING
> ...
>
> LET thing_array [5] = another_thing
>
> { and so on }
>
> makes no assumptions about the structure of an object of type THING,
> treating it as a "black box" which can be opened and whose content can
> be understood only by appropriate (C-) library functions.
>
> Similarly, the definition of logical relations involving objects of an
> imported type must be undertaken by the external library and made known
> to the BDL (perhaps via the IMPORT statement). Thus
>
> IF one_thing > another_thing
>
> must be detected by the BDL and handled appropriately.
>
> An object of an external type would probably NOT be or contain a
> pointer, i.e. a physical storage address. It may well be or contain a
> reference to an element in a table of pointers whose contents change
> from time to time, for example at every program start. Such a
> reference can be positional (e.g. one smallint per table dimension) or
> symbolic (resolution via a binary tree). I use both methods in bedrock
> libraries.
>
> A scheme such as this comes closer to what I understand under
> "transparency". A BDL programmer whose only concern is to shunt data
> need know nothing more about THING than he already knows about INTEGER,
> DECIMAL and the like.
>
> There are restrictions, of course. PRINT (and expecially PRINT USING)
> would for example probably not be possible: instead, external coersion
> functions would have to deliver components (improper subsets) of
> external objects as normal integers, strings etc., which could then be
> handled by the BDL in the usual fashion.
>
> Similarly, non-trivial assignments such as
>
> LET one_thing = one_thing + 5.48
> or even
> LET one_thing = one_thing + another_thing
>
> would probably be taboo. Restrictions are of course in principle a pain,
> because they decrease the orthogonality of the language. (But that
> consideration hasn't stopped 4GL in the past ...)
>
> The matter gets difficult when SQL is involved. Just the thought of
>
> CREATE TABLE glitch_objects (cust_num INTEGER, cust_thing THING)
> or
> select * into another_cust_num, another_thing [i]
>
> makes me a bit dizzy, but (to quote Shakespeare in /The Merchant of
> Venice/), "4J's is made of sterner stuff".
>
> Am I getting nearer?
>
> Gerald.
> __________________________________________
>
> "David N. Heydon" wrote:
> > What I was thinking of was quite safe and simple from the 4GL
> > programmers perspective, since they would only be dealing with the usual
> > 4gl datatypes. The only complexity for the programmer is in the
> > definition of the external function prototypes, where the target (non
> > 4GL) datatypes needs to be mapped into the closest 4gl datatype. In your
> > example (pointer to integer), the 4GL datatype would be an integer, not a
> > pointer, so its safe and normal to store. I'd agree that 4GL does not
> > need features like pointers, which is why I was suggesting this be
> > confined only to the definition of the external function prototypes,
> > which would only ever be required for interfacing directly with non 4GL
> > code.
> >
> > However that said, I do think 4GL could benefit from being able to pass
> > parameters by reference (perhaps a BYREF or VAR extension). Complex
> > datatypes like records or large strings could be passed much more
> > efficiently by reference instead of all those pushes and pops...We use
> > global records to escape the overhead, but this is something I hate
> > having to do, its risky if nothing else. Hopefully if the BDL language
> > ever gets objects it'll also get a call by reference facility.
> >
> > -----Original Message-----
> > From: Gerald Keil [mailto:g.keil@...]
> > Sent: 15 April 2002 11:10
> > To: fourjs-users@...
> > Subject: Re: [fourjs-users] Howto Handle XML-Files??
> >
> > Hello David,
> >
> > What for you is "messy and inflexible" is for me the overhead I must be
> > prepared to pay for having both
> >
> > (a) a "comfortable" BDL (4GL) with restricted features (which I
> > can safely place in the hands of newbies, for example), and
> >
> > (b) a veritable Turing machine, which however can be lethal in
> > the wrong hands.
> >
> > Your idea is to build a three-lane bridge over this gap. I have my
> > reservations. The exclusion of dynamic storage and pointer manipulation
> > from the BDL syntax is, in my opinion, consequent with its placement as
> > a business language. The real challenge of linking (a) with (b) lies not
> > in the mechanical interface, but rather in the "logical wrapper" which
> > reexpresses level b functionality as something useful and understandable
> > to "normal" level a programmers.
> >
> > Given (in the name of transparency) an automatic type conversion which
> > effectively disguises pointers as integers, for example, one ought not
> > be suprised when some unwary application programmer stores the result of
> > such a conversion in a database record and tries to use it again a week
> > later. Better: the functional interface should deliver information in
> > conformity with BDL semantics and keep its internal data management
> > details to itself. This is "transparency" in a useful sense; but it
> > cannot be mastered simply with a newer and better C/4GL interface, for
> > it generally requires a unique solution for each new problem.
> >
> > Gerald.
--
Mike Aubury
|