Re: Wanted:MAIL.MAI structure definition

Tom Linden wrote:

As I said, it was just curiosity. If there is not a compelling reason to
keep something proprietary, then starlet it. There, I created a new verb.

I'd flip that over. If there's not a compelling reason to share a particular interface -- to render the interface public, or at least to allow some sort of sharing -- then keep the interface private.

Opening any arbitrary interface runs contrary to the typical opacity of the internal interfaces and of application modularity and of long-standing programming practices. And it makes the usual and expected application compatibility far more difficult to achieve and to maintain.

If I had the cycles to re-implement MAIL all over again, for instance, we'd be using XML and/or a relational database, and some of these pieces would be (far) more visible. But opening up traditional internal APIs or database file organizations to visibility obviously invites folks to use the APIs, and this is access is most definitely a two-edged sword. With XML or a relational database -- or a way to export to same -- maintaining compatibility is easier, and defending against corruptions -- whether in the code, or in something that a programmer has hooked into the interface -- is easier.

There have been changes to the naming of various MAIL files over the years, for instance, and there are definite limits to the current MAIL design. If we open the database API, we effectively codify the current design in concrete, and make it far harder (if not impossible) to re-work these interfaces and these designs compatibly.

If there are particular requirements not met within the existing interface(s), then these should be addressed through callable MAIL or similar extensions. Opening up the internals of an arbitrary hunk of code serves no purpose, and (in my experience) tends to cause problems for everybody involved. I've ported code, for instance, that expected modifications directly to the underlying operating system in support of the application code -- kernel patches. Shudder.





.

Relevant Pages

  • Re: remove old versions of file
    ... I'm new to this and I've never developed an add-in before. ... The interface is as simple as possible, ... fit the description "properly designed software". ... I'll be in the relational database ...
    (microsoft.public.office.developer.vba)
  • Re: remove old versions of file
    ... I'm new to this and I've never developed an add-in before. ... The interface is as simple as possible, ... fit the description "properly designed software". ... I'll be in the relational database ...
    (microsoft.public.office.developer.vba)
  • Re: Wanted:MAIL.MAI structure definition
    ... If there's not a compelling reason to share a particular interface -- to render the interface public, or at least to allow some sort of sharing -- then keep the interface private. ... If I had the cycles to re-implement MAIL all over again, for instance, we'd be using XML and/or a relational database, and some of these pieces would be more visible. ... If we open the database API, we effectively codify the current design in concrete, and make it far harder to re-work these interfaces and these designs compatibly. ...
    (comp.os.vms)
  • Re: When is a function not a function?
    ... a DOM element and Array or a value with falseness. ... betrays very poor code design. ... subject of the test is expected to be any of a javascript function ... There is nothing to say that an object implementing the Node interface should not be a function object. ...
    (comp.lang.javascript)
  • Re: XP Requirement Analysis?
    ... and use TDD to force the same design to emerge. ... > These principles, used with other XP situations like pair programming, ... OK, but you need to know what that interface is, so you must do some ... to buy a business value. ...
    (comp.object)