RE: My not-quite obsolete namespace parser
You didn't explain why / is recognized as being different, when the
meaing is clearly the same thing. I understand the logic for
differentiating bewteen the two. If that is going to be done, it should
be enforced, not quietly allowed, but not fully supported, what's the
deal with that? It seems irratic to me.
You mention the suppression of duplicate includes, but the behaviour is
inconsistent.
For over a year now it has never even crossed my mind that I shouldn't
be using /. Eu doesn't complain, or even warn me that it will be
evaluated as a separate include. Instead I spent days trying to figure
out where my code was broken. For a long time I thought I just couldn't
use relative paths.
Even upon mentioning the problem on the list numerous times, noone
answered my dilemna.
What ambiguities? When eu encounters include, and the platforn is not
LNX, either allow only \, or convert / to \.
I wouldn't care if the support for / were removed, except that it would
break code. The other option is to make the behavoiur consistent, which
wouldn't break any code, and would be alot less confusing.
Chris
Robert Craig wrote:
> Chris Bensler writes:
> > What is the reason that eu DOS/WIN can't use '/' just the same as '\'?
>
> In general, you *can* use '/' just the same as '\', even
> though it is clearly not the convention on DOS or Windows.
>
> The thing we are quibbling about here,
> is the suppression of duplicate include files,
> where you should use the standard '\'
> on DOS/Windows to avoid ambiguities
> in rare situations, e.g. .\foo.e will look like
> the same file as foo.e and won't be included,
> but ./foo.e will look like a different file and will be included.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
|
Not Categorized, Please Help
|
|
