Re: [fpc-pascal] Program without window but messages
As leledumbo has pointed out, you need to call Application.Initialize()
before using LCL features. The code for TApplication.Initialize() shows
that it initializes the currently active widget set, which is maintained
by the Interfaces unit. ShowMessage() relies ultimately upon
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,{$ENDIF}
>> Interfaces, Forms, Dialogs;
>>
>> begin
>> Application.Initialize;
>> ShowMessage('Test');
>> end.
>
> Yes, this works!
> Now I only need to understand why. ;-)
>
> I was expecting the "application.initialize" to create a
> window so I omitted it.
> What does the initialize routine?
> Why is it needed?
>
> ___
> 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
Re: [fpc-pascal] typesafe typecasting
D^.Foo := 5; > // this is the only way I have found to let me have my > // own types 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 different callback functions that > use the same data structure and it would completely retain strong type > safety. What do you think, is this a good idea or would there have > been an even more elegant way to achieve the same? > > Bernd > ___ > 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
Re: [fpc-pascal] Can it map class type as key?
It fails because the operators < and > are not defined for TObject,
which is assumed by TFPGMap.KeyCompare().
As a makeshift you can implement a record type to wrap TObject and
define these operators for it. See the attached file for an example.
Hope it helps.
On April 26, at 16:45, ZHANG Dao-yuan wrote:
>> program moi;
>> {$mode objfpc}
>> uses fgl;
>> type
>> tSI= specialize tFpGMap;
>> // tIS= specialize tFpGMap;
>> begin
>> end.
>
> Hi,
> I'm trying to use template in fpc 2.6.0. I can map class type as value
> as above code can be compiled. But if I uncomment the declaration of tIS
> -- map class type as key, fpc fail to compile and print out these error
> msgs:
>
> Error: Operator is not overloaded: "TObject" < "TObject"
> Error: Operator is not overloaded: "TObject" > "TObject"
> t.pas(10) Fatal: There were 2 errors compiling module, stopping
> Fatal: Compilation aborted
> Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not
> specify a source file to be compiled)
>
> 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;
class operator LessThan(lhs, rhs: TObjectRec): Boolean;
class operator GreaterThan(lhs, rhs: TObjectRec): Boolean;
class operator Implicit(obj: TObject): TObjectRec;
class operator Implicit(rec: TObjectRec): TObject;
end;
TTest = TFPGMap;
class operator TObjectRec.LessThan(lhs, rhs: TObjectRec): Boolean;
begin
Exit(NativeInt(lhs) < NativeInt(rhs));
end;
class operator TObjectRec.GreaterThan(lhs, rhs: TObjectRec): Boolean;
begin
Exit(NativeInt(lhs) > NativeInt(rhs));
end;
class operator TObjectRec.Implicit(obj: TObject): TObjectRec;
begin
Result.Value := obj;
end;
class operator TObjectRec.Implicit(rec: TObjectRec): TObject;
begin
Exit(rec.Value);
end;
begin
end.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Can it map class type as key?
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 you can implement a record type to wrap TObject and
>> define these operators for it. See the attached file for an
>> example.
>>
>> Hope it helps.
>>
>
> The OP asks for generics usage, not for the operator overload (notice the
> 'specialize' keyword).
>
> L.
>
> ___
> 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
Re: [fpc-pascal] Re: Can it map class type as key?
I’m not quite getting what you’re trying to say… Free Pascal and Delphi do have distinct syntaxes for generic type definition and specialization. You may want to consult respective documentations to clarify your understanding of the code. ◦ Delphi ― <http://docwiki.embarcadero.com/RADStudio/en/Overview_of_Generics> ◦ Free Pascal ― <http://www.freepascal.org/docs-html/ref/refch8.html> Hope it helps. On April 26, at 18:00, ZHANG Dao-yuan wrote: >> tFpGMap The form of the code is similar to a comparision expression and `<' here > looks like a less-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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Adding method dynamically to a class
Depending on what you’re actually trying to do, you may consider implementing your own invokable variant type. I found a tutorial at http://alex.ciobanu.org/?p=152. Basically, instances will be wrapped in a TVarData-compatible record, and your custom TInvokeableVariantType-derived class will allow you to intercept method calls. On Tue, Jun 19, 2012 at 8:22 PM, ik wrote: > Hello, > > Is there a way to tell in run-time that a specific function/procedure should > belong to a class ? > > For example, let's say I have the following class: > > Type > TTest = class > procedure Foo; > end; > > And I have also: > > procedure Bar; > ... > end; > > Is there a way to make at some point of my code execution, that Bar will be > a method of TTest ? > Or maybe for a specific instance of TTest ? > > Thanks, > > 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
[fpc-pascal] Custom operators for non-record types
In Delphi mode, each custom operator has to be associated with a record type, and must take or return such a record. It seems that the OBJFPC mode doesn’t have this restriction; for example, the Math unit exports a custom ** on Int64, which is a simple type. However, I’ve been unable to define operators other than ** for non-record types, even if they do not conflict with the default interpretation. Examples include OPERATOR MOD (x, m: Double): Double and OPERATOR AND (x, y: Tristate): Tristate, where Tristate is an enumeration type. Is this a bug, or is there any explanation for this? Thanks. -- Best regards, JC Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom operators for non-record types
Do you have some inside information on the extra limitations regarding ordinal, floating point, and set types? As I understand, the only limitation on operator “overloading” should be that the operator do not have a default interpretation for the operands–result type combination. The modulus operator, for example, is certainly not defined by default as (Double, Double) → Double; but when I try to define it, the compiler says it’s an “[i]mpossible operator overload”. The same goes for logical operators on enumeration types. (Although each enumeration element has an underlying numerical value, it requires the use of Ord() or an explicit cast to convert it into a numerical type accepted by bitwise logical operators.) Maybe I should start preparing for a bug report? On Mon, Jul 2, 2012 at 3:41 AM, Sven Barth wrote: > Some parameter combinations are not allowed, because certain 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). -- Best regards, JC Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom operators for non-record types
Anyway, here’s a patch for reviewing… On Mon, Jul 2, 2012 at 3:54 PM, Sven Barth wrote: > Maybe there were reasons to not allow them... You can of course prepare a > bug report or wait till one of the other developers who are more experienced > in FPC's overloading speak up. > -- 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
Re: [fpc-pascal] Custom operators for non-record types
Apologies for the previous patch which I didn’t test carefully. I’ve made a revised version which fixes the over-relaxation problem that led to a number of default operand type combinations to be treated as overloadable. ◦ internal_check() now handles enumeration, set, and floating-point types. ◦ Unnecessary restrictions on enumerations have been removed. ◦ Restrictions on the string-as-the-first-operand case have been relaxed. There may be other valid cases not covered by this fix. I’ve filed a bug report for the patch at <http://bugs.freepascal.org/view.php?id=22359>. On Mon, 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
Re: [fpc-pascal] Custom operators for non-record types
Yes. I made that error in my first patch. The new compiler wasn’t even able to compile itself… I think someone should start making a complete chart for acceptance and rejection rules. On Mon, Jul 2, 2012 at 10:51 PM, Jonas Maebe wrote: > Going to a situation where overloading is allowed 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. -- Best regards, JC Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom operators for non-record types
isbinaryoperatoroverloadable() is called once. It first calls internal_check() with the default (LHS, RHS) order. internal_check() accepts or rejects the pair only if it recognizes the pair. Only if (LHS, RHS) is not recognized, will internal_check() be called again with the order reversed. If neither (LHS, RHS) nor (RHS, LHS) is recognized, isbinaryoperatoroverloadable() defaults to False. (Besides, commutativity is a semantic property which relies on the user implementation and cannot be deduced at compile time.) Rejection rules are used to prevent conflicts with the default interpretation. The original implementation, however, rejects overloads based solely on the operand type combination, not taking into consideration the operator being used. For the string-as-the-first-operand case, this resulted in, say, * as a function on (string, PChar) being rejected, which is legal. What I did with it is restrict the operand to +, =, <>, <, <=, >, and >= (and, of course, removing the limits on the second operand being an enumeration). For some operators, only one-sided protection is necessary. For example, IN must not be overloaded as a function on (, ). For some operators, the set of accepted operand type pairs should be symmetric, and thus so should its complement, the set of rejected pairs. If acceptance and rejection rules are inconsistent, rejection becomes sensitive to the order of operands. For example, I didn’t change pointer-as-the-first-operand 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" : > > >> ◦ Restrictions on the string-as-the-first-operand case have been relaxed. > > I don't know whether you realized that already, but the > isbinaryoperatoroverloadable function is called twice: once with the order > given by the user and once with the order reversed as at least regarding the > possibility of overloading the binary operators are commutative. So the > checks for the first operand being a string indirectly also apply to the > right one being a string. > > Regards, > Sven > > > ___ > 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
Re: [fpc-pascal] Custom operators for non-record types
Yes, it should. The bottomline is that cases treated as overloadable must not be defined by the default interpretation, because the overloaded interpretation will always take precedence. This is probably why the ld.typ = orddef case is not handled by either isbinaryoperatoroverloadable() or its unary counterpart. (But it’s really not true that ordinal types always make trouble—think of * as (Char, Integer) → string, for example.) Speaking of unary operators… I did not change isunaryoperatoroverloadable() to allow NOT to be defined on Double and enumeration types. I think NOT should be allowed on all types except ordinals (which include Booleans). Our terminology seems a bit inconsistent, too, don’t you think? PChar and PWideChar correspond to pointerdef, but behaves like strings---namely they can be manipulated and compared using operators +, =, <>, <, <=, >, and >= with another string-like entity (- doesn’t seem to belong there). The original implementation for the ld.typ = pointerdef case already guarantees that both the LHS and the RHS are string-like, so it remains only to add a limit on the operator so that only those mentioned above are forbidden. The thing that worries me is that I’m not sure if the default interpretation depends on the compilation mode being used. If that is the case maybe the rules will become even more complicated. On Tue, Jul 3, 2012 at 3:51 PM, Sven Barth wrote: > So in the end "* (PChar, String)" should 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). -- Best regards, JC Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom operators for non-record types
On Tue, Jul 3, 2012 at 3:55 PM, Sven Barth wrote: > I don't know whether you know this, but: > * testing the compiler compilation (as a first step) is best done using > "make cycle" in the compiler subdirectory (optionally "make fullcycle" if > you changed something were a subset of the supported platforms is affected) I did “make compiler” in $(source)\compiler and copied the resulting executable to my scratch directory. No wonder I didn’t find out the error. (ಠ_ಠ) > * if the compiler can be compiled you should do a "make clean all > TEST_FPC=path/to/your/newly/compiled/ppcXXX" in the "tests" directory and > compare with a testrun of the same version without the modifications (it's > sufficient to copy the "log" or "faillist" file from the > "tests/output/yourcpu-youros" 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
Re: [fpc-pascal] Custom operators for non-record types
Thank you both for the tips. I have just finished the patch and tested it. The patched version gives identical test results as the trunk. The patch refines operator overloading acceptance and rejection rules for both unary and binary operators. The new rules for unary operators allow NOT to be defined on enumeration and floating-point types. The new rules for binary operators should allow for all operator overloads that do not conflict with the default interpretation (DI).* The rules were designed based on a classification of operators and operand types according to their roles in the DI, and achieved a high accuracy in the first trial. *Note: An exception is that the operator IN cannot be overloaded with the signature (ordinal, set), where ordinal is any type covered by TOrdDef, even though not all such typs have a corresponding set type. This is unlikely to become a real 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 12:23 schrieb "JC Chu" : >>> >>> >>> Could you elaborate on that? Do I need to run the test suite with the >>> old compiler first? >> >> >> * first do a "make cycle" on a unmodified checkout, then run the >> testsuite. > > > While "make cycle" is useful as a first test, for a complete testsuite run > you also need the packages. So before running the testsuite, run a "make > all" in the top level FPC directory (possibly preceded by an "rm build*" in > case make says that nothing needs to be done for "all"). > > Also, if you do this regularly and have a multicore, you can speed up things > significantly by using (replace "x" with the number of cores you have, or > the number of cores+1 if you have a slow hard drive or are performing a cold > build) > a) for the fpc make all: make all -j x FPMAKEOPT="-T x" > b) for the testsuite: make full TEST_OPT="-O2" -j x > > (the testsuite "full" target is equivalent to "clean all digest", but > written in a way that makes all dependencies explicit so that parallel > building works correctly) > > > Jonas > > ___ > 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
[fpc-pascal] Patch application
I uploaded a patch in #22359 about a week ago but I see that it’s not been applied yet. (There was something wrong in previous versions but I believe the latest one should be correct.) Since it’s been about a week, I’m wondering if there’s still something that I missed. Thanks. -- Best regards, JC Chu ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Patch application
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 uploaded a patch in #22359 about a week ago but I see that it’s not > been applied yet. (There was something wrong in previous versions but > I believe the latest one should be correct.) Since it’s been about a > week, I’m wondering if there’s still something that I missed. Patch application or bug fixing in general is not always done immediately (see for example how old some generic bugs are). A developer needs to have time to look at the patch and check whether it breaks anything. That said I myself am currently a bit busy with university related topics as it's the end of the term so the time I can spend with working on FPC is sadly limited. :( Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Incompleteness of current fix for #22860
Jonas, Regarding bug #22860 on the inability to define enumeration members using expressions containing previously defined members of the same type, the current fix does not provide a complete solution. The current fix won’t allow for valid declarations such as TYPE TMyEnum = (meA, meB = 1 + meA) and TYPE TMyEnum = (meA, meB = meA xor meA). Forbidding all of those enumeration-related overloads, however, will undo much of what the relaxation patch was intended for. The compiler should expect an integer-typed constant expression after ‘=’, with a weakened type checking that takes as Ord(x) 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 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Incompleteness of current fix for #22860
On Thu, Sep 13, 2012 at 4:17 PM, Jonas Maebe wrote: > I think one of the prime requirements to get readable code is that a > compilable expression always means the same. Other forms of polymorphism can also lead to violations of this requirement. Basically I think it should be left to the user to decide when something is appropriate. > Changing the meaning of "enum + int" or vice versa depending on whether > you're in a type definition or in regular code following an overloaded > operator goes completely against that principle. It does look ugly at first but I think it is clear (to both writers and readers) that no overloaded operators can be in effect within enumeration type declarations because 1) most obviously the type has not been fully defined and 2) constant expressions do not accept overloaded operators. > Of course, a programmer can circumvent that by defining a particular > operator in multiple units with different meanings, but at least as far as > natively supported operators are concerned we can ensure that this principle > is respected. If something like “enumeration + integer” appears in regular code, that “+” 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.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE: [fpc-pascal] Questions About Porting Java and Extended Class Syntax Features
If you need to initialize a [STRICT] PRIVATE CLASS VAR you need to do this
in a CLASS CONSTRUCTOR (similarly finalizations will need a CLASS
DESTRUCTOR). You can expose it thru a read-only CLASS PROPERTY, but there
is no way to make it a real constant (as long as you can access the
variable 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 some confusion about
how to port certain types of Java Lang Features.
What is the best way to port 'private static final' member?
I was thinking the extended class syntax would cover this, but I dont it
will work for a scenario like this:
private static final ObjectMapper mapper = new ObjectMapper();
or
private static final Set = STATIC_SET;
static {
STATIC_SET = new HashSet;
STATIC_SET.Add("A Value");
...
}
Any insight you may have is appreciated.
Thank you.
--
Regards,
Brian
__**_
fpc-pascal maillist -
fpc-pascal@lists.freepascal.**org
http://lists.freepascal.org/**mailman/listinfo/fpc-pascal<http://lists.freepascal.org/mailman/listinfo/fpc-pascal>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to make class constructor body calls descendant's overriden method/property?
A CLASS CONSTRUCTOR is a special CLASS STATIC method executed during unit initialization. Because it is CLASS STATIC, Self is undefined (and thus (1) what you write for ClassName in TghModel.Create really stands for TghModel.ClassName, and (2) if TUsers inherits it, the same code will be executed). What you want amounts to getting the list of classes with a common ancestor. To my knowledge is no way to do that automatically. On Sat, Nov 17, 2012 at 10:48 PM, leledumbo wrote: > Cross posted from stackoverflow: > http://stackoverflow.com/questions/13431079/how-to-make-class-constructor-body-calls-descendants-overriden-method-property > > I'm writing an ORM framework and got stuck in a way to automatically > determine table name from class name. In my base object for the ORM to work, > I have: > > TghModel = class > ... > class var FTableName: String; > class constructor Create; > ... > > whose implementation is: > > class constructor TghModel.Create; > begin > FTableName := ClassName; > Delete(FTableName,1,1); // Delete 'T' > end; > > My assumption was that ClassName method will return the real class name. > e.g. if I have: > > TUsers = class(TghModel) > > then FTableName will be initialized to TUsers instead of TghModel, which is > wrong. I want to avoid users to make class constructor for each classes > inheriting from TghModel, especially because the content would be totally > the same as in TghModel.Create. Is there any way to implement it? > > > > -- > View this message in context: > http://free-pascal-general.1045716.n5.nabble.com/How-to-make-class-constructor-body-calls-descendant-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
Re: [fpc-pascal] Extending an enumeration
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 parametric) set type, say SET OF 0..31, that can hold all possible elements, and define the possible elements as constants. On Fri, Dec 28, 2012 at 6:42 PM, Mark Morgan Lloyd wrote: > Is it possible to extend an enumeration, while preserving strong type > checking? In other words, given existing code like > > typeTUpstreamServerCapabilitiesBase= (uscConnected, uscCanIssueGUID); > TLocalServerCapabilitiesBase= (lscConnected, lscCanIssueGUID, > lscIsFirebird); > > TUpstreamServerCapabilities= set of TUpstreamServerCapabilitiesBase; > TLocalServerCapabilities= set of TLocalServerCapabilitiesBase; > > can the common parts of those enumerations- whether a connection was > initially established and so on- be moved into a common declaration, > preferably using "classical" Pascal so that I can store capabilities as a > set? > > -- > Mark Morgan Lloyd > markMLl .AT. telemetry.co .DOT. uk > > [Opinions 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-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Extending an enumeration
If you do not allow clients of your unit to define new elements or change the set values, and what you want to do is prevent, say, accidentally adding an extended element to the set in the base class, you can declare extended elements as class-local constants. Otherwise you will need to add 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 parametric) set type, say SET OF 0..31, that >> can hold all possible elements, and define the possible elements as >> constants. > > > Yes, except that that loses type checking. > > > -- > Mark Morgan Lloyd > markMLl .AT. telemetry.co .DOT. uk > > [Opinions 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-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
