Path: news.mathworks.com!newsfeed-00.mathworks.com!kanaga.switch.ch!switch.ch!newsfeed00.sul.t-online.de!t-online.de!news.k-dsl.de!aioe.org!not-for-mail
From: dpb <none@non.net>
Newsgroups: comp.soft-sys.matlab
Subject: Re: Last drop in a user's patience
Date: Tue, 18 Nov 2008 14:29:41 -0600
Organization: Aioe.org NNTP Server
Lines: 51
Message-ID: <gfv8rm$vet$1@aioe.org>
References: <gflcij$3rm$1@fred.mathworks.com> <d1e62298-ffa0-446d-bd51-78932c271033@z28g2000prd.googlegroups.com> <gfqrj9$alu$1@fred.mathworks.com> <9edd631a-9cfe-4f66-8bf7-358f62773b69@o40g2000prn.googlegroups.com> <gfseb3$akf$1@fred.mathworks.com> <gfsgc3$rmp$1@aioe.org> <gfv5cl$cas$1@fred.mathworks.com>
NNTP-Posting-Host: 1RwJB80o2V5XTdF6aVs/eQ.user.aioe.org
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: abuse@aioe.org
NNTP-Posting-Date: Tue, 18 Nov 2008 20:33:59 +0000 (UTC)
X-Notice: Filtered by postfilter v. 0.7.4
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
Xref: news.mathworks.com comp.soft-sys.matlab:501556


Gadi Reinhorn wrote:
...
> To address issue (1) and for consistency in issue (2) we introduced the MEX 
> extension ".mexw32" for Windows 32.  For backwards compatibility we left 
> ".dll" as a secondary MEX extension.  We felt that leaving this 
> functionality for a few years and slowly phasing it out was a soft rasition 
> for users.
> 
> The main reason we have slowly moved to removing the use of the DLL 
> extension is that in order to continue innovating we are always looking for 
> ways to improve our code base.  We carefully balance performance 
> improvements and features with quality and compatibility.  In this case we 
> feel we can simplify our infrastructure by removing this functionality. 
> Since we strongly encourage users to rebuild their MEX-files every release, 
> we believe that by now ".dll" MEX-files are starting to become obsolete.  We 
> have been thoughtful and careful about this process.  We have also attempted 
> to be transparent.  We have been warning about this transition for several 
> years and are now approaching the final stages.
> 
> I hope this explanation clarifies why we have gone down this path.
...

In part, yes.

1) is result of namespace pollution that's a major weakness of the ML 
design.  I don't see much way at this late date to solve it and suspect 
it is only going to continue to get worse as more and more functionality 
is added.

2) is, of course, the dilemma of any upgrade path that has compatibility 
issues.  I'd only note as a rough comparison the path Fortran has taken 
of deprecation/obsolescence followed by removal from the Standard at a 
later revision is the same general philosophy.

However, the significant difference is that the Fortran Standard is an 
independent document and there are multiple implementors/implementations 
of the Standard for end users to choose from.  It is up to the compiler 
vendor to decide when (and whether) to actually remove functionality or 
not.  Most have not done so except for some very arcane features that 
are simply totally incompatible w/ newer, more popular features or a new 
compiler entirely that did not exist prior to a more recent Standard. 
This path leaves the end user w/ much more flexibility in choosing 
precisely how going forward suits their own operation than does the 
single-vendor choice.

It would take far more inside information than I have access to (and 
more time than I have to devote to the issue even if I had access) to 
make a full argument; I only note here the comparative paths for 
consideration.

--