On Friday 11 November 2016 07:48:54 Lars wrote:
> On Thu, November 10, 2016 11:04 pm, Martin Schreiber wrote:
> > On Friday 11 November 2016 04:21:31 Lars wrote:
> >> Replying to an old thread in my inbox. Apologies if it's obsolete as it
> >> is a month old.
> >
> > I don't think such themes are
On Thu, November 10, 2016 11:04 pm, Martin Schreiber wrote:
> On Friday 11 November 2016 04:21:31 Lars wrote:
>
>>
>> Replying to an old thread in my inbox. Apologies if it's obsolete as it
>> is a month old.
>>
> I don't think such themes are allowed in fpc-pascal.
If an oberon like garbage
On Friday 11 November 2016 04:21:31 Lars wrote:
>
> Replying to an old thread in my inbox. Apologies if it's obsolete as it is
> a month old.
>
I don't think such themes are allowed in fpc-pascal. Please continue the
discussion on MSEide+MSEgui mailinglist:
On Wed, October 5, 2016 9:54 pm, Martin Schreiber wrote:
> On Thursday 06 October 2016 00:16:22 Tony Whyman wrote:
>
>> On 05/10/16 23:03, Graeme Geldenhuys wrote:
>>
>>> Martin Schreiber recently mentioned in another Interface discussion
>>> that there is a very good reason he doesnât use COM
On 07/10/2016 18:33 μμ, Marcos Douglas wrote:
We don't need "clean up properly" instances that is interface-based.
If this solve the problem for contained objects, I'll do it!
BUT, if I do this I can forget all about TContainedObject or
TAggregatedObject? If I can't, this not make sense.
OK
On 07/10/2016 18:33 μμ, Marcos Douglas wrote:
The problem is: The user (programmer) needs to know (previously) if
such classes can or not be used as a contained object!
True then again that is true for all objects not only interfaces. You
need to understand what they address how they address
On Fri, Oct 7, 2016 at 12:33 PM, Marcos Douglas wrote:
>> For me extending the TContainedObject to support both contained and stand
>> alone use is trivial I bet you can do it as well now that you know where to
>> look.
>
> That is a good idea.
>
> If is possible. If doesn't
On Fri, Oct 7, 2016 at 11:46 AM, stdreamer wrote:
> On 07/10/2016 16:12 μμ, Marcos Douglas wrote:
>>
>> The team shouldn't know about the hierarchy; about how was implemented
>> these classes.
>> They can use TDataStream directly or as a contained object.
>> But as I
On Fri, Oct 7, 2016 at 11:02 AM, Tony Whyman
wrote:
> ...As a workaround for the interface delegation problem it works, as long as
> you don't try and use TDelegateClass on its own
As I said... sad.
Regards,
Marcos Douglas
On 07/10/2016 16:12 μμ, Marcos Douglas wrote:
The team shouldn't know about the hierarchy; about how was implemented
these classes.
They can use TDataStream directly or as a contained object.
But as I understood, we need to use TContainedObject or
TAggregatedObject only in these "special cases"
On 07/10/16 12:29, stdreamer wrote:
No! Delegation is a mechanism, when used, you have to know exactly how
it works. Delegation is only used to minimize code instead of writing
a bunch of procedures that call the contained object's methods. That's
it and nothing more.
I believe that I now
On 07/10/16 12:29, stdreamer wrote:
The point is that you are trying to equate delegation with contained
objects/interfaces and that is not what delegates are about.
Delegation has nothing to do with the underlined mechanism you choose
to use.
Hmm, not so sure about that. I have updated my
On Fri, Oct 7, 2016 at 8:29 AM, stdreamer wrote:
> No! Delegation is a mechanism, when used, you have to know exactly how it
> works.
The "mechanism" here is about using [implements].
We have to know what is the sintaxe:
- declare a property
- use [implements] keyword
-
On Fri, Oct 7, 2016 at 6:49 AM, Tony Whyman
wrote:
> The problem being referred to is the functionality described here:
>
> http://freepascal.org/docs-html/current/ref/refse44.html#x98-127.4
>
> under the title "Interface delegation". The word "contained" does
On Fri, Oct 7, 2016 at 7:30 AM, Tony Whyman
wrote:
> Reference Counted interfaces must be easy to use and should not require the
> user to have advanced knowledge of how they work. If that last point is true
> then all the that nay-sayers that argue against
On Fri, Oct 7, 2016 at 6:31 AM, stdreamer wrote:
>
> Τhe problem of a contained interface has already been solved, see the
> TContainedObject. To sum it up a contained object reference counting
> mechanism increments and decrements the container's reference counter it
>
On 07/10/2016 13:30 μμ, Tony Whyman wrote:
On 07/10/16 11:08, stdreamer wrote:
I see no rabbit hole or any other problem in the code posted so far
except perhaps lack of proper clean up which might be intentional.
A Rabbit Hole is not the same as a bug and my point is not that
"interface
On 07/10/16 11:08, stdreamer wrote:
I see no rabbit hole or any other problem in the code posted so far
except perhaps lack of proper clean up which might be intentional.
A Rabbit Hole is not the same as a bug and my point is not that
"interface delegation" does not work, it is that it is
On 07/10/2016 12:49 μμ, Tony Whyman wrote:
You seem to be playing around with words. Perhaps I am guilty of sloppy
English when I say "interface is copied" when meaning "an interface
reference is copied". However, this does not change the underlying problem.
The problem being referred to is the
You seem to be playing around with words. Perhaps I am guilty of sloppy
English when I say "interface is copied" when meaning "an interface
reference is copied". However, this does not change the underlying problem.
The problem being referred to is the functionality described here:
On 05/10/2016 19:13 μμ, Tony Whyman wrote:
Marcos,
I believe I concluded that this could be a bug or feature. Either way it
is a Bear Trap waiting for the unwary programmer and it would be nice if
in some way the implementation could be improved. The problem, as I see
it is:
Basics:
1.
Hi Graeme,
On Thu, Oct 6, 2016 at 12:05 PM, Graeme Geldenhuys
wrote:
> Hello Marcos,
>
> On 2016-10-06 at 11:41, Marcos Douglas wrote:
>
>> The COM and CORBA names, are both wrong.
>> When you say COM, everybody thinks on Windows... that sad.
>
>
> Yes, both names
On Thu, Oct 6, 2016 at 11:57 AM, Graeme Geldenhuys
wrote:
> Hello Marcos,
>
> On 2016-10-06 at 11:25, Marcos Douglas wrote:
>
>> you need to declarate
>> two variables to do one job.
>> I don't like that and I think shouldn't be necessary.
>
> Well, to be fair, that
Hello Marcos,
On 2016-10-06 at 11:41, Marcos Douglas wrote:
> The COM and CORBA names, are both wrong.
> When you say COM, everybody thinks on Windows... that sad.
Yes, both names are horribly inaccurate. Unfortunately I don't see FPC
developers rectifying that any time soon. :-/
Regards,
Hello Marcos,
On 2016-10-06 at 11:25, Marcos Douglas wrote:
> you need to declarate
> two variables to do one job.
> I don't like that and I think shouldn't be necessary.
Well, to be fair, that example is not representative of a real-world
application. In a real-world app, I would not declare
On Thu, Oct 6, 2016 at 7:36 AM, Graeme Geldenhuys
wrote:
> On 2016-10-06 02:49, Marcos Douglas wrote:
>> I understand you, but reference counting help us to write a better
>> code, more object-oriented.
>
> That's got nothing to do with reference counting
On Thu, Oct 6, 2016 at 7:30 AM, Graeme Geldenhuys
wrote:
> On 2016-10-05 16:26, Marcos Douglas wrote:
>> So, I coded a new example — more simpler, I think — to demonstrate the same
>> problem and prove that there is some wrong that is causing a memleak.
>
> And here
On Thu, Oct 6, 2016 at 7:11 AM, Graeme Geldenhuys
wrote:
> On 2016-10-06 02:34, Marcos Douglas wrote:
>> But, the result was the same, even using D7.
>> So, is this by design? Sad...
>
> Sad and nasty indeed. But it seems it is “by design” or done for “Delphi
>
On 06/10/16 11:08, Graeme Geldenhuys wrote:
I've seem some
COM Interface code where they had to resort to using raw Pointer types
etc to try and avoid reference counting and causing unexpected memory
leaks.
I have also seen plenty of examples of poor coding with classes, but the
fact that
On 2016-10-06 02:49, Marcos Douglas wrote:
> I understand you, but reference counting help us to write a better
> code, more object-oriented.
That's got nothing to do with reference counting functionality. I use
object-oriented coding practices all the time, but I don't need
reference counting
On 2016-10-05 16:26, Marcos Douglas wrote:
> So, I coded a new example — more simpler, I think — to demonstrate the same
> problem and prove that there is some wrong that is causing a memleak.
And here is that example converted to use CORBA style interfaces and no
memory leaks.
Program output:
On 2016-10-06 02:34, Marcos Douglas wrote:
> But, the result was the same, even using D7.
> So, is this by design? Sad...
Sad and nasty indeed. But it seems it is “by design” or done for “Delphi
compatibility”.
It would be interesting to know what Delphi developers think of this.
You should post
On 2016-10-05 23:16, Tony Whyman wrote:
> Used properly reference counted interfaces are very powerful and allow
> for some very elegant programming. Do you complain about AnsiStrings?
I have very powerful and elegant programming with CORBA interfaces too.
;-) Also as Martin mentioned, reference
On 2016-10-06 05:54, Martin Schreiber wrote:
> Recently I had to revive my stone old AMD-K6 PC with Windows 95. What marvel,
> that relict with its age-old applications provides a better user experience,
> is snappier, more convenient and more productive than my newest Linux machine
> with the
On Thursday 06 October 2016 00:16:22 Tony Whyman wrote:
> On 05/10/16 23:03, Graeme Geldenhuys wrote:
> > Martin Schreiber recently mentioned in another Interface discussion that
> > there is a very good reason he doesn’t use COM style interfaces…
> > Reference Counting!
>
> Used properly
On Wed, Oct 5, 2016 at 7:16 PM, Tony Whyman
wrote:
>
> Reference counted interfaces allow you to create classes (and objects) that
> behave in the same way as AnsiStrings. IMHO, a lot of standard packages
> would be greatly improved if they used com interfaces.
I
On Wed, Oct 5, 2016 at 7:07 PM, Tony Whyman
wrote:
>
>[...]
>
> No, if you explicitly free the provider class there will be no memleaks. My
> point is that having to do this is counter-intuitive and easy to get wrong
> - or to overlook cases where it is necessary.
On Wed, Oct 5, 2016 at 7:03 PM, Graeme Geldenhuys
wrote:
> Martin Schreiber recently mentioned in another Interface discussion that
> there is a very good reason he doesn’t use COM style interfaces…
> Reference Counting!
I understand you, but reference counting
On Wed, Oct 5, 2016 at 6:51 PM, Graeme Geldenhuys
wrote:
> On 2016-10-05 16:26, Marcos Douglas wrote:
>> Here is the output on my machine (Lazarus 1.7 r52880M FPC 3.0.1
>> i386-win32-win32/win64)
>
> Just so you know... bug or not, it seems to have the same
On 05/10/16 23:03, Graeme Geldenhuys wrote:
Martin Schreiber recently mentioned in another Interface discussion that
there is a very good reason he doesn’t use COM style interfaces…
Reference Counting!
Used properly reference counted interfaces are very powerful and allow
for some very elegant
On 05/10/16 19:19, Marcos Douglas wrote:
Hi Tony,
On Wed, Oct 5, 2016 at 1:13 PM, Tony Whyman
wrote:
[...]
7. You are responsible for freeing the object that "provides" the delegated
interface.
But I'm working only using Interfaces. All variables are
On 2016-10-05 16:26, Marcos Douglas wrote:
> So, I coded a new example — more simpler, I think — to demonstrate the same
> problem and prove that there is some wrong that is causing a memleak.
Martin Schreiber recently mentioned in another Interface discussion that
there is a very good reason he
On 2016-10-05 22:51, Graeme Geldenhuys wrote:
> In fact,
> compiled with Delphi 7, the app doesn't quit at all. I had to Ctrl+C it.
Ignore that bit... Looking at the code in detail I see there was a
ReadLn statement at the end. Dope! :)
Regards,
Graeme
On 2016-10-05 16:26, Marcos Douglas wrote:
> Here is the output on my machine (Lazarus 1.7 r52880M FPC 3.0.1
> i386-win32-win32/win64)
Just so you know... bug or not, it seems to have the same behaviour as
with Delphi 7. Compiled with D7 it has the exact same output. In fact,
compiled with Delphi
Hi Tony,
On Wed, Oct 5, 2016 at 1:13 PM, Tony Whyman
wrote:
>
> [...]
>
> 7. You are responsible for freeing the object that "provides" the delegated
> interface.
But I'm working only using Interfaces. All variables are interfaces type.
So, I can't free the
On 05/10/16 16:26, Marcos Douglas wrote:
Tony Whyman had posted on August 10 a problem with the compiler using
Delegates.
He used a workaround to "solve" his problem and the thread died.
Marcos,
I believe I concluded that this could be a bug or feature. Either way it
is a Bear Trap waiting
Hi,
Tony Whyman had posted on August 10 a problem with the compiler using
Delegates.
He used a workaround to "solve" his problem and the thread died.
So, I coded a new example — more simpler, I think — to demonstrate the same
problem and prove that there is some wrong that is causing a memleak.
47 matches
Mail list logo