Re: [fpc-pascal] Interface delegates and the implements property specifier

[Sven Barth via fpc-pascal]

Adriaan van Os  schrieb am So., 22. Dez. 2019, 20:53:

> I have always wondered why hierarchies in object-oriented programming are
> idolized, where in the
> database world hierarchical databases are something of the past and
> everything is relational there
> now .
>

Because in object oriented programming languages one tends to try to work
with the common denominator to ease up the dependencies between the
concrete implementations. E.g. the LCL relies on TComponent and TControl,
it does not need to know that there is a TMyWhateverControl. I even miss
inheritance in databases as well as that would make the tables simpler.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface delegates and the implements property specifier

[Sven Barth via fpc-pascal]

Ryan Joseph via fpc-pascal 
>
> > On Dec 22, 2019, at 5:26 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > You don't seem to understand what implementing an interface means in
> Object Pascal. It means that a class can be cast to an interface. It does
> *not* mean that the interface's methods are available from that class.
>
> I guess I'm not seeing the design pattern which they was invented for and
> I've never come across it in my own work. Not against the idea in any way
> however.
>
> My mind went in the same direction as Adriaan's did when I saw
> "implements" I thought that one class could be built from many smaller
> classes but share the same namespace (like in multiple inheritance or
> entity/component designs). If a class implements an interface via a
> delegate then I would expect this to function the same as inheritance, i.e.
> the namespaces are merged and share functions. Doesn't that make sense?
>

It does make sense, but not in the context of interfaces. They are not
there to provide implementations, but to provide a known API to the user.



> Maybe what I mean to say is that there's a need for a delegation syntax
> that functions like multiple inheritance and avoids the traps of deeply
> nested single inheritance hierarchies. Does anyone else agree?
>

What might be more interesting in this context than multiple inheritance is
the concept of aspects (aka aspect oriented programming though you might
also want to look for "mixin"; there's an old thread about that:
https://lists.freepascal.org/fpc-pascal/2009-December/023815.html). If we
could find an agreeable syntax and implementation for that then we'd be
potentially inclined to include that as a new feature as there had been
experiments for that in the past.

Regards,
Sven

>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Passing a CORBA interface as parameter

[Adriaan van Os]

Zamrony P. Juhara via fpc-pascal wrote:
If you need to know if an instance implement certain interface, you can 
use is operator


if anInstance is IInterface1 then
begin
 
end


Thanks for the reply, but that is not what I meant.

Regards,

Adriaan van Os

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface delegates and the implements property specifier

[Adriaan van Os]

Ryan Joseph via fpc-pascal wrote:



I guess I'm not seeing the design pattern which they was invented for and I've 
never come across it in my own work. Not against the idea in any way however.

My mind went in the same direction as Adriaan's did when I saw "implements" I 
thought that one class could be built from many smaller classes but share the same 
namespace (like in multiple inheritance or entity/component designs). If a class 
implements an interface via a delegate then I would expect this to function the same as 
inheritance, i.e. the namespaces are merged and share functions. Doesn't that make sense?

Maybe what I mean to say is that there's a need for a delegation syntax that functions like multiple inheritance and avoids the traps of deeply nested single inheritance hierarchies. Does anyone else agree? 


Compare this with relational databases where the columns of related, say "delegate", tables can be 
put side-to-side with columns of the main table in so-called database views 
.


I have always wondered why hierarchies in object-oriented programming are idolized, where in the 
database world hierarchical databases are something of the past and everything is relational there 
now .


Regards,

Adriaan van Os

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface delegates and the implements property specifier

[Ryan Joseph via fpc-pascal]

> On Dec 22, 2019, at 5:26 AM, Sven Barth via fpc-pascal 
>  wrote:
> 
> You don't seem to understand what implementing an interface means in Object 
> Pascal. It means that a class can be cast to an interface. It does *not* mean 
> that the interface's methods are available from that class.

I guess I'm not seeing the design pattern which they was invented for and I've 
never come across it in my own work. Not against the idea in any way however.

My mind went in the same direction as Adriaan's did when I saw "implements" I 
thought that one class could be built from many smaller classes but share the 
same namespace (like in multiple inheritance or entity/component designs). If a 
class implements an interface via a delegate then I would expect this to 
function the same as inheritance, i.e. the namespaces are merged and share 
functions. Doesn't that make sense?

Maybe what I mean to say is that there's a need for a delegation syntax that 
functions like multiple inheritance and avoids the traps of deeply nested 
single inheritance hierarchies. Does anyone else agree? 

Regards,
Ryan Joseph

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] StringList encoding question

[Bart via fpc-pascal]

Hi,

Consider this code:

{$codepage utf8}
{$mode objfpc}
{$H+}

uses
  SysUtils, Classes;

var
  SL: TSTringList;
  S: String;

begin
  writeln('DefaultSystemCodePage = ',DefaultSystemCodePage);
  SL := TStringList.Create;
  {$if fpc_fullversion > 30200}
  SL.WriteBom := False;
  {$endif}
  SL.SkipLastLineBreak := True;
  S := 'ä';  //S has CodePage CP_UTF8
  SL.Add(S);
  SL.SaveToFile('slU.txt'{$if fpc_fullversion > 30200}, TEncoding.UTF8{$endif});
  SL.SaveToFile('slA.txt'{$if fpc_fullversion > 30200}, TEncoding.ANSI{$endif});
  SL.Free;
end.

Tested with fpc trunk (form a few days ago).
It outputs:
DefaultSystemCodePage = 1252 (I'm on Windows as you might have guessed)
The file slA.txt contains the bytes C3 A4 (which is ä in UTF8 encoding)
The file slU.txt contains the bytes C3 83 C2 A4

I struggle to understand why.
What is the codepage of the stringlist's internal list of strings
(array of TStringItem's)?
It seems that the stringlist considers it's internal
TStringItem.FString that has #$C3A#$A4 to  have a codepage of CP_ACP
(always)?

Bart

-- 
Bart
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Interface delegates and the implements property specifier

[Sven Barth via fpc-pascal]

Am 22.12.2019 um 04:44 schrieb Ryan Joseph via fpc-pascal:



On Dec 21, 2019, at 10:49 AM, Adriaan van Os  wrote:

I had hoped that procedure IMyInterface2.P2 would now be visible as a method of 
TMyClass. This would be quite helpful in implementing multiple-inheritance. But 
no, the implements specifier completely hides it. I assume this has been 
discussed before.

That's exactly what I was ranting about some months back with the idea of "default 
properties". I would expect that syntax to pull the methods names into the current 
namespace and this would be very helpful.

It's by design as Sven pointed out but this makes no sense whatsoever to me. If 
the compiler team agrees I will personally make a mode switch or whatever is 
permitted to accomplish this. :)

Vetoed.

You don't seem to understand what implementing an interface means in 
Object Pascal. It means that a class can be cast to an interface. It 
does *not* mean that the interface's methods are available from that class.


Take this:

=== code begin ===

program tintftest;

{$mode objfpc}
{$interfaces corba}

type
  ITest = interface
    procedure Test;
  end;

  TTest = class(TObject, ITest)
  strict private
    procedure Test;
  end;

procedure TTest.Test;
begin
end;

var
  t: TTest;
  i: ITest;
begin
  t := TTest.Create;
  //t.Test; // this does not compile
  i := t;
  i.Test;
end.

=== code end ===

An implementor can decide to have the interface's methods not accessible 
from outside.


Or take this:

=== code begin ===

program tintftest;

{$mode objfpc}
{$interfaces corba}

type
  ITest = interface
    procedure Test;
  end;

  TTest = class(TObject, ITest)
  public
    procedure ITest.Test = IntfTest;
    procedure IntfTest;
    procedure Test;
  end;

procedure TTest.Test;
begin
  Writeln('Test');
end;

procedure TTest.IntfTest;
begin
  Writeln('IntfTest');
end;

var
  t: TTest;
  i: ITest;
begin
  t := TTest.Create;
  t.Test;
  i := t;
  i.Test;
end.

=== code end ===

This will output

=== output begin ===

PS C:\fpc\git> .\testoutput\tintftest
Test
IntfTest

=== output end ===

So while TTest implements the ITest interface it's methods are not the 
same as the interface's.


Similar for delegates. The delegation property can be private (mostly 
protected though to avoid a "unused private symbol" warning), so you 
only get access to the delegated field by casting the class to the 
implemented interface.


Your proposal to hoist the methods of a delegated interface would 
conflict with this. Or it would require an alternative syntax to give 
the implementor the necessary control of the visibility.


TL;DR: in Object Pascal a class implementing an interface can be cast to 
that interface, but it does not need to present the methods of said 
interface.


Regards,
Sven
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal