checks in property setters.
On Fri, Dec 28, 2012 at 7:33 PM, Mark Morgan Lloyd
wrote:
> JC Chu wrote:
>>
>> It is not possible to extend an enumeration type. If you are not
>> willing to use separate sets to hold common and extended elements, you
>> can use a generic (not pa
nions above are the author's, not those of his employers or colleagues]
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best regards,
JC Chu
___
fpc-pas
cendant-s-overriden-method-property-tp5711994.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
itself, you can modify it).
--
Best regards,
JC Chu
*From:* bsquared
*Sent:* November 7, 2012 9:37
*To:* fpc-pascal@lists.freepascal.org
*Subject:* [fpc-pascal] Questions About Porting Java and Extended Class
Syntax Features
Hello,
I am looking into porting Java to Free Pascal. I have
” can _only_ be user-defined because it is undefined in the
default interpretation---there’s no ambiguity to the reader unless the
writer use operator overloading irresponsibly.
--
Best regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepasc
) each
enumeration member x in the expression, where x must belong to the
enumeration type being declared, and must appear before the member
it’s used to define.
Since this weakening happens only within enumeration definitions, I
think it should be treated specifically.
--
Best regards,
JC Chu
Our end-of-semester rushes usually take 2 weeks. Anyway I’m hoping it’s
going to be tested (I did for i386-win32 and x86_64-win64) and applied
asap. :(
--
Best regards,
JC Chu
On Jul 12, 101 R.O.C., at 23:32, Sven Barth
wrote:
Am 12.07.2012 12:20 schrieb "JC Chu" :
>
> I
regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
obstacle, however, and can be
relaxed very easily.
The patch will soon be added to the bug report at
<http://bugs.freepascal.org/view.php?id=22359>.
On Tue, Jul 3, 2012 at 9:28 PM, Jonas Maebe wrote:
>
> Sven Barth wrote on Tue, 03 Jul 2012:
>
>> Am 03.07.2012
quot; directory for comparison)
Could you elaborate on that? Do I need to run the test suite with the
old compiler first?
--
Best regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
hould be allowed as well out of
> consistency, shouldn't it?
>
> Nevertheless for pointers one needs to be careful, as I don't know exactly
> how far internal pointer arithmetic operators are available (AFAIK at least
> "+" and maybe "-" exist).
--
Bes
rand case to allow for (PChar, string)
overloads, so * as a function on (PChar, string), despite legal, still
gets rejected.
That is to say, the rules in internal_check() are not yet exhaustive.
On Tue, Jul 3, 2012 at 3:35 AM, Sven Barth wrote:
> Am 02.07.2012 16:51 schrieb "JC Chu&qu
by default is not good.
> It's too easy to miss something (because there is no formal specification of
> the language anywhere), and then in subsequent releases you may have to have
> to break existing code because you have to disable certain overloads again.
--
Bes
n, Jul 2, 2012 at 7:37 PM, JC Chu wrote:
> Anyway, here’s a patch for reviewing…
--
Best regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
.
>
--
Best regards,
JC Chu
htypechk.pas.patch
Description: Binary data
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
ain inline
> operators are already in place. I don't know their exact rulings, but
> ordinals (Integer values, floating point values), enums and sets are a bit
> restricted regarding overload (especially if it is a binary operator where
> left and right is of such a type).
--
?
Thanks.
--
Best regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
t; Ido
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
s-than operator. But they are not. In my opinion, fpc
> should not take the declaration as a statement then try to search for
> the nonsense operator-overloaded methods.
--
Best Regards,
JC Chu
___
fpc-pascal maillist - fpc-pascal@lists.freepas
Notice the {$MODE DELPHI} directive.
On Thu, Apr 26, 2012 at 17:24, Lukasz Sokol wrote:
> On 26/04/2012 10:14, JC Chu wrote:
>> It fails because the operators < and > are not defined for TObject,
>> which is assumed by TFPGMap.KeyCompare().
>>
>> As a makeshift y
)
>
> Any way to resolve it?
> ___________
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal
--
Best Regards,
JC Chu
{$MODE DELPHI}
uses Fgl;
type
TObjectRec = record
Value: TObject;
and still retain total type-safety
> RegisterCallback(CastMyCallback(@MyNiceCallback), D);
> end;
>
> begin
> Run;
> end.
>
> This has an overhead of only 4 code lines (the CastMyCallback
> function) and only once for all my differen
TWidgetSet.PromptUser(), and that is why TApplication.Initialize() is
needed.
On April 26, at 00:04, Jürgen Hestermann wrote:
> JC Chu schrieb:
>> Try this.
>> program Test;
>> {$MODE DELPHI}
>> {$APPTYPE GUI}
>> uses
>> {$IF Defined(UNIX) and Defined(UseCThreads)}cthreads,{
23 matches
Mail list logo
