Re: [fpc-devel] Object upgrades
On Mon, Jun 10, 2019 at 3:31 PM Ryan Joseph wrote:
> Sorry, if I dereference the size is still of TBase. I don’t think “result"
> is actually changing depending on the class type. This may have something
> to do with the way new works though. How can we fix this?
>
It's because Initialize isn't virtual (and can't be), meaning your code
really just creates a PBase and then hard-casts it to a PChild.
If you really want to use objects in that kind of way though, here's a
general example that works and doesn't leak memory:
program Test;
{$mode ObjFPC}
{$modeswitch AutoDeref}
type
PBase = ^TBase;
TBase = object
public
I: Int64;
constructor Initialize;
class function Create: PBase; static; inline;
procedure Free;
end;
constructor TBase.Initialize;
begin
WriteLn('Base!');
I := 12;
end;
class function TBase.Create: PBase;
begin
New(Result, Initialize);
end;
procedure TBase.Free;
begin
if Assigned(@Self) then begin
WriteLn('Size: ', SizeOf(Self));
FreeMem(@Self, SizeOf(Self));
end;
end;
type
PChild = ^TChild;
TChild = object(TBase)
public
S: String[5];
constructor Initialize;
class function Create: PChild; static; inline;
end;
constructor TChild.Initialize;
begin
inherited Initialize;
WriteLn('Child!');
S := 'hello';
end;
class function TChild.Create: PChild;
begin
New(Result, Initialize);
end;
var
PB: PBase;
PC: PChild;
begin
PB := TBase.Create;
WriteLn(PB.I);
PB.Free;
PC := TChild.Create;
WriteLn(PC.I);
WriteLn(PC.S);
PC.Free;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
schrieb am Di., 18. Juni 2019, 03:27: > >> *this is an example of a traditional record and a traditional object as > i > >> think of them... > > [snip] > > > > These would still work as is in FPC. > > > right but are they objects, classes or advanced records? > Your example showed a couple of records and an object. The later is often also called TP-style object for better distinction to Delphi-style objects also known as "classes" (due to their use of the "class" keyword instead of the "object" keyword). Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/17/19 4:56 PM, Sven Barth via fpc-devel wrote: Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm getting old and rarely dabble in pascal code any more but i still read the mailing lists :) I suggest you to take a look at this: https://wiki.freepascal.org/Object_Oriented_Programming_with_Free_Pascal_and_Lazarus#Free_Pascal_Language_Extensions thanks... i'll try to get by there soon-ish... *this is an example of a traditional record and a traditional object as i think of them... [snip] These would still work as is in FPC. right but are they objects, classes or advanced records? -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
Am 17.06.2019 um 19:56 schrieb wkitt...@windstream.net: And yes, both are again different from classes. yeah, i'll have to see if i can figure out what classes are and if they are one of the old-school objects or records... yeah, i'm getting old and rarely dabble in pascal code any more but i still read the mailing lists :) I suggest you to take a look at this: https://wiki.freepascal.org/Object_Oriented_Programming_with_Free_Pascal_and_Lazarus#Free_Pascal_Language_Extensions *this is an example of a traditional record and a traditional object as i think of them... [snip] These would still work as is in FPC. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/17/19 12:49 PM, Sven Barth via fpc-devel wrote:
schrieb am Mo., 17. Juni 2019, 14:15:
On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote:
> schrieb am Mo., 17. Juni 2019, 02:07:
>
> what always confused me these days is that records and objects were
one thing
> back in the (TP6) day but today they are something quite different...
i had to
> be very careful when i wrote my satellite TLE management tool because
of these
> differences...
>
>
> Ehm... TP style objects were already quite different to records back in
TP days.
yes... what i'm saying is that today's are different and that's what
confuses me...
You are talking about classes, aren't you?
maybe... that's part of the confusion... i'm self taught from TP2... never took
any classes for anything computer at all... started with B.A.S.I.C. and a friend
showed me asm and pascal... i dropped basic like a hot potato and went all out
with asm and pascal... had a nice library of routines in asm but as each new TP
came out, fewer and fewer of my homegrown asm routines were needed... eventually
i was doing asm blocks in my pascal sources instead of compiling .obj files and
linking them in...
in the day that i speak of, records were simple static blocks that contained
data in a certain defined order... today's records have methods, too, which
are
more like objects back then... i forget the difference between yesterday's
objects and today's...
But back in the days the objects were already different from records.
right... i wrote my own objects when they were introduced and later extensively
used message base objects from Mark May when writing BBS message base tools...
some objects had (traditional) records* within them...
mksm106.zip 215k
MK Source for Msg Access v1.06 - Mark May's
Pascal OOP source code to access Squish,
Jam, Hudson, *.Msg, and Ezycom message
bases. Great for developing BBS utilities.
(FW)
ftp://sestar.synchro.net/main/PROG/mksm106.zip
i started, some time back, to convert the code to FPC but RL and other shite got
in the way...
And yes, both are again different from classes.
yeah, i'll have to see if i can figure out what classes are and if they are one
of the old-school objects or records... yeah, i'm getting old and rarely dabble
in pascal code any more but i still read the mailing lists :)
*this is an example of a traditional record and a traditional object as i think
of them...
Type JamHdrType = Record
Signature: Array[1..4] of Char;
Created: LongInt;
ModCounter: LongInt;
ActiveMsgs: LongInt;
PwdCRC: LongInt;
BaseMsgNum: LongInt;
Extra: Array[1..1000] of Char;
End;
Const JamSubBufSize = 4000;
Type JamSubBuffer = Array[1..JamSubBufSize] of Char;
Type HdrType = Record
JamHdr: JamMsgHdrType;
SubBuf: JamSubBuffer;
End;
Type JamMsgObj = Object (AbsMsgObj)
JM: ^JamMsgType;
MsgHdr: ^HdrType;
JamIdx: ^JamIdxArrayType;
TxtBuf: ^JamTxtBufType;
Error: Longint;
Constructor Init; {Initialize}
Destructor Done; Virtual; {Done}
Procedure SetMsgPath(St: String); Virtual; {Set netmail path}
Function GetHighMsgNum: LongInt; Virtual; {Get highest netmail msg number in
area}
Function LockMsgBase: Boolean; Virtual; {Lock the message base}
Function UnLockMsgBase: Boolean; Virtual; {Unlock the message base}
Function WriteMailIdx(FN: String; MsgPos: Word): Word; Virtual; {Write
Netmail or EchoMail.jam}
Procedure SetDest(Var Addr: AddrType); Virtual; {Set Zone/Net/Node/Point for
Dest}
Procedure SetOrig(Var Addr: AddrType); Virtual; {Set Zone/Net/Node/Point for
Orig}
Procedure SetFrom(Name: String); Virtual; {Set message from}
Procedure SetTo(Name: String); Virtual; {Set message to}
Procedure SetSubj(Str: String); Virtual; {Set message subject}
Procedure SetCost(SCost: Word); Virtual; {Set message cost}
Procedure SetRefer(SRefer: LongInt); Virtual; {Set message reference}
Procedure SetSeeAlso(SAlso: LongInt); Virtual; {Set message see also}
Function GetNextSeeAlso: LongInt; Virtual;
Procedure SetNextSeeAlso(SAlso: LongInt); Virtual;
Procedure SetDate(SDate: String); Virtual; {Set message date}
Procedure SetTime(STime: String); Virtual; {Set message time}
Procedure SetLocal(LS: Boolean); Virtual; {Set local status}
Procedure SetRcvd(RS: Boolean); Virtual; {Set received status}
Procedure SetPriv(PS: Boolean); Virtual; {Set priveledge vs public status}
Procedure SetCrash(SS: Boolean); Virtual; {Set crash netmail status}
Procedure SetKillSent(SS: Boolean); Virtual; {Set kill/sent netmail status}
Procedure SetSent(SS: Boolean); Virtual; {Set sent netmail status}
Procedure SetFAttach(SS: Boolean); Virtual; {Set file attach status}
Procedure SetReqRct(SS: Boolean); Virtual; {Set request receipt status}
Procedure SetReqAud(SS: Boolean); Virtual; {Set request audit status}
Procedure
Re: [fpc-devel] Object upgrades (new)
schrieb am Mo., 17. Juni 2019, 14:15: > On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: > > schrieb am Mo., 17. > > Juni 2019, 02:07: > > > > what always confused me these days is that records and objects were > one thing > > back in the (TP6) day but today they are something quite > different... i had to > > be very careful when i wrote my satellite TLE management tool > because of these > > differences... > > > > > > Ehm... TP style objects were already quite different to records back in > TP days. > > > yes... what i'm saying is that today's are different and that's what > confuses me... > You are talking about classes, aren't you? > > After all the former supported inheritance and (virtual) methods while > the later > > supported variant parts. > > > in the day that i speak of, records were simple static blocks that > contained > data in a certain defined order... today's records have methods, too, > which are > more like objects back then... i forget the difference between yesterday's > objects and today's... > But back in the days the objects were already different from records. And yes, both are again different from classes. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/17/19 1:54 AM, Sven Barth via fpc-devel wrote: schrieb am Mo., 17. Juni 2019, 02:07: what always confused me these days is that records and objects were one thing back in the (TP6) day but today they are something quite different... i had to be very careful when i wrote my satellite TLE management tool because of these differences... Ehm... TP style objects were already quite different to records back in TP days. yes... what i'm saying is that today's are different and that's what confuses me... After all the former supported inheritance and (virtual) methods while the later supported variant parts. in the day that i speak of, records were simple static blocks that contained data in a certain defined order... today's records have methods, too, which are more like objects back then... i forget the difference between yesterday's objects and today's... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
schrieb am Mo., 17. Juni 2019, 02:07: > On 6/16/19 6:44 PM, Ryan Joseph wrote: > > > > > >> On Jun 16, 2019, at 6:00 PM, Benito van der Zander > wrote: > >> > >> Objects are much more useful than classes or records > > > > Now that’s an inflammatory statement! :) But seriously, I do miss record > inheritance from C++, C#, Swift when I’m in Pascal. > > > what always confused me these days is that records and objects were one > thing > back in the (TP6) day but today they are something quite different... i > had to > be very careful when i wrote my satellite TLE management tool because of > these > differences... > Ehm... TP style objects were already quite different to records back in TP days. After all the former supported inheritance and (virtual) methods while the later supported variant parts. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
On 6/16/19 6:44 PM, Ryan Joseph wrote: On Jun 16, 2019, at 6:00 PM, Benito van der Zander wrote: Objects are much more useful than classes or records Now that’s an inflammatory statement! :) But seriously, I do miss record inheritance from C++, C#, Swift when I’m in Pascal. what always confused me these days is that records and objects were one thing back in the (TP6) day but today they are something quite different... i had to be very careful when i wrote my satellite TLE management tool because of these differences... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On 6/16/19 4:41 PM, Sven Barth via fpc-devel wrote: Am 16.06.2019 um 17:43 schrieb wkitt...@windstream.net: On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this off that i've found... they want you to use their interface to read conversations and your sent message is included in there slotted in where it should be... I see my own messages both on the GMail Android app as well as Thunderbird. that's weird... i pull my gmail via pop3 in to my tbird and never get any of my list posts back... i'm on 10+ lists... some with this account and others with my gmail... the gmail account never sends back my messages when i pop them... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
I miss the sushi in Japan too my dude.--Alexander Grotewohlhttp://dcclost.comOn Jun 16, 2019 6:44 PM, Ryan Joseph wrote: > On Jun 16, 2019, at 6:00 PM, Benito van der Zander wrote: > > Objects are much more useful than classes or records Now that’s an inflammatory statement! :) But seriously, I do miss record inheritance from C++, C#, Swift when I’m in Pascal. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
> On Jun 16, 2019, at 6:00 PM, Benito van der Zander wrote: > > Objects are much more useful than classes or records Now that’s an inflammatory statement! :) But seriously, I do miss record inheritance from C++, C#, Swift when I’m in Pascal. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
Hi',
I don't see a need to add management operators to objects. Objects
have constructors and destructors, so they don't need Initialize and
Finalize operators
One need would be to automatically call the destructor
It could make the code much simpler, especially when it also replaces
try..finally, and prevent memory leaks
Just leave the poor, old objects alone.
Objects are much more useful than classes or records
Bye,
Benito
Am 15.06.19 um 18:50 schrieb Sven Barth via fpc-devel:
Am 15.06.2019 um 17:17 schrieb Ryan Joseph:
{ I think the old thread “Object upgrades” got broken during the
server move so I’ll try to start a new thread and see if this gets
posted }
Another question. I’m not sure it’s possible but I did try to add
management operators to objects and found that if a initialize
operator was declared in a unit which was precompiled and then
inherited from an object in another unit which declared another
initialize operators, the initialize operator would be called twice.
The issue is that the operator is compiled into some other code which
always gets called when the object is used as a var type. Is there
any work around to that? The options I’m aware of are:
1) don’t allow management operators in objects (that would be very
unfortunate indeed).
2) don’t allow subclasses to redeclare a management operator (that
seems ok since the operator can call a virtual method from the base
class).
3) allow overriding of operators. I don’t think that would be make
sense or perhaps even possible.
I don't see a need to add management operators to objects. Objects
have constructors and destructors, so they don't need Initialize and
Finalize operators and they have a defined assignment operation. Just
leave the poor, old objects alone.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Am 16.06.2019 um 17:43 schrieb wkitt...@windstream.net: On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this off that i've found... they want you to use their interface to read conversations and your sent message is included in there slotted in where it should be... I see my own messages both on the GMail Android app as well as Thunderbird. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On 6/16/19 10:23 AM, Ryan Joseph wrote: Charlie, I’m still not seeing my own messages posted if gmail can determine that a message coming in from a list is one you sent, it does not pass it on back to you... there's no way to turn this off that i've found... they want you to use their interface to read conversations and your sent message is included in there slotted in where it should be... -- NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list unless* *a signed and pre-paid contract is in effect with us.* ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 15, 2019, at 11:40 AM, Karoly Balogh (Charlie/SGR) > wrote: > > Hi, > > On Sat, 15 Jun 2019, J. Gareth Moreton wrote: > >> Ryan Joseph requested that I reply to this to show that it's in the >> mailing list. Hopefully the technical problems can be resolved! > > There was an issue affecting GMail users, and GMail's SMTP servers over > IPv6. This has been resolved by now. (By disabling IPv6, which is somehow > always the easiest solution for IPv6 problems...) Charlie, I’m still not seeing my own messages posted even though I’m seeing others and I can confirm via the archives my messages are being received. Is this a problem with the server or my email client? If you happened to notice I was having problems with my SMTP server so I switched to Gmail, which was working for a week or so until the server went down. Thanks. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
Ryan Joseph schrieb am Sa., 15. Juni 2019, 20:43: > > > > On Jun 15, 2019, at 12:50 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > I don't see a need to add management operators to objects. Objects have > constructors and destructors, so they don't need Initialize and Finalize > operators and they have a defined assignment operation. Just leave the > poor, old objects alone. > > It’s not about objects as much as record inheritance (which as I was told > will not be happening). I don’t see why Pascal got left out of this one > particular thing but since we’ve always had objects it only makes sense to > keep them up to date. Not sure why there would be any resistance to this. > Making a mode switch for “advanced objects” seems sensible enough to me > (unless you want to make a whole new keyworld like “struct” or something). > I neither see a reason for record inheritance nor for the objects to be more like records. Pascal doesn't need to replicate each and every feature of other languages. What we need is libraries to help users do their work. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
> On Jun 15, 2019, at 12:50 PM, Sven Barth via fpc-devel > wrote: > > I don't see a need to add management operators to objects. Objects have > constructors and destructors, so they don't need Initialize and Finalize > operators and they have a defined assignment operation. Just leave the poor, > old objects alone. It’s not about objects as much as record inheritance (which as I was told will not be happening). I don’t see why Pascal got left out of this one particular thing but since we’ve always had objects it only makes sense to keep them up to date. Not sure why there would be any resistance to this. Making a mode switch for “advanced objects” seems sensible enough to me (unless you want to make a whole new keyworld like “struct” or something). Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades (new)
Am 15.06.2019 um 17:17 schrieb Ryan Joseph:
{ I think the old thread “Object upgrades” got broken during the server move so
I’ll try to start a new thread and see if this gets posted }
Another question. I’m not sure it’s possible but I did try to add management
operators to objects and found that if a initialize operator was declared in a
unit which was precompiled and then inherited from an object in another unit
which declared another initialize operators, the initialize operator would be
called twice.
The issue is that the operator is compiled into some other code which always
gets called when the object is used as a var type. Is there any work around to
that? The options I’m aware of are:
1) don’t allow management operators in objects (that would be very unfortunate
indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok
since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or
perhaps even possible.
I don't see a need to add management operators to objects. Objects have
constructors and destructors, so they don't need Initialize and Finalize
operators and they have a defined assignment operation. Just leave the
poor, old objects alone.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Hi, On Sat, 15 Jun 2019, J. Gareth Moreton wrote: > Ryan Joseph requested that I reply to this to show that it's in the > mailing list. Hopefully the technical problems can be resolved! There was an issue affecting GMail users, and GMail's SMTP servers over IPv6. This has been resolved by now. (By disabling IPv6, which is somehow always the easiest solution for IPv6 problems...) Charlie___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Thanks, I’m seeing this now. I can’t find the thread in the archives though but I see my new thread with the same name appear in the archives. My email client may be messing with me also because I don’t see it yet. Sorry for the noise if you guys are seeing everything. > On Jun 15, 2019, at 11:35 AM, J. Gareth Moreton > wrote: > > Ryan Joseph requested that I reply to this to show that it's in the mailing > list. Hopefully the technical problems can be resolved! Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Ryan Joseph requested that I reply to this to show that it's in the
mailing list. Hopefully the technical problems can be resolved!
Gareth aka. Kit
On 15/06/2019 15:25, Ryan Joseph wrote:
On Jun 12, 2019, at 9:39 AM, Ryan Joseph wrote:
{ resending this, I think it got lost during the server move since I’m not
seeing it in the archives }
{ I think the server is back up so I’m resending this for the 3rd time to see
if it gets through. }
Another question. I’m not sure it’s possible but I did try to add management
operators to objects and found that if a initialize operator was declared in a
unit which was precompiled and then inherited from an object in another unit
which declared another initialize operators, the initialize operator would be
called twice.
The issue is that the operator is compiled into some other code which always
gets called when the object is used as a var type. Is there any work around to
that? The options I’m aware of are:
1) don’t allow management operators in objects (that would be very unfortunate
indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok
since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Object upgrades (new)
{ I think the old thread “Object upgrades” got broken during the server move so
I’ll try to start a new thread and see if this gets posted }
Another question. I’m not sure it’s possible but I did try to add management
operators to objects and found that if a initialize operator was declared in a
unit which was precompiled and then inherited from an object in another unit
which declared another initialize operators, the initialize operator would be
called twice.
The issue is that the operator is compiled into some other code which always
gets called when the object is used as a var type. Is there any work around to
that? The options I’m aware of are:
1) don’t allow management operators in objects (that would be very unfortunate
indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok
since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 12, 2019, at 9:39 AM, Ryan Joseph wrote:
>
> { resending this, I think it got lost during the server move since I’m not
> seeing it in the archives }
{ I think the server is back up so I’m resending this for the 3rd time to see
if it gets through. }
Another question. I’m not sure it’s possible but I did try to add management
operators to objects and found that if a initialize operator was declared in a
unit which was precompiled and then inherited from an object in another unit
which declared another initialize operators, the initialize operator would be
called twice.
The issue is that the operator is compiled into some other code which always
gets called when the object is used as a var type. Is there any work around to
that? The options I’m aware of are:
1) don’t allow management operators in objects (that would be very unfortunate
indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok
since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
{ resending this, I think it got lost during the server move since I’m not
seeing it in the archives }
Another question. I’m not sure it’s possible but I did try to add management
operators to objects and found that if a initialize operator was declared in a
unit which was precompiled and then inherited from an object in another unit
which declared another initialize operators, the initialize operator would be
called twice.
The issue is that the operator is compiled into some other code which always
gets called when the object is used as a var type. Is there any work around to
that? The options I’m aware of are:
1) don’t allow management operators in objects (that would be very unfortunate
indeed).
2) don’t allow subclasses to redeclare a management operator (that seems ok
since the operator can call a virtual method from the base class).
3) allow overriding of operators. I don’t think that would be make sense or
perhaps even possible.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 4:07 PM, Sven Barth via fpc-devel > wrote: > > Of course the dereferentiation of PBase while always have the size of TBase. > That's the point of a pointer. You need to add a static Create method to each > subclass if you want to use that concept. And no kind of TClassSelf or > whatever will help you there as you'd need virtual class functions for that > and objects don't support those just as they don't support a "class of" kind > of type. There's a reason why classes are superior in nearly all cases after > all. > Got it. That aside the operators are the important thing anyways. Another question. I’m not sure it’s possible but I did try to add management operators to objects and found that if a initialize operator was declared in a unit which was precompiled and then inherited from an object in another unit which declared another initialize operators, the initialize operator would be called twice. The issue is that the operator is compiled into some other code which always gets called when the object is used as a var type. Is there any work around to that? The options I’m aware of are: 1) don’t allow management operators in objects (that would be very unfortunate indeed). 2) don’t allow subclasses to redeclare a management operator (that seems ok since the operator can call a virtual method from the base class). 3) allow overriding of operators. I don’t think that would be make sense or perhaps even possible. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 4:04 PM, Sven Barth via fpc-devel > wrote: > > Ehm... You are aware that you can simply use TRecord here? > Yes but it’s lots of redundancy. It’s nice to have a type that says “the type of the structure”, the same as what “self” basically means but at the class level (compile time). TObject has ClassType but a compile time construct would be a nice companion. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Ryan Joseph schrieb am Mo., 10. Juni 2019, 21:31: > > > > On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote: > > > > Result in your example is the size of a pointer in all cases, which is > fine / exactly what you'd expect it to be. > > > > Sorry, if I dereference the size is still of TBase. I don’t think “result" > is actually changing depending on the class type. This may have something > to do with the way new works though. How can we fix this? > Of course the dereferentiation of PBase while always have the size of TBase. That's the point of a pointer. You need to add a static Create method to each subclass if you want to use that concept. And no kind of TClassSelf or whatever will help you there as you'd need virtual class functions for that and objects don't support those just as they don't support a "class of" kind of type. There's a reason why classes are superior in nearly all cases after all. Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Ryan Joseph schrieb am Mo., 10. Juni 2019, 20:31: > > > > On Jun 10, 2019, at 2:26 PM, Sven Barth via fpc-devel < > fpc-devel@lists.freepascal.org> wrote: > > > > Also FPC doesn’t have something “self” but for the class level so you > need to cast the return value. Btw adding “ClassSelf” is something I’ve > wanted for a while, so I can reference the class type within the class > declaration. > > > > What are you talking about here? > > > > Like this. I would prefer there being a “ClassSelf” type or something > which acted as TSelf. > > type > TRecord = record > public type > TSelf = TRecord; > public > class operator + (left: TSelf; right: integer): > TSelf; > class operator + (left: TSelf; right: integer): > TSelf; > class operator - (left: TSelf; right: integer): > TSelf; > class operator * (left: TSelf; right: integer): > TSelf; > class operator / (left: TSelf; right: integer): > TSelf; > class operator ** (left: TSelf; right: integer): > TSelf; > class operator div (left: TSelf; right: integer): > TSelf; > class operator mod (left: TSelf; right: integer): > TSelf; > Ehm... You are aware that you can simply use TRecord here? Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 3:25 PM, Ben Grasset wrote:
>
> Result in your example is the size of a pointer in all cases, which is fine /
> exactly what you'd expect it to be.
>
Sorry, if I dereference the size is still of TBase. I don’t think “result" is
actually changing depending on the class type. This may have something to do
with the way new works though. How can we fix this?
type
PBase = ^TBase;
TBase = object
constructor Initialize;
class function Create: PBase; static;
end;
class function TBase.Create: PBase;
begin
new(result, Initialize);
writeln('create: ', sizeof(result^));
end;
constructor TBase.Initialize;
begin
writeln('create tfoo')
end;
type
PChild = ^TChild;
TChild = object (TBase)
y: string;
end;
var
c: PChild;
begin
c := PChild(TChild.Create);
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On Mon, Jun 10, 2019 at 1:56 PM Ryan Joseph wrote: > I don’t think this is possible. Just did little test and the size of > “result” is always the size of the base class. Does this work? > Result in your example is the size of a *pointer* in all cases, which is fine / exactly what you'd expect it to be. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 2:26 PM, Sven Barth via fpc-devel > wrote: > > Also FPC doesn’t have something “self” but for the class level so you need to > cast the return value. Btw adding “ClassSelf” is something I’ve wanted for a > while, so I can reference the class type within the class declaration. > > What are you talking about here? > Like this. I would prefer there being a “ClassSelf” type or something which acted as TSelf. type TRecord = record public type TSelf = TRecord; public class operator + (left: TSelf; right: integer): TSelf; class operator + (left: TSelf; right: integer): TSelf; class operator - (left: TSelf; right: integer): TSelf; class operator * (left: TSelf; right: integer): TSelf; class operator / (left: TSelf; right: integer): TSelf; class operator ** (left: TSelf; right: integer): TSelf; class operator div (left: TSelf; right: integer): TSelf; class operator mod (left: TSelf; right: integer): TSelf; Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Ryan Joseph schrieb am Mo., 10. Juni 2019, 19:56: > Also FPC doesn’t have something “self” but for the class level so you need > to cast the return value. Btw adding “ClassSelf” is something I’ve wanted > for a while, so I can reference the class type within the class declaration. > What are you talking about here? Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt wrote: Records do. Objects not. Ooops forget the mode switch. :) I’m seeing objects have properties. Are you sure? Maybe they got added recently. Well, at the time I used objects, they didn't exist. But I haven't used objects in a long time, so maybe they got added quite some time ago. I will check and update the docs when needed. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 1:19 PM, Michael Van Canneyt
> wrote:
>
> I don't think that for classes this should be allowed. Sven and Florian
> already explained the reasons for this in detail.
Yes but that was in regards to binary operators which would have memory
management issues. The operators I listed return boolean so there’s risk. It
would be pretty inconsistent however.
> First of all, I don't think you need to make objects "look" more like classes.
>
> There is nothing wrong with alerting people that they're using a different
> kind of animal when using objects. I for one want to see at a single glance
> what code does. So seeing "New" instead of "Create" alerts me to the fact
> that I am
> dealing with objects. I consider this a plus, and if they start sharing more
> functionality, this plus becomes more important.
>
> So IMO there is no need to change the compiler for this.
> Just add a static function that returns a new instance, which you can call
> "create" if this pleases your sense of beauty or symmetry.
I don’t think this is possible. Just did little test and the size of “result”
is always the size of the base class. Does this work?
Also FPC doesn’t have something “self” but for the class level so you need to
cast the return value. Btw adding “ClassSelf” is something I’ve wanted for a
while, so I can reference the class type within the class declaration.
type
PBase = ^TBase;
TBase = object
x: integer;
constructor Initialize;
class function Create: PBase; static;
end;
class function TBase.Create: PBase;
begin
writeln('create: ', sizeof(result));
new(result, Initialize);
end;
constructor TBase.Initialize;
begin
writeln('create tfoo')
end;
type
PChild = ^TChild;
TChild = object (TBase)
y: string;
end;
var
c: PBase;
begin
c := TChild.Create;
end.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 1:20 PM, Michael Van Canneyt > wrote: > > Records do. Objects not. Ooops forget the mode switch. :) I’m seeing objects have properties. Are you sure? Maybe they got added recently. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: (same for properties, BTW) Just noticed this. Yes, why don’t records have properties? Seems like an omission. Records do. Objects not. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On Mon, 10 Jun 2019, Ryan Joseph wrote: On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt wrote: So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and claim they are the only way to get inheritance for records since I’m 99% certain FPC is never going to allow record inheritance. Make that 100% :-) Very well. That means objects are our only option. Yes. Personally I have an immediate use for objects but I need them to have operator overloads as members of the object for generics support (this isn’t possible with the stand-alone function operator overloads). Could we at least make this upgrade to objects with a mode switch? If it is under a mode switch (advancedobjects, similar to advancedrecords), I see no harm in this. I would even say it is logical to add it. I always felt strange that records have it but objects not. (same for properties, BTW) Great, one person on my side. It’s a totally trivial change also so that’s good news. I imagine it is indeed trivial. My original idea was to make these available for classes also but Sven shot that idea down. Is that the final position? There are at least the following operators which could be safely added to classes. class operator not (left: TSelf): boolean; class operator <> (left: TSelf; right: TRight): boolean; class operator < (left: TSelf; right: TRight): boolean; class operator > (left: TSelf; right: TRight): boolean; class operator <= (left: TSelf; right: TRight): boolean; class operator >= (left: TSelf; right: TRight): boolean; class operator = (left: TSelf; right: TRight): boolean; class operator >< (left: TSelf; right: TRight): boolean; class operator in (left: TSelf; right: TRight): boolean; I don't think that for classes this should be allowed. Sven and Florian already explained the reasons for this in detail. If that’s rejected then I guess we’re left with “advancedobjects” mode switch? Yes. Your other proposal of changing the memory use is of a different caliber, because it fundamentally changes the way objects are used. The objections against that proposal remain intact. What happened is that classes introduced this idea in FPC that TClassName.Create is syntax for allocation (in the trunk even dynamic arrays use this syntax now) so I wanted to extend that to the legacy “new” function which just looks wrong now as a result. Is there anything we could do to make “new” more modern look like classes? First of all, I don't think you need to make objects "look" more like classes. There is nothing wrong with alerting people that they're using a different kind of animal when using objects. I for one want to see at a single glance what code does. So seeing "New" instead of "Create" alerts me to the fact that I am dealing with objects. I consider this a plus, and if they start sharing more functionality, this plus becomes more important. So IMO there is no need to change the compiler for this. Just add a static function that returns a new instance, which you can call "create" if this pleases your sense of beauty or symmetry. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt > wrote: > > (same for properties, BTW) Just noticed this. Yes, why don’t records have properties? Seems like an omission. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On Jun 10, 2019, at 11:25 AM, Michael Van Canneyt > wrote: > >> >> So where do we stand on this? I have a patch to make it possible allow >> operator overloads that are members of objects but I hear that objects are >> legacy types. I disagree of course and claim they are the only way to get >> inheritance for records since I’m 99% certain FPC is never going to allow >> record inheritance. > > Make that 100% :-) Very well. That means objects are our only option. > >> Personally I have an immediate use for objects but I >> need them to have operator overloads as members of the object for generics >> support (this isn’t possible with the stand-alone function operator >> overloads). >> >> Could we at least make this upgrade to objects with a mode switch? > > If it is under a mode switch (advancedobjects, similar to advancedrecords), I > see no harm in this. I would even say it is logical to add it. I always felt > strange that records have it but objects not. (same for properties, BTW) Great, one person on my side. It’s a totally trivial change also so that’s good news. My original idea was to make these available for classes also but Sven shot that idea down. Is that the final position? There are at least the following operators which could be safely added to classes. class operator not (left: TSelf): boolean; class operator <> (left: TSelf; right: TRight): boolean; class operator < (left: TSelf; right: TRight): boolean; class operator > (left: TSelf; right: TRight): boolean; class operator <= (left: TSelf; right: TRight): boolean; class operator >= (left: TSelf; right: TRight): boolean; class operator = (left: TSelf; right: TRight): boolean; class operator >< (left: TSelf; right: TRight): boolean; class operator in (left: TSelf; right: TRight): boolean; If that’s rejected then I guess we’re left with “advancedobjects” mode switch? > > Your other proposal of changing the memory use is of a different caliber, > because it fundamentally changes the way objects are used. The objections > against that proposal remain intact. What happened is that classes introduced this idea in FPC that TClassName.Create is syntax for allocation (in the trunk even dynamic arrays use this syntax now) so I wanted to extend that to the legacy “new” function which just looks wrong now as a result. Is there anything we could do to make “new” more modern look like classes? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On Mon, 10 Jun 2019, Ryan Joseph wrote: So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and claim they are the only way to get inheritance for records since I’m 99% certain FPC is never going to allow record inheritance. Make that 100% :-) Personally I have an immediate use for objects but I need them to have operator overloads as members of the object for generics support (this isn’t possible with the stand-alone function operator overloads). Could we at least make this upgrade to objects with a mode switch? If it is under a mode switch (advancedobjects, similar to advancedrecords), I see no harm in this. I would even say it is logical to add it. I always felt strange that records have it but objects not. (same for properties, BTW) Your other proposal of changing the memory use is of a different caliber, because it fundamentally changes the way objects are used. The objections against that proposal remain intact. Michael.___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
So where do we stand on this? I have a patch to make it possible allow operator overloads that are members of objects but I hear that objects are legacy types. I disagree of course and claim they are the only way to get inheritance for records since I’m 99% certain FPC is never going to allow record inheritance. Personally I have an immediate use for objects but I need them to have operator overloads as members of the object for generics support (this isn’t possible with the stand-alone function operator overloads). Could we at least make this upgrade to objects with a mode switch? Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On Thu, 2019-05-30 at 01:42 +0200, Sven Barth via fpc-devel wrote: > Nikolay Nikolov schrieb am Do., 30. Mai 2019, > 00:52: > > So, what's with all this FUD surrounding operator overloading not > > working with objects? Did you even test it, before screaming > > "legacy!"? :) > > He's talking about operator overloads that are members of the object > like what was introduced for records and not about global operators. > And yes, there's a small, but important difference: generics can only > pick up the global ones if the unit containing the operator overloads > was used inside the unit the generic was declared in (not specialized > in). Thanks for the clarification. I didn't know about this difference and thought it was just different syntax (namely Delphi copying C++ and C# instead of following FPC, which had operator overloading long before Delphi). Nikolay ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Nikolay Nikolov schrieb am Do., 30. Mai 2019, 00:52: > So, what's with all this FUD surrounding operator overloading not > working with objects? Did you even test it, before screaming "legacy!"? :) > He's talking about operator overloads that are members of the object like what was introduced for records and not about global operators. And yes, there's a small, but important difference: generics can only pick up the global ones if the unit containing the operator overloads was used inside the unit the generic was declared in (not specialized in). Regards, Sven > ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
On 5/27/19 1:08 AM, Ryan Joseph wrote:
Records don’t have a VMT table and overriding but otherwise they’re the same
afaik (constructors don’t work the same also). Operator overloads simply aren’t
enabled for objects because apparently they’re a legacy syntax but as you
pointed out they’re still useful.
Are you sure about the operator overloads? I'm pretty sure I've used
them on objects since FPC 1.0.x (even before that) and they've always
worked fine. They are also used by some of the PTCPas example programs,
which are shipped with FPC and also work fine. I even tested it again
with a trivial example. Here it is: It works with FPC 3.0.4 and almost
certainly FPC trunk as well:
type
TMyObject = object
end;
operator + (a, b: TMyObject) res: TMyObject;
begin
Writeln('Plus operator! yeah!');
end;
var
a, b, c: TMyObject;
begin
c := a + b;
end.
So, what's with all this FUD surrounding operator overloading not
working with objects? Did you even test it, before screaming "legacy!"? :)
Nikolay
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On May 26, 2019, at 5:50 PM, Kostas Michalopoulos > wrote: > > Do records support inheritance in next FPC? 3.0.4 doesn't seem to > allow that and this is the main reason i use objects when i need value > types. No, only objects. Objects don’t have operator overloads though so they can’t be used in some cases. Of course records could support inheritance but I think that’s even more contentious (and instrusive to the compiler) than adding operator overloads to objects. > > Actually, what are the differences between records and objects that > make it impossible for records to get objects' features or objects to > get records' features so there is no difference between the two and > one become alias for the other? Records don’t have a VMT table and overriding but otherwise they’re the same afaik (constructors don’t work the same also). Operator overloads simply aren’t enabled for objects because apparently they’re a legacy syntax but as you pointed out they’re still useful. Being able to use subclassing for TVec2 -> TVec3 -> TVec4 objects would be really useful. I hope the compiler team reconsiders this. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Do records support inheritance in next FPC? 3.0.4 doesn't seem to allow that and this is the main reason i use objects when i need value types. Actually, what are the differences between records and objects that make it impossible for records to get objects' features or objects to get records' features so there is no difference between the two and one become alias for the other? I often want value types and find myself having to choose between the two depending on the features i need. It'd be very nice if both had the same features or at least one became a full superset of the other. On Fri, May 24, 2019 at 10:50 AM Sven Barth via fpc-devel wrote: > > Ryan Joseph schrieb am Fr., 24. Mai 2019, 01:20: >> >> I’m doing some work to upgrade old-style objects including class >> operators/management operators and better construction. > > > Please don't. They're legacy types (even though we don't consider them > obsolete) and geared towards the TP behavior and compatibility. > > Regards, > Sven > ___ > fpc-devel maillist - fpc-devel@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On May 26, 2019, at 2:58 PM, Sven Barth via fpc-devel > wrote: > > Keeping them alive is not the same as developing new syntaxes for them (and > for objects that *would* be a new syntax). Also we fix bugs for them which > Delphi does not do. > Can we at least do operators overloads for them then? It’s such a trivial change and makes it possible to use inheritance for records (I can do this in C++,C#,Swift which is very nice). Specifically I was trying to refactor some code and using subclasses for vectors would be really nice but without operator overloads it’s not possible. Also, since we’re not getting ARC classes it looks like, management operators for objects would make it possible to use a base class for “boxing” managed classes. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Ryan Joseph schrieb am So., 26. Mai 2019,
17:05:
>
>
> > On May 24, 2019, at 4:49 AM, Sven Barth via fpc-devel <
> fpc-devel@lists.freepascal.org> wrote:
> >
> > Please don't. They're legacy types (even though we don't consider them
> obsolete) and geared towards the TP behavior and compatibility.
> >
>
> { resending this again because the old message got blocked }
>
> I thought FPC was trying to keep them alive? Objects are still the only
> way to do inheritance for records but they lack operator overloads. The
> syntax for new/dispose certainly feels legacy but that’s not as important
> as the class operators.
>
Keeping them alive is not the same as developing new syntaxes for them (and
for objects that *would* be a new syntax). Also we fix bugs for them which
Delphi does not do.
Regards,
Sven
>
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
> On May 24, 2019, at 4:49 AM, Sven Barth via fpc-devel
> wrote:
>
> Please don't. They're legacy types (even though we don't consider them
> obsolete) and geared towards the TP behavior and compatibility.
>
{ resending this again because the old message got blocked }
I thought FPC was trying to keep them alive? Objects are still the only way to
do inheritance for records but they lack operator overloads. The syntax for
new/dispose certainly feels legacy but that’s not as important as the class
operators.
Regards,
Ryan Joseph
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Object upgrades
Ryan Joseph schrieb am Fr., 24. Mai 2019, 01:20: > I’m doing some work to upgrade old-style objects including class > operators/management operators and better construction. > Please don't. They're legacy types (even though we don't consider them obsolete) and geared towards the TP behavior and compatibility. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Object upgrades
I’m doing some work to upgrade old-style objects including class operators/management operators and better construction. It’s natural to do ClassType.Constructor which translates to a “new” statement but not sure about what can be done for destructors. Maybe call the destructor directly like “o^.destroy” which translates to a “dispose” statement, or an implicit .free method? I assume this needs to be put behind a mode switch also. Any ideas? type TMyObject = object constructor Create; destructor Destroy; end; constructor TMyObject.Create; begin end; destructor TMyObject.Destroy; begin end; var o: TMyObjectPtr; begin // new(o, Create); o := TMyObject.Create; // what to do here??? o^.destroy; // implicit free method? o^.free; end. Regards, Ryan Joseph ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
