In our previous episode, Santiago A. said:
> >
> > A different route would to fix that (like Modula2 or "qualified" importing
> > like in again M2 but also GPC).
> My two cents:
>
> Whenever there is a conflict, an ambiguity, you must full qualify the
> identifier otherwise the compiler will compl
On Tue, Oct 11, 2016 at 11:57 AM, Santiago A. wrote:
> Being aware of the order is a workaround that works, but it doesn't mean
> that relying on the order is the best idea.
Of course, no doubts about it.
Regards,
Marcos Douglas
___
fpc-pascal maillist
El 11/10/2016 a las 14:15, Marcos Douglas escribió:
>
> But what I do, for years, is import my units using an order by
That's what everybody does, otherwise you run into a troubles.
The problem is when you change the order unnoticed
The problem is when you use non standard packages and you don't k
On Tue, Oct 11, 2016 at 7:21 AM, Santiago A. wrote:
> My two cents:
>
> Whenever there is a conflict, an ambiguity, you must full qualify the
> identifier otherwise the compiler will complain.
> For the special cases, when you need to hide the declaration, you could
> use the directive "override"
El 11/10/2016 a las 10:03, Marco van de Voort escribió:
> In our previous episode, Santiago A. said:
>> I think that "automatic overriding" is a wrong design from the first
>> turbo pascal and should be fixed. The need of overriding system
>> functions like memory managers is a corner case to treat
In our previous episode, Santiago A. said:
> I think that "automatic overriding" is a wrong design from the first
> turbo pascal and should be fixed. The need of overriding system
> functions like memory managers is a corner case to treat, not a reason
> to not solve the unexpected hide of declarat
El 05/10/2016 a las 9:23, Graeme Geldenhuys escribió:
> On 2016-10-05 08:11, LacaK wrote:
>> Now I understand what happens, but isn't it bit confusing ?
> Yup, I would agree, and if possible, one should be removed.
Yes and no.
Yes, probably in this case one of them should be removed, but the reas
One problem is, that documentation of SysUtils.LowerCase is not correct
regarding to System.LowerCase
http://www.freepascal.org/docs-html/rtl/sysutils/lowercase.html :
"... It is completely equivalent to the *lowercase function of the
system unit*"
But another problem, which I have pointed out
On Wed, 5 Oct 2016 09:11:51 +0200, LacaK wrote:
>writeln(LowerCase(US)); // prints ÁÉÍ
>writeln(UnicodeLowerCase(US)); // prints áéí
>
> Why first LowerCase() does nothing while second wroks as expected?
>
SysUtils.LowerCase is only supposed to work on ascii characters.
From manu
On 2016-10-05 08:11, LacaK wrote:
> Now I understand what happens, but isn't it bit confusing ?
Yup, I would agree, and if possible, one should be removed.
Regards,
Graeme
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freep
10 matches
Mail list logo