Re: [fpc-pascal] Re: ISO Standard Pascal I/O
On Fri, 28 May 2010, Roger Bailey wrote: Me: ... nextcharacter := input^ ... Does FPC not support this standard Pascal feature? Jonas: No, it does not. FPC mainly supports Borland-style Pascal dialects, and they are not ISO Standard/Extended Pascal compliant. I can live with that, but it would save newcomers a lot of trouble if the documentation were a bit more upfront about what FPC is not. Just saying it implements "some", or "most" of the features of dialect X is a recipe for frustration. Point well taken. Will try to do for the next release. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpweb fcgi: auto shutdown feature
On 28 Mei 2010, at 23:18, Michael Van Canneyt wrote: > Unless Joost does it first, I'll have a look at it next week. But it will be > under control of an option, and this option will be 'off' by default. Of course. I agree with that. It'd be nicer if the option can be set from the config file, just like the way I implemented it in ExtPascal. Thank you. :) -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpweb fcgi: auto shutdown feature
On Sat, 29 May 2010, Bee Jay wrote: On 28 Mei 2010, at 23:18, Michael Van Canneyt wrote: Unless Joost does it first, I'll have a look at it next week. But it will be under control of an option, and this option will be 'off' by default. Of course. I agree with that. It'd be nicer if the option can be set from the config file, just like the way I implemented it in ExtPascal. Thank you. :) The FCL FastCGI class does not have a config file. If you want that, you must implement that yourself. It is one of the flaws of ExtPascal's implementation: everything is tied together, using fixed formats for config files. When it would be far better to provide properties which can be set/unset at will: A modular design, allowing to re-use the components in setups that the implementor didn't think of. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpweb fcgi: auto shutdown feature
On 29 Mei 2010, at 15:36, Michael Van Canneyt wrote: > The FCL FastCGI class does not have a config file. > If you want that, you must implement that yourself. Alright then. > It is one of the flaws of ExtPascal's implementation: everything is tied > together, using fixed formats for config files. Whether it's a flaw or not, it just a matter of POV. Wanderlan seems to be a KISS concept lover. When a simpler way could get the job done, then be it. If then something more complex is needed, then improve it when the need is here. He's a very pragmatic developer, I would say. > When it would be far better to provide properties which can be set/unset at > will: A modular design, > allowing to re-use the components in setups that the implementor didn't think > of. ExtPascal's code, despite the flaws as you said, is very easy to be understood because of its simplicity. Somehow I think it's good to attract new contributors because s/he doesn't need too learn a huge beast OO framework beneath it. I only needed a mere couple of hours to get a good grasp of it. If the code become more complex, a refactoring effort can be done easily. Besides, it's (always) a work in progress. I believe it'll evolve, just like the other open source projects. ;) -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] stuck with untyped pointer
On Sat, 29 May 2010 00:33:00 +0200 José Mejuto wrote: > s> But the object layer brings the biggest issue with the implicit > s> "self" causing names external to a method to clash with local > s> names. > > Hmmm... I think that this should not happend. Is the case in your > posted example ? I mean when (how do you call this in Pascal: attributes?), say, fields and/or method names conflict with simple (usually local) variable names. This only happens because fields/methods can be denoted implicitely. So, the compiler may relate a name "value" to a "value" slot of the class of the current target; while the for the programmer "value" is a local var. And the value slot has nothing to do here -- but the compiler cannot know it. I find this wrong. Well, just my point of view. This design choice causes namespaces to leak ;-) In any other case, a locally introduced name acts like if were prefixed eg "local.value": private to the current namespace and thus totally safe. Object pascal's design choice makes field/method names also belong to every local namespace! > s> Worse: the compiler _sometimes_ blocks when var names conflict with > s> slot names (I have not yet understood when/why it does or not). > s> No offense intended, but I consider this as a language-design > s> error. (symptom: lexical paralysis ; cause: namespace leak) > > Var names "slot" names ? Which is a "slot name" ? Can you post a brief > example ? Sorry, I'm using terminology imported form another paradigm: "slot" is a general word for either data (property) or executable (method) field of a given object. Rather used in the prototype-based community. (A very practicle word because unambiguous; even "attribute" is sometimes unclear, may denote only data slots for some people, or only public ones. Slot only and always means "any kind of element belonging to an object".) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] object model
On Sat, 29 May 2010 01:09:50 +0300 Alberto Narduzzi wrote: > Hi, > > > Struct is declared as "class" so it inherits from TObject if not other > > class is especified. > > is that true? I don't mean not to trust you, but is the compiler > assuming that, or is it a FPC rule? IMO a class is a class, and doesn't > inherit from anything else. Unless specified. BTW, From who does TObject > inherit then? > Just asking, I never declare anything as a pure class, or if I do I > don't care if it descends from TObject or not, actually... Hum, there must be a root type, from which all others inherit primitive object mechanics. Such as, and mainly, accessing an attribute. Now, this needs not be obvious on the user-language side, but generally it is. So a test such as anything.isOfType(RootObject) always returns true. Don't know about free pascal, but this is very probable (and I assumed it's true before the question was raised). I take the opportunity to ask about inherited attribute (only methods in FP?) transmission and lookup: there are 2 common schemes: * Copy: A subclass holds copies of (references to) inherited methods. So, lookup stops on an object's class. * Delegation: A subclass delegates to its superclass when a looked up attribute is not found locally. (The superclass may itself delegate further, this up to the root class.) Maybe this does not apply to, or is irrelevant in, a static language. I imagine the compiler can directly bind a reference to eg anObject.aMethod wherever aMethod may be defined; since it knows the whole hierarchy. So, this may have no impact at runtime. I'd like to have more accurate information on this topic, because if it has any importance I will try to flatten as much as possible my object system; else I can "free-mindly" build vertical hierarchies, which often better mirror the semantics. Thank you all, denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpweb fcgi: auto shutdown feature
On Sat, 29 May 2010, Bee Jay wrote: On 29 Mei 2010, at 15:36, Michael Van Canneyt wrote: The FCL FastCGI class does not have a config file. If you want that, you must implement that yourself. Alright then. It is one of the flaws of ExtPascal's implementation: everything is tied together, using fixed formats for config files. Whether it's a flaw or not, it just a matter of POV. Wanderlan seems to be a KISS concept lover. When a simpler way could get the job done, then be it. If then something more complex is needed, then improve it when the need is here. He's a very pragmatic developer, I would say. Yes, but he chooses a very restrictive approach. As it is, you must convince him to change something. With the modular component approach, you don't need to wait. You develop whatever extensions you need on top of existing components. This is not doable with ExtPascal. Anyway, I don't want to criticize him too much. He had some very good ideas in ExtPascal, and they are certainly worth looking at. When it would be far better to provide properties which can be set/unset at will: A modular design, allowing to re-use the components in setups that the implementor didn't think of. ExtPascal's code, despite the flaws as you said, is very easy to be understood because of its simplicity. Somehow I think it's good to attract new contributors because s/he doesn't need too learn a huge beast OO framework beneath it. I only needed a mere couple of hours to get a good grasp of it. If the code become more complex, a refactoring effort can be done easily. Besides, it's (always) a work in progress. I believe it'll evolve, just like the other open source projects. ;) Let us hope so :-) Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] object model
On Sat, 29 May 2010, spir ☣ wrote: On Sat, 29 May 2010 01:09:50 +0300 Alberto Narduzzi wrote: Hi, Struct is declared as "class" so it inherits from TObject if not other class is especified. is that true? I don't mean not to trust you, but is the compiler assuming that, or is it a FPC rule? IMO a class is a class, and doesn't inherit from anything else. Unless specified. BTW, From who does TObject inherit then? Just asking, I never declare anything as a pure class, or if I do I don't care if it descends from TObject or not, actually... Hum, there must be a root type, from which all others inherit primitive object mechanics. Such as, and mainly, accessing an attribute. Now, this needs not be obvious on the user-language side, but generally it is. So a test such as anything.isOfType(RootObject) always returns true. Don't know about free pascal, but this is very probable (and I assumed it's true before the question was raised). All classes descent from TObject, always: implicitly or explicitly. I take the opportunity to ask about inherited attribute (only methods in FP?) transmission and lookup: there are 2 common schemes: * Copy: A subclass holds copies of (references to) inherited methods. So, lookup stops on an object's class. * Delegation: A subclass delegates to its superclass when a looked up attribute is not found locally. (The superclass may itself delegate further, this up to the root class.) Static methods are directly bound by the compiler. For virtual methods: the actual pointer to the method is in the VMT A pointer to the VMT is initialized when an instance is created. But I am not sure whether VMTs are linked or whether they are copied for descendents. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC bug or brain bug ?
On 27/05/10 23:13, Jonas Maebe wrote: On 27 May 2010, at 23:31, Yann Bat wrote: The compiler always adds a VMT if an object has a constructor or destructor. The reason is that the VMT also contains the instance size, which is used by the constructor helper to allocate the required amount of memory. Ok but why a different behaviour between [fpc | objfpc] mode and [tp | delphi] mode ? It is allowed in Delphi and TP because they allow declaring typed constants of objects. I don't remember why it was disabled in the FPC modes, but that happened a long time ago (before the move from cvs to svn). Maybe someone else does. Definitely TP-style objects did not have a VMT unless you declared a virtual method, in TP. And a destructor was only virtual if it was declared virtual. Hence typed constant objects could be possible. Presumably FPC decided compatibility with this feature was not desirable? FP ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC bug or brain bug ?
On Sat, May 29, 2010 12:56, Frank Peelo wrote: > On 27/05/10 23:13, Jonas Maebe wrote: >> On 27 May 2010, at 23:31, Yann Bat wrote: >> >> The compiler always adds a VMT if an object has a constructor or destructor. The reason is that the VMT also contains the instance size, which is used by the constructor helper to allocate the required amount of memory. >>> Ok but why a different behaviour between [fpc | objfpc] mode and [tp | >>> delphi] mode ? >>> >> It is allowed in Delphi and TP because they allow declaring typed >> constants of objects. I don't remember why it was disabled in the FPC >> modes, but that happened a long time ago (before the move from cvs to >> svn). Maybe someone else does. >> > > Definitely TP-style objects did not have a VMT unless you declared a > virtual method, in TP. And a destructor was only virtual if it was > declared virtual. Hence typed constant objects could be possible. > Presumably FPC decided compatibility with this feature was not desirable? I believe the same is the case with FPC and _objects_ (not classes) and FPC is thus compatible here. The text above (mentioning constructors allocating the memory) probably refers to classes. In case of objects, constructor does not need to allocate memory because the object is either declared statically, or it's declared dynamically, but the allocation happens before the constructor is invoked. Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpweb fcgi: auto shutdown feature
On 29 Mei 2010, at 16:52, Michael Van Canneyt wrote: > Yes, but he chooses a very restrictive approach. As it is, you must > convince him to change something. With the modular component approach, you > don't need to wait. Why should I have to wait? I got the source code, all of them. If I need some new features and I'm able to implement it myself, nobody could prevent me to do it. That's why the simplicity of ExtPascal code does matter in some cases. > He had some very good ideas in ExtPascal, and they are certainly worth > looking at. Yes, before I knew ExtPascal, I never thought such tool can be build (pascal vs js ui framework integration). Even Morfik is unable to do it, at least not easily. :) > Let us hope so :-) Well... it's happening. :) -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC bug or brain bug ?
On 29 May 2010, at 13:22, Tomas Hajny wrote: > I believe the same is the case with FPC and _objects_ (not classes) and > FPC is thus compatible here. The text above (mentioning constructors > allocating the memory) probably refers to classes. In case of objects, > constructor does not need to allocate memory because the object is either > declared statically, or it's declared dynamically, but the allocation > happens before the constructor is invoked. Semantically, yes. Implementation-wise, no: # [13] new(o,init); movl_U_P$PROGRAM_O,%ebx movlL_VMT_P$PROGRAM_TOBJ$non_lazy_ptr,%edx movl$0,%eax callL_P$PROGRAM_TOBJ_$__INIT$$LONGBOOL$stub movl%eax,_U_P$PROGRAM_O The first $0 parameter (in %eax) indicates that memory still has to be reserved. P$PROGRAM_TOBJ_$__INIT$$LONGBOOL (= tobj.init) calls fpc_help_constructor, which allocates the memory if necessary (based on the size in the VMT, and the VMT is loaded in %edx in the code above). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC bug or brain bug ?
On 29 May 2010, at 12:56, Frank Peelo wrote: > On 27/05/10 23:13, Jonas Maebe wrote: >> On 27 May 2010, at 23:31, Yann Bat wrote: >> The compiler always adds a VMT if an object has a constructor or destructor. The reason is that the VMT also contains the instance size, which is used by the constructor helper to allocate the required amount of memory. >>> Ok but why a different behaviour between [fpc | objfpc] mode and [tp | >>> delphi] mode ? >>> >> It is allowed in Delphi and TP because they allow declaring typed constants >> of objects. I don't remember why it was disabled in the FPC modes, but that >> happened a long time ago (before the move from cvs to svn). Maybe someone >> else does. > > Definitely TP-style objects did not have a VMT unless you declared a virtual > method, in TP. And a destructor was only virtual if it was declared virtual. > Hence typed constant objects could be possible. I made a typo in the comment above (my first quoted statement at the top of the mail is still correct though), it should have read "It is allowed in Delphi and TP because they allow declaring typed constants of objects *that contain a VMT*". As I explained, FPC adds a VMT for any object type that contains a constructor or destructor. This by itself may be another incompatibility with TP/Delphi. > Presumably FPC decided compatibility with this feature was not desirable? The reason for adding the VMT as soon as there is a constructor or destructor may be for implementation reasons, although it's strange that this is TP-incompatible since this was probably implemented by Pierre or Carl-Eric, and they generally paid a lot of attention to being binary compatible to TP as much as possible. As mentioned before, I don't know the reason for not allowing typed constants of TP-style objects that have a VMT.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] casting back a pointer to original type
Hello, Say I store class instances of various types in a TFPList. All happen to be descendants of same superclass C and each one has a specific method "text". When retrieving and writing an element, if they were all direct instances of C, I would do something like: element := C(list[index]); // casting back text := element.text; I cannot do that, even if elements all are *indirect* instances of C, because this calls C.text instead of the element's own proper text method. Which is wrong, indeed. So, I must cast elements back to their own type; but I have no idea how to do this. Doesn't the compiler store this information? After all, when an element is put into the list, its type is known. Is there a reason why retrieving an element does not cast it back to its original type automatically? Should I store element types manually in a parallel list? There must be a way to solve this issue, I guess... Side-question: it seems, when subclassing, that methods with same name and same parameters do not need any modifier keyword (such as "override" or "overload"). Eg I can have function text; in both a superclass C0 and a subclass C1 work as expected. Correct? Thank you, Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On Sat, 29 May 2010, spir ☣ wrote: Hello, Say I store class instances of various types in a TFPList. All happen to be descendants of same superclass C and each one has a specific method "text". When retrieving and writing an element, if they were all direct instances of C, I would do something like: element := C(list[index]); // casting back text := element.text; I cannot do that, even if elements all are *indirect* instances of C, because this calls C.text instead of the element's own proper text method. Which is wrong, indeed. So, I must cast elements back to their own type; but I have no idea how to do this. Doesn't the compiler store this information? After all, when an element is put into the list, its type is known. Is there a reason why retrieving an element does not cast it back to its original type automatically? Should I store element types manually in a parallel list? There must be a way to solve this issue, I guess... There are 2 1. Make all descendents descendent of a super class that has a text property. 2. Make the "text" property published, and use RTTI to get/set it. uses typinfo; text:=GetStrProp(element,'text'); Or SetStrProp(Element,'text',AValue) Side-question: it seems, when subclassing, that methods with same name and same parameters do not need any modifier keyword (such as "override" or "overload"). Eg I can have function text; in both a superclass C0 and a subclass C1 work as expected. Correct? It depends on what you want to achieve. If you make it a static method, then the compiler will emit a warning "function Text hides method of parent class" (or something like it) If you make it virtual, then you must explicitly add "override" to override the implementation of the method. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On 29 May 2010, at 18:11, Michael Van Canneyt wrote: > It depends on what you want to achieve. If you make it a static method, then > the compiler will emit a warning "function Text hides method of parent > class" (or something like it) > > If you make it virtual, then you must explicitly add "override" to override > the implementation of the method. Virtual methods can also hide inherited methods (if you don't add override). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On Sat, 29 May 2010, Jonas Maebe wrote: On 29 May 2010, at 18:11, Michael Van Canneyt wrote: It depends on what you want to achieve. If you make it a static method, then the compiler will emit a warning "function Text hides method of parent class" (or something like it) If you make it virtual, then you must explicitly add "override" to override the implementation of the method. Virtual methods can also hide inherited methods (if you don't add override). Right. I should have added that. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
> element := C(list[index]); // casting back
> text := element.text;
> I cannot do that, even if elements all are *indirect* instances of C, because
> this calls C.text instead of the element's own proper text method.
If you use virtual methods then C.text should call the descendant's method.
This
is what polymorphism, the most powerful concept in object oriented programming,
is all about.
> Side-question: it seems, when subclassing, that methods with same name and
> same parameters do not need any modifier keyword (such as "override"
> or "overload"). Eg I can have
> function text;
> in both a superclass C0 and a subclass C1 work as expected. Correct?
This is likely your problem. If you are not using virtual methods then you are
not going to get polymorphism.
Here's a sample program to illustrate:
{$mode objfpc}
type
C0 = class
procedure statictext;
procedure virtualtext; virtual;
end;
C1 = class (C0)
procedure statictext;
procedure virtualtext; override;
end;
procedure C0.virtualtext;
begin
writeln ('C0 virtual');
end;
procedure C0.statictext;
begin
writeln ('C0 static');
end;
procedure C1.virtualtext;
begin
writeln ('C1 virtual');
end;
procedure C1.statictext;
begin
writeln ('C1 static');
end;
var
a : C0;
b : C1;
p : pointer;
t : tobject;
begin
b := C1.create;
p := b;
a := C0(p);
a.statictext; // output: C0 static
a.virtualtext; // output: C1 virtual
// let's add another degree of removal
t := tobject(p);
C0(t).statictext;
C1(t).statictext;
C0(t).virtualtext;
C1(t).virtualtext;
end.
Cheers,
David
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On Sat, 29 May 2010 10:46:45 -0700 David Emerson wrote: > > element := C(list[index]); // casting back > > text := element.text; > > I cannot do that, even if elements all are *indirect* instances of C, > > because > > this calls C.text instead of the element's own proper text method. > > If you use virtual methods then C.text should call the descendant's method. > This > is what polymorphism, the most powerful concept in object oriented > programming, > is all about. > > > Side-question: it seems, when subclassing, that methods with same name and > > same parameters do not need any modifier keyword (such as "override" > > or "overload"). Eg I can have > > function text; > > in both a superclass C0 and a subclass C1 work as expected. Correct? > > This is likely your problem. If you are not using virtual methods then you > are > not going to get polymorphism. I cannot do that. C0 (and all classes) instances need a text method. I also cannot have 2 methods (one static, one virtual) with different names. It's a basic feature, always called with the same name. Like getItem for a hierarchy of collections: every collection must have it, and always under the same name, so that any client can rely on it. I'll have to find a workaround. As of now, the only solution I can imagine (but it's really really stupid) is to store somewhere, in a // list, the actual types of all items recorded in a TFPList. But I find this incredible... I must be overlooking something basic; how do you use TFPList, if when reading back stored items their types are lost in ether? TFPList is precisely intended to record class instances, meanings all kinds of stuff descending from TObject, or am I wrong on this? Is there another kind of (pointed) sequential collection able to store class instances without losing its items' types? Another solution may be to store the type as an additional attribute of items themselves, before they are put into a collection. But since Pascal is static, this cannot be done "live" at runtime; meaning *all* items in the system must have this attribute. But I could then probably do something like: // the looked up item is list[index] // first read (a reference to) its type on the item itself typ := list[index].type; // now I can read and cast it item := typ(list[index]); Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On Sat 29 May 2010, spir ☣ wrote: > I cannot do that. C0 (and all classes) instances need a text method. I also > cannot have 2 methods (one static, one virtual) with different names. So make a virtual method called text. Don't use a static method at all. In my example I was trying to demonstrate the difference between static methods and virtual methods. I was not trying to suggest that you change your method names, or use both static and virtual methods. I can't be sure without seeing your code, but based on reading your messages three times, it appears to me that you are using static methods (i.e. without the virtual and override keywords) and expecting them to behave like virtual methods. Cheers & good luck, David ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] casting back a pointer to original type
On 29 May 10, at 15:26 , spir ☣ wrote: > I cannot do that. C0 (and all classes) instances need a text method. I also > cannot have 2 methods (one static, one virtual) with different names. It's a > basic feature, always called with the same name. Like getItem for a hierarchy > of collections: every collection must have it, and always under the same > name, so that any client can rely on it. David is not suggesting you have two methods with different names - his example is demonstrating the different behaviour of static and virtual methods. Calling a static method is determined at compile time - the compiler must use the actual class of your variable (or cast) - so your descendent methods will never be called. This is what is happening to you at the moment - only your base class Text method is called. Calling a virtual method is determined at runtime based upon the actual class held by the variable (cast) - it seems this is exactly what you need. Set your base class Text method as virtual, and each descendent class Text method as override - your code should then function as you require... element := C(list[index]); // casting back text := element.text; if the pointer in list[index] is C1, C1.Text will be called. Regards, Andrew. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
