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
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
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
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
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
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
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
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
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
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
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
> 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
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
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
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
> 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
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
> 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
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
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.
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
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
{ 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
> 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
{ 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
> 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
> 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
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
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
> 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
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
> 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
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
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
> 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
> 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
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.
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
> 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 -
> 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
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
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
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
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
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
> 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
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'
> 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
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
> 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
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
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
52 matches
Mail list logo
