ELKS & flat-short compatibility paradox #1 :-) 
Author Message
 ELKS & flat-short compatibility paradox #1 :-)

I hope I am wrong on this, but if not enjoy!

:-) Consider the following hypothetical candidate implementation for ELKS :-)

 class GENERAL
  ... -- as in any ELKS definition
 end -- class GENERAL

 class ANY
 inherit
   GENERAL
     export {NONE} all
   end
 ... -- the rest according to any ELKS definition
 end -- class ANY

Now then,

1) the candidate is flat-short compatible with GENERAL

2) the candidate is flat-short compatible with ANY (since the "inherit
GENERAL ..." does not redeclare anything it is outside the flat-short
conventions)

3) the "export { NONE } all" clause in ANY has the effect of making
all inherited features from GENERAL 'secret', including object_id (and
clone, copy, is_equal, ...), and making it impossible for the
rest of the kernel library to even build let alone run,

Yet this candidate implementation is ***certifiably ELKS compatible***

At least two options suggest themselves here:

A) clean up ELKS in this area, as well as the many other areas presented
in earlier postings, and hopefully by 1998 we can have an implementable
standard that is met by all vendors, and require compliance via actual
running code (i.e. a test suite, which includes compilation) before any
candidate can be labelled ETR/ETL/ELKS compliant, or

B) rush a set of classes out the door that uses this technique (and
matches the flat-short paper definition required for ELKS compliance),
and announce immediate availability of the first, certifiably ELKS compliant,
vendor independent, platform independent, ... implementation of ELKS 95.

Actually for B) we should announce its immediate availability well before we
finish typing in the paper description,  and be sure to loudly proclaim
that this widespread availability of an independent **certifiably compliant**
kernel library is a first for the entire software industry, go on about
the quick design->market times possible with Eiffel/ELKS and so on ...
Stay tuned for exciting news at OOPSLA'95.

Enough :-), back to work.



Tue, 27 Jan 1998 03:00:00 GMT  
 ELKS & flat-short compatibility paradox #1 :-)

Quote:


> |  class ANY
> |  inherit
> |    GENERAL
> |      export {NONE} all
> |    end
> |  ... -- the rest according to any ELKS definition
> |  end -- class ANY
> ...
> | Yet this candidate implementation is ***certifiably ELKS compatible***
> Let's not overreact :-).
> My reading of the standard would disallow this. Section 2.4 says that
> only the listed types of differences are permissible in order for
> class to be labeled "flat short compatible".  "Export status" is not
> one of the listed allowable deviations, so a candidate implementation
> is therefore not allowed to change export status of any standard features.

But since export status does not appear in the flat-short form, it
is not in the standard class nor in the candidate class, so there is
no difference in the flat-short forms (the tree falling with no one there
to hear it).

Here is the **certification**:

From ELKS 2.3.1.4: "A feature f from GENERAL shall be included if and
only if C redeclares f."

The definition for redeclaration in ETL is

 "A Feature_declaration g appearing in a class C for a feature
 fname is a redeclaration if and only if fname is the
 same as the final name of some inherited feature of C"

and in ETR it is

 "A class C redeclares an inherited feature f if and only if one of
 the following two conditions holds:
 1) C contains a Feature_declaration for a feature g with the same
    name as f
 2) C inherits f as deferred, and inherits as effective another feature
    g with the same final name as f"

Since class ANY contains no Feature_declaration, no redeclaration
takes place and therefore the "flat-short form" for ANY is unchanged.

As proof of concept, consider the following candidate for class ANY:

 *** start ***

 indexing
    copyright: "Copyright 1995 BKS Systems, Inc.%
        %All rights reserved%
        %Permission is granted to use this technique%
        %for education and entertainment purposes only :-)"

    background: "This candidate implementation for ELKS 95%
        %illustrates one possible paradoxical implementation%
        %that is completely compliant, flat-short compatible, and%
        %vendor/platform-independent. It is also totally useless as%
        %it renders all features in class GENERAL inacessible."

    description: "Project-wide universal properties. This class is %
        %an ancestor to all developer-written classes. ANY inherits %
        %from GENERAL and may be customized for individual %
        %projects or teams."    

 class ANY

 inherit
    GENERAL
        export
            {NONE} all
        end            

 end -- class ANY

 *** end ***

The associated flat-short form is (with comments truncated by me):

 *** start ***
 indexing
    copyright: "Copyright 1995 BKS Systems, Inc....
    background: "This candidate implementation for ELKS 9...
    description: "Project-wide universal properties...

 class interface
     ANY

 end -- class ANY

 *** end ***

The only "flat-short" difference is the additional indexing clauses, which are
allowed by ELKS95 2.4.1.10. Given that no other changes were made to any
other class in ELKS95, this candidate implementation is flat-short
compatible, and therefore certifiable.

Hopefully I can get "ELKS 95 compliance certificate # 000" to accurately
reflect the utility of this implementation :-)



Tue, 27 Jan 1998 03:00:00 GMT  
 ELKS & flat-short compatibility paradox #1 :-)

|  class ANY
|  inherit
|    GENERAL
|      export {NONE} all
|    end
|  ... -- the rest according to any ELKS definition
|  end -- class ANY
...
| Yet this candidate implementation is ***certifiably ELKS compatible***

Let's not overreact :-).

My reading of the standard would disallow this. Section 2.4 says that
only the listed types of differences are permissible in order for
class to be labeled "flat short compatible".  "Export status" is not
one of the listed allowable deviations, so a candidate implementation
is therefore not allowed to change export status of any standard features.

[ Warning to TowerEiffel 1.5 users: the version of STORABLE in 1.5 has
  just such an invalid reexport clause (possibly prompting Brian's

| standard that is met by all vendors, and require compliance via actual
| running code (i.e. a test suite, which includes compilation) before any
| candidate can be labelled ETR/ETL/ELKS compliant, or

Are you volunteering?  I think it would be _great_ to have such a
validation suite.  You can count on Tower's support in developing one.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Eiffel: Accept no substitutes.


Tower Technology        WWW:      http://www.cm.cf.ac.uk/Tower/



Tue, 27 Jan 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. ELKS flat-short compliance issues

2. long = short*short ; (short,short) = long/short

3. dBASE & Paradox Database Drivers Available for C5

4. Keep FLAT button FLAT

5. Clipper & Paradox

6. MASM 5.x & PARADOX 4.x (DOS)

7. MASM 5.x & PARADOX 4.x (DOS)

8. external asm & flat mode

9. VESA LFB & Flat real mode

10. Import & Export the flat file

11. compatibility between PWS & ISAPI C55 broker

12. CFD & CW key file compatibility

 

 
Powered by phpBB® Forum Software