Sections 5.5.2 and 6.6.8 of the FreePascal Language Reference discuss the "inherited" keyword, but
I couldn't find it in the syntax diagrams. Sections 12.2 and 13.1.2. have
procedure-statement = ( procedure-identifier | method-identifier | qualified-method-identifier |
variable-reference ) [ a
On 10/27/2016 06:01 AM, Tony Whyman wrote:
That is you can build an object hierarchy to parallel an interface
hierarchy.
I don't use the "Supports" primitive. - so maybe there is a bug in this
feature but otherwise, what is the problem with interface inheritance?
Yes, the problem is with "Sup
On 10/27/2016 05:18 AM, Graeme Geldenhuys wrote:
On 2016-10-27 12:42, Marcos Douglas B. Santos wrote:
It is a "bug by design".
The worst kind!
Actually, I think this is should be corrected in both modes (COM and CORBA).
Indeed, and even if it is fixed in FPC, it shouldn’t break any existi
On 27/10/16 03:47, Graeme Geldenhuys wrote:
A common misconception about how interfaces work. In fact, I don't
actually know why FPC and Delphi bother with Interface Inheritance,
because I simply don't see the point.
To make your "t_2" class support both interface, you need to specify
both in the
On Thu, Oct 27, 2016 at 10:18 AM, Graeme Geldenhuys
wrote:
>> It is a "bug by design".
>
> The worst kind!
Yeah, you're right.
>> Actually, I think this should be corrected in both modes (COM and CORBA).
>
> Indeed, and even if it is fixed in FPC, it shouldn’t break any existing
> code either. S
On 2016-10-27 12:42, Marcos Douglas B. Santos wrote:
> It is a "bug by design".
The worst kind!
> Actually, I think this is should be corrected in both modes (COM and CORBA).
Indeed, and even if it is fixed in FPC, it shouldn’t break any existing
code either. So it’s a win-win situation.
If no
On Thu, Oct 27, 2016 at 1:12 AM, Graeme Geldenhuys
wrote:
> In the Stack Overflow link I posted - further down the page - a person
> named Jasper mentions that in is QueryInterface implementation bug where
> QueryInterface on checks for valid Interface signatures in the top level
> of the interfac
On 2016-10-27 03:47, Graeme Geldenhuys wrote:
> Again, I don't know why it is done like this, and works very different
> to class inheritance. Delphi 7 works exactly the same in this regard.
> Maybe somebody with more knowledge on the subject could shed some light.
I did some quick internet search
On 2016-10-27 02:13, David Emerson wrote:
>t_2 = class (_obj_type_, i_2)
> // i_2 inherits from i_1, compiler requires i_1 implementation
> procedure do_one;
> procedure do_two;
> end;
A common misconception about how interfaces work. In fact, I don't
actually know why FPC
Hi all,
I am a bit perplexed / disappointed to see that the Supports /
QueryInterface functions for interfaces are not behaving the way I would
expect them to behave, when using an interface that inherits from
another interface.
note, _obj_type_ might be TObject, TInterfacedObject, or TCompo
On 6/12/13, Jonas Maebe wrote:
> Now change the variable type to TFoo but keep instantiating it using
> TFooChild.Create (like I originally suggested). Having that work is
> the whole point of polymorphism and why virtual/override exist.
I didn't even know that was possible
OK now I see the
On Wed, Jun 12, 2013 at 2:39 PM, Max Vlasov wrote:
> Overall looking at all cases I think this keyword can be considered as a
> good universal prefix excluding the context of the existing class working
> with methods and properties. Even looking at the name it has more to do with
> INHERITance tha
On 12 Jun 2013, at 13:33, Bart wrote:
On 6/12/13, Jonas Maebe wrote:
So that it would still have the same behaviour if you changed the
variable
declaration to
var
FooChild: TFoo;
If I change FooChild to TFoo (and instantiate with TFoo.Create) the
Now change the variable type to TFoo
On Wed, Jun 12, 2013 at 2:12 AM, Bart wrote:
>
> I thought that if I had a subclass that inherited form a parentclass,
> and both have a method with the same name (Bar), then the method of
> the subclass hid the method of the parentclass, and you could not call
> inherited Bar in the subclass.
>
On 6/12/13, Jonas Maebe wrote:
> So that it would still have the same behaviour if you changed the variable
> declaration to
>
> var
> FooChild: TFoo;
If I change FooChild to TFoo (and instantiate with TFoo.Create) the
outut is always the same, wether or not I use virtual for TFoo.Bar and
weth
On 12 Jun 2013, at 00:12, Bart wrote:
> var
> FooChild: TFooChild;
>
> begin
> FooChild := TFooChild.Create;
> FooChild.Bar;
> FooChild.Free;
> end.
>
> To my surprise this compiles without any warning or error.
> It outputs:
> C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
> TFoo.Bar
Hi,
I thought that if I had a subclass that inherited form a parentclass,
and both have a method with the same name (Bar), then the method of
the subclass hid the method of the parentclass, and you could not call
inherited Bar in the subclass.
More specifically I was under the impression that you
On Sun, 21 Dec 2003 17:36:00 +0100 Florian Klaempfl
<[EMAIL PROTECTED]> wrote:
> Mattias Gaertner wrote:
>
> > Can someone explain the semantic difference between *1 and *2 please?
> >
> > procedure A(p: Type1);
> > begin
> > inherited; // *1
> > inherited A(p); // *2
> > end;
> >
> > ?
>
Hello,
> > Can someone explain the semantic difference between *1 and *2 please?
> >
> > procedure A(p: Type1);
> > begin
> > inherited; // *1
> > inherited A(p); // *2
> > end;
> >
> > ?
>
> 1: supporting a delphi bug
> 2: as you expect
>
> Well, the comment to 1 isn't completly true: In met
Mattias Gaertner wrote:
Can someone explain the semantic difference between *1 and *2 please?
procedure A(p: Type1);
begin
inherited; // *1
inherited A(p); // *2
end;
?
1: supporting a delphi bug
2: as you expect
Well, the comment to 1 isn't completly true: In method handlers
(declared with
Can someone explain the semantic difference between *1 and *2 please?
procedure A(p: Type1);
begin
inherited; // *1
inherited A(p); // *2
end;
?
Mattias
___
fpc-pascal maillist - [EMAIL PROTECTED]
http://lists.freepascal.org/mailman/listinfo/f
21 matches
Mail list logo
