On 2017-09-06 09:03, Ryan Joseph wrote:
For the sake of discussion can you see why it makes sense that “hook.” syntax
would be implied because the class does indeed supposedly implement the
interface? Everything about the syntax says that the methods in IHook should be
in TBaseClass so I can’t
Am 06.09.2017 10:34 schrieb "Ryan Joseph" :
>
>
> > On Sep 6, 2017, at 2:50 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > There is NO need to make Hook public, because you can always get access
to that functionality via the Supports() call and get a reference to IHook.
>
> T
> On Sep 6, 2017, at 2:50 PM, Graeme Geldenhuys
> wrote:
>
> There is NO need to make Hook public, because you can always get access to
> that functionality via the Supports() call and get a reference to IHook.
The Supports() call is the key takeaway here.
For the sake of discussion can you
On 2017-09-05 05:05, Ryan Joseph wrote:
That’s what I was looking for in terms of a practical use patterns
for “implements properties”. I should have seen that at the start but
I’m still hung up on how it’s implemented.
And to come back to your example in your first post:
// your code
TBase
> On Sep 4, 2017, at 3:45 PM, Michael Schnell wrote:
>
> Re Interfaces: Do you know a decent description of how to use Interface
> _as_a_language_feature_ (e.g. in fpc) completely independent of their use
> with certain OS-provided libraries ?
As an alternate to polymorphism but without subcl
On 02.09.2017 11:59, Graeme Geldenhuys wrote:
Like multi-threading, Interfaces are an advanced feature of the
Object Pascal language. Unfortunately, many ways that it can be used
incorrectly too.
Unfortunately multi-threading is not a feature of the Object Pascal
language :( . Oxygen does ha
> On Sep 2, 2017, at 6:56 PM, Sven Barth via fpc-pascal
> wrote:
>
> As Graeme said: the point is to code against interfaces, not classes. Don't
> pass around or work with the TBaseClass instance, instead only with the IHook
> interface. And this is what the implements feature is for.
>
>
Am 02.09.2017 10:38 schrieb "Ryan Joseph" :
>
>
> > On Sep 2, 2017, at 3:27 PM, Graeme Geldenhuys <
mailingli...@geldenhuys.co.uk> wrote:
> >
> > Please search the internet about Interfaces and probably Design
Patterns too. Have ever heard the phrase: "Code to an Interface, not an
Implementation".
On 2017-09-02 09:38, Ryan Joseph wrote:
It separates the code (which is nice) but then gives you an annoying
extra step of typing hook.XXX for every method.
I don't have that problem, and I use interfaces extensively. Like
multi-threading, Interfaces are an advanced feature of the Object Pasca
> On Sep 2, 2017, at 3:27 PM, Graeme Geldenhuys
> wrote:
>
> Please search the internet about Interfaces and probably Design Patterns too.
> Have ever heard the phrase: "Code to an Interface, not an Implementation".
>
> Interfaces are so much more than simply "adding methods to a class".
I u
On 2017-09-02 08:44, Ryan Joseph wrote:
but then what is the purpose of this?
Please search the internet about Interfaces and probably Design Patterns
too. Have ever heard the phrase: "Code to an Interface, not an
Implementation".
Interfaces are so much more than simply "adding methods to a
> On Sep 2, 2017, at 2:35 PM, Sven Barth via fpc-pascal
> wrote:
>
> Because you must use the interface and not the class instance:
>
> === code begin ===
>
> var
> base: TBaseClass;
> hook: IHook;
> begin
> base := TBaseClass.Create;
> hook := base;
>
> hook.DoIt; // will call bas
Am 02.09.2017 06:34 schrieb "Ryan Joseph" :
>
> I think I asked this some years ago but I came across it again I just
don’t get what the point of this is. There is an “implements” property but
it seems like yet another half-baked feature from Delphi that wasn’t
implemented completely or is broken.
13 matches
Mail list logo
