Welcome, Guest
Guest Settings
Help

Thread: Rant: Class Helpers Neutered



Permlink Replies: 422 - Last Post: Mar 26, 2017 6:57 AM Last Post By: Dalija Prasnikar Threads: [ Previous | Next ]
Brandon Staggs

Posts: 500
Registered: 3/3/01
Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 12, 2017 7:14 PM
I know this happened a while ago.

But, seriously.

This was probably the most aggravating change in Delphi I can
remember, in terms of code breakage.

The only time I ever resorted to class helpers was to fix broken code
that wasn't mine. Almost always in the VCL.

The most useful aspect of class helpers is dead in Berlin.

I had been putting off upgrading to Berlin because I knew this would
create a lot of work -- finding new ways to fix broken VCL behavior
now that I have no clean way to crack the classes.

Whatever is "bad" about using a class helper to crack a class, it is
nowhere near as bad as the only viable alternative left: making a
local copy of the affected source files.

Unless I am missing a viable alternative? Any suggestions to fixing
broken VCL code, such as its inability to properly adjust font size in
a popup menu on a monitor that isn't equal to the system dpi? I
reported this over a year ago, fixed it myself with a class helper,
and it hasn't been fixed and the workaround is now dead in the
water...

And on a related note: I think all of the Delphi IDE devs should be
required to do all of their dev work on a mixed-DPI system. They keep
changing and breaking and not fully implementing cross-DPI support and
it is obvious they don't have to use what they code. I came to terms
with the broken state of multi-DPI in the VCL with Seattle and fixed
everything with custom base classes and class helpers. It all worked.
Berlin broke my fixes, which would be perfectly fine with me if they
had fixed the root problems that necessitated them in the first place.
No such luck.

:-(

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Alexandre Machado

Posts: 1,433
Registered: 8/10/13
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 12, 2017 8:05 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Maybe this can help you:

Credits to Uwe Schuster (https://twitter.com/UScLE/status/741012652202332161)

program ClassHelper;
 
{$APPTYPE CONSOLE}
 
type
  TFoo = class(TObject)
  private
    procedure PrivateProc(AValue: Integer);
  public 
    V: Integer;
  end;
  
{ TFoo }
 
procedure TFoo.PrivateProc(AValue: Integer);
begin
  WriteLn(V * AValue);
end;
 
type
  TFooHelper = class helper for TFoo
    procedure CallPrivateProc(AValue: Integer);
  end;
  
procedure TFooHelper.CallPrivateProc(AValue: Integer);
var
  P: procedure(AValue: Integer) of object;
begin
  TMethod(P).Code := @TFoo.PrivateProc;
  TMethod(P).Data := Self;
  P(Value);
end;
 
var
  F: TFoo;
begin
  F := TFoo.Create;
  try
    F.V := 21;
    F.CallPrivateProc(2);
  finally
    F.Free;
  end;
  ReadLn;
end.
 
Arthur Hoornweg

Posts: 330
Registered: 6/2/98
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 3:57 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:
Maybe this can help you:

I'm surprised that this works, because apparently the class helper can still "see* the address of method tFoo.Privateproc even though it was declared private. But how about fields?

Olivier Sannier

Posts: 392
Registered: 8/26/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 4:30 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur Hoornweg wrote:
Alexandre Machado wrote:
Maybe this can help you:

I'm surprised that this works, because apparently the class helper can still "see* the address of method tFoo.Privateproc even though it was declared private. But how about fields?


Fields don't work, you have to use class masking:

https://github.com/project-jedi/jvcl/blob/master/jvcl/run/JvToolEdit.pas#L1170
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 6:16 AM   in response to: Olivier Sannier in response to: Olivier Sannier
"Olivier Sannier" wrote on Fri, 13 Jan 2017 04:30:19 -0800:

Arthur Hoornweg wrote:
Alexandre Machado wrote:
Maybe this can help you:

I'm surprised that this works, because apparently the class helper can still "see* the address of method tFoo.Privateproc even though it was declared private. But how about fields?


Fields don't work, you have to use class masking:

https://github.com/project-jedi/jvcl/blob/master/jvcl/run/JvToolEdit.pas#L1170

Class Helpers provided a reliable way to crack fields and methods. I
need both... Class masking looks like an alternative slightly better
than making a local copy of the rtl source. Looks very brittle ...
sigh. But thanks, I may end up having to use it.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Olivier Sannier

Posts: 392
Registered: 8/26/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 6:28 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
"Olivier Sannier" wrote on Fri, 13 Jan 2017 04:30:19 -0800:

Arthur Hoornweg wrote:
Alexandre Machado wrote:
Maybe this can help you:

I'm surprised that this works, because apparently the class helper can still "see* the address of method tFoo.Privateproc even though it was declared private. But how about fields?


Fields don't work, you have to use class masking:

https://github.com/project-jedi/jvcl/blob/master/jvcl/run/JvToolEdit.pas#L1170

Class Helpers provided a reliable way to crack fields and methods. I
need both... Class masking looks like an alternative slightly better
than making a local copy of the rtl source. Looks very brittle ...
sigh. But thanks, I may end up having to use it.

It is indeed quite brittle, and I liked class helpers a lot for their
robustness in that regard.
But that's also why there is a $MESSAGE directive here to remind me to
check everytime a new version of Delphi comes out.
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 6:43 AM   in response to: Olivier Sannier in response to: Olivier Sannier
"Olivier Sannier" wrote on Fri, 13 Jan 2017 06:28:57 -0800:

But that's also why there is a $MESSAGE directive here to remind me to
check everytime a new version of Delphi comes out.

I do the same for all of my VCL/RTL fixes. Some of them even emit
errors because I want to make sure I force myself to check to see if
my corrections are still required.

I know it is too late to have anything done about this, but I still
can hardly believe the chutzpah of Embarcadero making this breaking
change. They say they are fixing a "bug" but it is a feature when it
is used for a decade by coders to solve problems. And until Emba uses
strict private on all of their class private fields to prevent
friend classes from using private fields, their claims about "OOP
purity" are totally bogus. Marco's complaint that people could
unknowingly access private fields is valid, but easily solved with a
compiler warning.... I could go on, but apparently I have to spend my
time finding new ways to fix broken VCL and RTL code if I am to stay
current with Delphi releases.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dan Barclay

Posts: 701
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 1:49 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
"Olivier Sannier" wrote on Fri, 13 Jan 2017 06:28:57 -0800:

But that's also why there is a $MESSAGE directive here to remind me to
check everytime a new version of Delphi comes out.

I do the same for all of my VCL/RTL fixes. Some of them even emit
errors because I want to make sure I force myself to check to see if
my corrections are still required.

I know it is too late to have anything done about this, but I still
can hardly believe the chutzpah of Embarcadero making this breaking
change. They say they are fixing a "bug" but it is a feature when it
is used for a decade by coders to solve problems. And until Emba uses
strict private on all of their class private fields to prevent
friend classes from using private fields, their claims about "OOP
purity" are totally bogus. Marco's complaint that people could
unknowingly access private fields is valid, but easily solved with a
compiler warning.... I could go on, but apparently I have to spend my
time finding new ways to fix broken VCL and RTL code if I am to stay
current with Delphi releases.

They don't understand application development. Seriously, they understand tool/library coding. It's not just Embarcadero. Tools developers sometimes lean so heavily on theory experts and subject matter experts they miss the real targets. Idealists generally screw things up in search of perfection that they fail to achieve anyway. Idealism is not a bad thing per se, it just needs to be mixed with pragmatism.

Application development is full of compromise. Idealists and language zealots would not do well at delivering solutions where there is a need to span technologies and customer needs.

Dan
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 2:58 PM   in response to: Dan Barclay in response to: Dan Barclay
"Dan Barclay" wrote on Fri, 13 Jan 2017 13:49:16 -0800:

They don't understand application development. Seriously, they understand tool/library coding. It's not just Embarcadero. Tools developers sometimes lean so heavily on theory experts and subject matter experts they miss the real targets. Idealists generally screw things up in search of perfection that they fail to achieve anyway. Idealism is not a bad thing per se, it just needs to be mixed with pragmatism.

Application development is full of compromise. Idealists and language zealots would not do well at delivering solutions where there is a need to span technologies and customer needs.

Exactly!

Not only do they not understand application development, they do not
even test their own solutions. We are told that we shouldn't break
OOP so the ability was removed (and in the same thread Marco balks at
the thought of enforcing private in same-source classes), but oh you
can still do it with RTTI (um, contradiction much?). But you CAN'T
always use RTTI. You just can't can't can't -- some cases where class
helpers were used to crack a class can not be duplicated with
super-slow RTTI at all. Why say it does the same thing? Because you
don't design applications for a living, only dev tools.

Now that people are using TMethod to get at the address of private
methods as an alternative to class helpers, next they will remove
TMethod and say it is purely a compiler feature and is bad OOP to use.
They did it with 8-bit strings only to expose it again later after
they realized you can't target Linux without direct support for 8-bit
strings. Or they might look for the Detours library and refuse to
build in the code because it's too impure. whatever!

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Remy Lebeau (Te...


Posts: 7,732
Registered: 12/23/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 3:19 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon wrote:

Now that people are using TMethod to get at the address of private
methods as an alternative to class helpers, next they will remove
TMethod and say it is purely a compiler feature and is bad OOP to use.

They won't, and can't, remove TMethod. It is too fundamental to how closures
are callable without using thunks. But they could certainly remove the ability
of a class helper obtaining the memory address of a private method, at least.

They did it with 8-bit strings only to expose it again later after
they realized you can't target Linux without direct support for
8-bit strings.

That is not why 8bit strings were re-introduced. And besides, they still
had access to 8bit strings internally, they just disabled it (not removed
it) for end users.

--
Remy Lebeau (TeamB)
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 13, 2017 4:59 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
"Remy Lebeau" wrote on Fri, 13 Jan 2017 15:19:02 -0800:

Brandon wrote:

Now that people are using TMethod to get at the address of private
methods as an alternative to class helpers, next they will remove
TMethod and say it is purely a compiler feature and is bad OOP to use.

They won't, and can't, remove TMethod. It is too fundamental to how closures
are callable without using thunks. But they could certainly remove the ability
of a class helper obtaining the memory address of a private method, at least.

Sure. Same outcome. Removing capabilities developers rely on to fix
bugs in code they can't control, like the VCL.

They did it with 8-bit strings only to expose it again later after
they realized you can't target Linux without direct support for
8-bit strings.

That is not why 8bit strings were re-introduced. And besides, they still
had access to 8bit strings internally, they just disabled it (not removed
it) for end users.

My point was, internally, 8bit strings were still there, just removed
from use by us developers so we wouldn't be so stupid as to use
something so bad as an 8-bit string (or so that new Delphi users
wouldn't be confused by the existence of a type, or something
somesuch). They could take the same approach to playing with TMethod
to work around the neutering of class helpers. It grows tiresome that
Embarcadero continually makes decisions like this because they think
they know so much better than developers who are already using
features for a decade. The reality is that the VCL is a large,
complex library and contains imperfections. I don't expect it to be
perfect; I don't even expect them to fix all of the bugs. But I also
don't expect them to make it harder for me to make my own corrections
to their bugs, which is the only outcome of the change to class
helpers. In the end it seems that I am expected to curate my own
copies of the VCL source, something that I am loath to do. Marco even
suggested this as an alternative to using class helpers to fix bugs in
the VCL. That is probably the absolute last resort/worst possible way
to deal with it. Nobody wants to have to merge their source code
fixes into new VCL units every time they upgrade Delphi. It is much
easier to manage a few class helper methods and it is just lame that
they are working against such a useful thing.

But moaning about it won't change anything. Time to write my hacks to
fix bugs in the Berlin VCL source and move on, LOL!

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 12:03 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

Sure. Same outcome. Removing capabilities developers rely on to fix
bugs in code they can't control, like the VCL.

Developers should not have relied on what amounted to being a bug. That
was their problem. Now the bug is fixed and they start moaning.
<shaking head>

They did it with 8-bit strings only to expose it again later after
they realized you can't target Linux without direct support for
8-bit strings.

That is not why 8bit strings were re-introduced. And besides, they
still had access to 8bit strings internally, they just disabled it
(not removed it) for end users.

My point was, internally, 8bit strings were still there, just removed
from use by us developers

Probably because the original plan was never to have them in the mobile
compilers. ISTM the plan was to remove them from the internal code too,
but they just didn't get around to it yet.

--
Rudy Velthuis http://www.rvelthuis.de

"Always do right- this will gratify some and astonish the rest."
-- Mark Twain (1835-1910)
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 2:56 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:
Brandon Staggs wrote:

Sure. Same outcome. Removing capabilities developers rely on to fix
bugs in code they can't control, like the VCL.

Developers should not have relied on what amounted to being a bug. That
was their problem. Now the bug is fixed and they start moaning.
<shaking head>

And how are we supposed to know that was a bug? It may as well had
been intentional feature.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Dave Nottage

Posts: 1,180
Registered: 1/7/00
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 3:11 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had some inkling that it was not intentional.

--
Dave Nottage [MVP, TeamB]
Hints, tips and tricks at: http://www.delphiworlds.com/blog
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 3:51 AM   in response to: Dave Nottage in response to: Dave Nottage
Dave Nottage wrote:
Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had some inkling that it was not intentional.

Since class helpers are horizontal extension of a class ability to
access private section does not seem so unreasonable. You
access the class from the ground level so to speak.

With Java you can hack in all the way in with reflection, since Delphi
is more low level language than Java more direct (and more robust)
way of hacking is not unexpected. Also Delphi RTTI is optional
rather than mandatory feature.

It never ever crossed my mind that private access was unintentional
and even more I never thought that it might get "fixed" regardless of
many developers being against that fix.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Dave Nottage

Posts: 1,180
Registered: 1/7/00
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 4:31 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Since class helpers are horizontal extension of a class ability to
access private section does not seem so unreasonable

Who defined them as a "horizontal extension"? The help states:

"Class and record helpers provide a way to extend a type.."

Which sounds way more like inheritance. At the very least, developers could have enquired as to their intention instead
of making assumptions, when they discovered they could use them to access private members.

--
Dave Nottage [MVP, TeamB]
Hints, tips and tricks at: http://www.delphiworlds.com/blog
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 6:09 AM   in response to: Dave Nottage in response to: Dave Nottage
Dave Nottage wrote:
Dalija Prasnikar wrote:

Since class helpers are horizontal extension of a class ability to
access private section does not seem so unreasonable

Who defined them as a "horizontal extension"? The help states:

"Class and record helpers provide a way to extend a type.."

Which sounds way more like inheritance. At the very least, developers could have enquired as to their intention instead
of making assumptions, when they discovered they could use them to access private members.

How you use them is defining feature. With vertical extension - inheritance
you have to create new class that inherits existing one and moreover you
have to instantiate instance of that new class to use extended features.

With horizontal extension you operate on existing class instances directly.

Of course, there is nowhere written that horizontal extension must have
access to private section, and there are languages that provide extensions
without that access. But just the same there is nowhere written that it
is forbidden to have such access.

Like I already said some other OOP languages have full private access through
reflection. So all that OOP private protection strictness argument is rather moot.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 10:03 AM   in response to: Dave Nottage in response to: Dave Nottage
"Dave Nottage" wrote on Mon, 16 Jan 2017 04:31:05 -0800:

Which sounds way more like inheritance. At the very least, developers could have enquired as to their intention

Seriously? When I find a feature that solves an immediate problem for
me, I should ask Emba document writers if it is okay for me to do it!?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dave Nottage

Posts: 1,180
Registered: 1/7/00
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 12:19 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

Seriously? When I find a feature that solves an immediate problem for
me, I should ask Emba document writers if it is okay for me to do it!?

That would depend on what the "feature" actually allows. If, in a language there's a basic premise that is consistent
throughout, then something else appears that does not fit in with that premise, it should ring alarm bells for a
developer. I guess I must be crazy for thinking like that ;-)

--
Dave Nottage [MVP, TeamB]
Hints, tips and tricks at: http://www.delphiworlds.com/blog
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 1:27 PM   in response to: Dave Nottage in response to: Dave Nottage
Am 16.01.2017 um 21:19 schrieb Dave Nottage (TeamB):
Brandon Staggs wrote:

Seriously? When I find a feature that solves an immediate problem for
me, I should ask Emba document writers if it is okay for me to do it!?

That would depend on what the "feature" actually allows. If, in a language there's a basic premise that is consistent
throughout, then something else appears that does not fit in with that premise, it should ring alarm bells for a
developer. I guess I must be crazy for thinking like that ;-)

Hm? Such as private not really being private if the other class wanting
to access private fields resides in the same unit?

Ok, we've got strict private nowadays, but the IDE still doesn't 100%
get the concept of strict private and protected afaik. It doesn't get
that this is one keyword written in 2 words. So it sometimes
automatically places stuff between or unecessarily creates a new private
section if there would be a strict private one already.

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 5:53 PM   in response to: Dave Nottage in response to: Dave Nottage
"Dave Nottage" wrote on Mon, 16 Jan 2017 12:19:07 -0800:

That would depend on what the "feature" actually allows. If, in a language there's a basic premise that is consistent
throughout, then something else appears that does not fit in with that premise, it should ring alarm bells for a
developer.

Class helpers only exist so that you do not have to adhere to strict
OOP principles. Otherwise you would be told to inherit from the class
you want to extend. And when the IDE gives you a list of methods as
you type, and the compiler says "no problem" when you select one of
them, it is not unreasonable to treat it as a feature-- especially
when it becomes very well-known and used for a decade.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 2:18 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Dave Nottage wrote:
Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had some
inkling that it was not intentional.

Since class helpers are horizontal extension of a class ability

I would not call it horizontal. It would at best call it oblique, since
class helpers come after the fact. Having class helpers or any other
mechanism violate privacy is simply wrong.

It is clear that it was a bug: it allowed you AND EVERYONE ELSE to
access things you should not be able to access. It is like a wide open
backdoor. If you see that, you also know it is very likely not
intentional, and you probably don't go inside and look in the drawers.

--
Rudy Velthuis http://www.rvelthuis.de

"Wagner's music is better than it sounds."
-- Mark Twain (1835-1910)
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 7:36 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 30.01.2017 um 11:18 schrieb Rudy Velthuis (TeamB):
Dalija Prasnikar wrote:

Dave Nottage wrote:
Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had some
inkling that it was not intentional.

Since class helpers are horizontal extension of a class ability

I would not call it horizontal. It would at best call it oblique, since
class helpers come after the fact. Having class helpers or any other
mechanism violate privacy is simply wrong.

It is clear that it was a bug: it allowed you AND EVERYONE ELSE to
access things you should not be able to access. It is like a wide open
backdoor. If you see that, you also know it is very likely not
intentional, and you probably don't go inside and look in the drawers.

Hello,

every technique allowing to get at private stuff would be wrong then.
So fixing issues which require access to private fields would be
impossible for customers (except copying the source file and making the
fix in source, but that's not an elegant/good solution either).

Am I correct with my assesment of the situation?

The best would be more timely fixes from EMBT, but that I'd consider
being a daydream at least for the forseeable future. I don't claim they
do nothing, but given the vast amount of bugs pressent I'm realistic
about what they can and will do or not.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 5, 2017 6:25 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

every technique allowing to get at private stuff would be wrong then.

It should not be normal programming practice. It should be an
exceptional measure for exceptional circumstances.

An analogy:

I could open most doors with an axe or some other tools, even if they
are locked. But is is not considered good practice and it is not
considered good practice to overcome the fact that I locked it. There
are cases when it is necessary (e.g. fire), but it should not be normal
practice, and it should certainly not be easy to open someone else's
locked door. People who enter a house without permission are usually
called burglars.

The private members of a class are locked away from the public.
Accessing them is like breaking the door with an axe. Some people used
class helpers to get at anything they thought they needed access to.
That is analogous to burglary.

But some people here have been using class helpers as a convenient
matter to "open any door" they wanted to. In other words, they were
using them as part of their normal programming practice.

Note that you can still access private members or functions, but it is
not easy anymore, and it has become too tedious to use it as part of
normal programming practice. That is a good thing.

Too bad if some have gotten in trouble. That probably means they did
use it as some part of their normal programming practice, so I have not
too much pity with them.

Hacks shoould not be easy. They should be recognized as exceptions to
the normal and as something you should not do, but you have no other
choice.
--
Rudy Velthuis http://www.rvelthuis.de

"Some editors are failed writers, but so are most writers."
-- T. S. Eliot (1888-1965)
jesu ortega

Posts: 64
Registered: 9/28/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 6, 2017 12:55 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Here the right analogy would be that your neighbour has left the tap open and it's flooding your home. He won't return home for months or years but he wants you to wait and wait and not enter his home because it's private property.
David Keith

Posts: 173
Registered: 12/10/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 6, 2017 8:07 AM   in response to: jesu ortega in response to: jesu ortega
On 2/6/2017 03:55, jesu ortega wrote:
Here the right analogy would be that your neighbour has left the tap open and it's flooding your home. He won't return home for months or years but he wants you to wait and wait and not enter his home because it's private property.

EXCELLENT! +10
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:57 AM   in response to: jesu ortega in response to: jesu ortega
jesu ortega wrote:

Here the right analogy would be that your neighbour has left the tap
open and it's flooding your home. He won't return home for months or
years but he wants you to wait and wait and not enter his home
because it's private property.

That's nonsense. The analogy is that you can enter my home whenever you
feel you need something of mine that I locked away (for whatever
reason), even if I locked the door. And that is not right.

--
Rudy Velthuis http://www.rvelthuis.de

Harp's Corollary To Estridge's Law: Your "IBM PC-compatible"
computer grows more incompatible with every passing moment.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 3:11 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 05.03.2017 um 09:57 schrieb Rudy Velthuis (TeamB):
jesu ortega wrote:

Here the right analogy would be that your neighbour has left the tap
open and it's flooding your home. He won't return home for months or
years but he wants you to wait and wait and not enter his home
because it's private property.

That's nonsense. The analogy is that you can enter my home whenever you
feel you need something of mine that I locked away (for whatever
reason), even if I locked the door. And that is not right.

Your analogy is not perfect either. In case of your home: he doesn't own
it and he has no usage rights on it either.

In case of Delphi included libraries he has the source code and the
right to use it and maybe even the right to modify it (but then he
looses right to complain about bugs he's introducing because of
modifying it).

Greetings

Markus
jesu ortega

Posts: 64
Registered: 9/28/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 12:16 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
I'm not against private property. I'm against people who don't close the tap when they are warned about it, even knowing that it's hurting others and also hurting themselves in the long run.

Yes, every programmer leaves some taps open every day. The problem with Embarcadero is that they leave them open for tooo long.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:12 PM   in response to: jesu ortega in response to: jesu ortega
jesu ortega wrote:

I'm not against private property. I'm against people who don't close
the tap when they are warned about it

Well, see it this way: Embarcadero closed their tap, and now you can
hear the howling from those who can't get their water for free anymore.
<g>

--
Rudy Velthuis http://www.rvelthuis.de

"A committee is a group of people who individually can do nothing
but together can decide that nothing can be done." -- Fred Allen.

jesu ortega

Posts: 64
Registered: 9/28/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 6:01 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
tap <> class helper
tap = bug

I guess that when your patients need new teeth, you put a Samsung Note battery inside them, so they don't dare to touch them and break your work.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:40 AM   in response to: jesu ortega in response to: jesu ortega
jesu ortega wrote:

tap <> class helper
tap = bug

The class helpers allowing to access private members of a class were
the bug. That bug was fixed. Don't you want bugs to be fixed?

I guess that when your patients need new teeth, you put a Samsung
Note battery inside them, so they don't dare to touch them and break
your work.

I don't follow, sorry. That doesn't make any sense.
--
Rudy Velthuis http://www.rvelthuis.de

"It is now possible for a flight attendant to get a pilot
pregnant." -- Richard J. Ferris, president of United Airlines
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 10:41 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:
Dalija Prasnikar wrote:

Dave Nottage wrote:
Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had some
inkling that it was not intentional.

Since class helpers are horizontal extension of a class ability

I would not call it horizontal. It would at best call it oblique, since
class helpers come after the fact. Having class helpers or any other
mechanism violate privacy is simply wrong.

It is clear that it was a bug: it allowed you AND EVERYONE ELSE to
access things you should not be able to access. It is like a wide open
backdoor. If you see that, you also know it is very likely not
intentional, and you probably don't go inside and look in the drawers.

Silly me. I am using too much Java lately. You know that language where
every darn thing is an object. So it is OOP, all right. And it has that thingy
called reflection, and you can access anything you want with it no matter
how private it is.

And without it, I would not be able to do a thing on Android. Because Google
API's are more messed up than Delphi's. And bugs galore, too. So
you have to fix things by breaking in order to get things done.

And BTW, every serialization library I know in Java is working on PRIVATE
fields directly.... Zero encapsulation.

OOP principles have their purpose - they don't exist in void, they exist because
following them can help you write better, more maintainable code. At certain
point each one of those can interfere with each other as well as final goal -
developing applications fast and reliably. When that happens they no longer serve
any purpose.

If you want to make religion out of OOP, knock your self out. I have better
things to do.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 5, 2017 6:09 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Rudy Velthuis (TeamB) wrote:
Dalija Prasnikar wrote:

Dave Nottage wrote:
Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had
some inkling that it was not intentional.

Since class helpers are horizontal extension of a class ability

I would not call it horizontal. It would at best call it oblique,
since class helpers come after the fact. Having class helpers or
any other mechanism violate privacy is simply wrong.

It is clear that it was a bug: it allowed you AND EVERYONE ELSE to
access things you should not be able to access. It is like a wide
open backdoor. If you see that, you also know it is very likely not
intentional, and you probably don't go inside and look in the
drawers.

Silly me. I am using too much Java lately. You know that language
where every darn thing is an object. So it is OOP, all right. And it
has that thingy called reflection, and you can access anything you
want with it no matter how private it is.

Yes, and Delphi has that too. But reflection is meant to be used by
debuggers and similar tools. I know it is used for other purposes too,
because people in other languages also think "pragmatic".

The fact that you can open my front door with an axe doesn't mean you
should or that it should be noral practice. Reflection is such a kind
of axe.

Using reflection to undermine privacy in normal programming is wrong.
Privacy does not exist for nothing.

--
Rudy Velthuis http://www.rvelthuis.de

"The instinct of nearly all societies is to lock up anybody who
is truly free. First, society begins by trying to beat you up.
If this fails, they try to poison you. If this fails too, the
finish by loading honors on your head."
-- Jean Cocteau (1889-1963)
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 24, 2017 6:32 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:
Using reflection to undermine privacy in normal programming is wrong.
Privacy does not exist for nothing.

It shouldn't exist in the first place. There's no rational reason - other than hiding buggy code - to ever make anything private. If something's not part of the official API, that's what documentation is for. Heck, in Python, where everything is an object, language-enforced privacy doesn't even exist. If something is meant to be private, you precede its name by an underscore. It's solely by convention/documentation. That's the way it should be. I saw one Python programmer indignantly ask on Stack Overflow when someone wanted to know how to make things private, "Who are you to know, for all time, what anyone will ever need to do with this code?" They're completely correct. You don't know what someone will ever need to do and you can't presume to. Once you let someone use your code, it's not yours anymore, it's theirs.That code is about meeting their needs. And if they break anything, it's "buyer beware".

Nick Gibson put it this way:

Is this such a bad thing? Why is it that we want to lock people out of our classes? I've never really thought about it before now: if a field wasn't used outside the class in my reference code, then it was dutifully protected from the outside world. The problem
with this kind of programming is that it leads you into thinking of the people using your code as malicious.

There's a lot to be said for defensive programming, but after a certain point it's reducing the power of our code. I could see the argument towards field safety if you were distributing a library and you wanted to reduce the possible bugs others could write
using your code, but for the majority of cases it appears that it's motivated out of a fear that users will tamper with the programmer's perfect code, in nothing less than a malicious attempt to destroy its purity.

Do we resent others using our work outside our intentions? Some really useful things have been accomplished by using code in ways it's authors had never intended (and probably never wanted, for that matter).

Next time you reach for the 'private' keyword, have a good think about whether it's necessary, or whether you're reducing the potential of your code.

Free your code, Rudy! Do a grep search on all of your code and remove any "private" keywords! Embrace freedom! :-)
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:32 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:
Using reflection to undermine privacy in normal programming is
wrong. Privacy does not exist for nothing.

It shouldn't exist in the first place. There's no rational reason -
other than hiding buggy code - to ever make anything private.

That's pure bullshit. The reason to make things private is to protect
the integrity of the object, i.e. to ensure that no one can
(inadvertently, or on purpose) meddle with the internals of the class
or object and leave it in an invalid state.

Sheesh, do I really have to explain this basic principle to
professional programmers?

--
Rudy Velthuis http://www.rvelthuis.de

"Computer system analysis is like child-rearing; you can do
grievous damage, but you cannot ensure success."
-- Tom DeMarco

Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 2:58 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 05.03.2017 um 09:32 schrieb Rudy Velthuis (TeamB):
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:
Using reflection to undermine privacy in normal programming is
wrong. Privacy does not exist for nothing.

It shouldn't exist in the first place. There's no rational reason -
other than hiding buggy code - to ever make anything private.

That's pure bullshit. The reason to make things private is to protect
the integrity of the object, i.e. to ensure that no one can
(inadvertently, or on purpose) meddle with the internals of the class
or object and leave it in an invalid state.

Sheesh, do I really have to explain this basic principle to
professional programmers?


He thinks that every resonable programmer should be intelligent enough
to be able to meddle with these "basics" or "inner workings" of a class
without ruining them and so he'd have the complete flexibility.

Issue is: most developers are not clever or experienced enough to not
break something. Most would not know who's really inheriting from that
class and thus relies on the exact working of these private inner
things. Yes, inheriting classes cannot call private stuff directly, but
the inherited protected stuff is quite likely to use some of the private
stuff.

Greetings

Markus
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:12 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

He thinks that every resonable programmer should be intelligent enough
to be able to meddle with these "basics" or "inner workings" of a class
without ruining them and so he'd have the complete flexibility.

I believe it was Martin Fowler who identified two types of programmers: directing and enabling. Here we go:

Many debates in software development are underpinned by whether the speaker has a Directing Attitude or an Enabling Attitude. These different attitudes affect choices over languages, designs, tools, processes, and lots more.

Here's some examples of this dichotomy:

A debate a while ago triggered by Joel Spolsky's post on exceptions. He didn't like exceptions because they could be misused badly, leading to confusing code (directing). Bill Caputo pointed out that exceptions, when used well, make life much easier
(enabling).
Some of the static/dynamic typing debate brings up these points. Some arguments in favor of static typing talk about how they prevent people from making certain kinds of mistake (directing) while dynamic typers point out how static typing restricts
some useful idioms (enabling).
Agile processes are PeopleOriented (enabling), while plan-driven methods seek to ensure that even a poor team can do an acceptable job (directing).

These aren't hard-wired attitudes. Often people are directing in some cases and enabling in others. But I think there is a deep strain running through here, often a personality issue, that runs underneath much discussion on how we do software. (I'm very
much in the enabling category, as if you can't tell.)

Issue is: most developers are not clever or experienced enough to not
break something.

That's neither your judgment to make nor your responsibility, especially today in the era of open source code when you have no idea who may end up using your code.

Most would not know who's really inheriting from that
class

Doesn't documentation provide that information?
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:17 PM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Markus Humm wrote:

He thinks that every resonable programmer should be intelligent
enough to be able to meddle with these "basics" or "inner workings"
of a class without ruining them and so he'd have the complete
flexibility.

I believe it was Martin Fowler who identified two types of
programmers: directing and enabling.

Totally irelevant, IMO. I don't want people to ruin the innards of my
classes. Why do you think ICs are cast in plastic? So people can't
meddle with the innards.

--
Rudy Velthuis http://www.rvelthuis.de

"Ketchup left overnight on dinner plates has a longer half-life
than radioactive waste." -- Wes Smith.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 9:42 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 08.03.2017 um 00:17 schrieb Rudy Velthuis (TeamB):
Joseph Mitzen wrote:

Markus Humm wrote:

He thinks that every resonable programmer should be intelligent
enough to be able to meddle with these "basics" or "inner workings"
of a class without ruining them and so he'd have the complete
flexibility.

I believe it was Martin Fowler who identified two types of
programmers: directing and enabling.

Totally irelevant, IMO. I don't want people to ruin the innards of my
classes. Why do you think ICs are cast in plastic? So people can't
meddle with the innards.

Your comparison is not the best one. It's mostly not needed to shield
the ICs from people trying to mess around with them as due to the small
structures and multiple layer nobordy can resonably do something useful
anyway. The purpose of the housing is to shield the inner workings of
the environment, e.g. UV light, dust and water. Humans are only a
secondary concern, as most ICs are in devices with outer housings
anyway. ;-)

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:41 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 08.03.2017 um 00:17 schrieb Rudy Velthuis (TeamB):
Joseph Mitzen wrote:

Markus Humm wrote:

He thinks that every resonable programmer should be intelligent
enough to be able to meddle with these "basics" or "inner
workings" >>> of a class without ruining them and so he'd have the
complete >>> flexibility.

I believe it was Martin Fowler who identified two types of
programmers: directing and enabling.

Totally irelevant, IMO. I don't want people to ruin the innards of
my classes. Why do you think ICs are cast in plastic? So people
can't meddle with the innards.

Your comparison is not the best one.

In the beginning of OO, classes were often compared to "software ICs".

--
Rudy Velthuis http://www.rvelthuis.de

"I'm living so far beyond my income that we may almost be said
to be living apart." -- e e cummings (1894-1962)
Mike Margerum

Posts: 520
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 5:14 AM   in response to: Markus Humm in response to: Markus Humm

He thinks that every resonable programmer should be intelligent enough
to be able to meddle with these "basics" or "inner workings" of a class
without ruining them and so he'd have the complete flexibility.

Shouldn't they? everything should be protected by default, not private.

Issue is: most developers are not clever or experienced enough to not
break something. Most would not know who's really inheriting from that
class and thus relies on the exact working of these private inner
things. Yes, inheriting classes cannot call private stuff directly, but
the inherited protected stuff is quite likely to use some of the private
stuff.

so private is protecting me from programmers who aren't clever enough?
Gee thanks.

Most developers have probably never even looked at the RTL source code.
Anyone who has is probably smart enough to make changes to it.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:19 PM   in response to: Mike Margerum in response to: Mike Margerum
Mike Margerum wrote:


He thinks that every resonable programmer should be intelligent
enough to be able to meddle with these "basics" or "inner workings"
of a class without ruining them and so he'd have the complete
flexibility.

Shouldn't they? everything should be protected by default, not
private.


That's bullshit. Pure and utter bull. There are certainly things that
should be private, and protected should certainly not be the default.

--
Rudy Velthuis http://www.rvelthuis.de

"To sin by silence when they should protest makes cowards of
men."
-- Abraham Lincoln
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:44 AM   in response to: Mike Margerum in response to: Mike Margerum
Mike Margerum wrote:


He thinks that every resonable programmer should be intelligent
enough to be able to meddle with these "basics" or "inner workings"
of a class without ruining them and so he'd have the complete
flexibility.

Shouldn't they?


It were nice if that were really the case. Often enough, it isn't.
--
Rudy Velthuis http://www.rvelthuis.de

"Beyond its entertainment value, Baywatch has enriched and,
in many cases, helped save lives. I'm looking forward to
the opportunity to continue with a project which has has
such a significance for so many."
-- David Hasselhoff, Actor
Quentin Correll


Posts: 2,118
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 11:13 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy,

| It were nice...

It would be nice...

--

Q -- XanaNews 1.19.1.372 - 2017-03-11 11:11:34

Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 6:55 PM   in response to: Quentin Correll in response to: Quentin Correll
Quentin Correll wrote:

Rudy,

It were nice...

It would be nice...

Yeah, sorry. German uses "es wäre".

--
Rudy Velthuis http://www.rvelthuis.de

"I am tired of fighting, our chiefs are killed...it is cold and
we have no blankets. The little children are freezing to
death...hear me, my chiefs, I am tired: my heart is sick and
sad. From where the sun now stands...I will fight no more
forever..."
-- Chief Joseph, before his tribe was slaughtered
John Treder

Posts: 290
Registered: 8/2/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 8:27 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Quentin Correll wrote:

Rudy,

It were nice...

It would be nice...

Yeah, sorry. German uses "es wäre".

Hey, you were just using the subjunctive, and Q, old geezer that he is, has forgotten it. Your usage is technically correct, though it has fallen out of use in the barbarian land of Californiia. :-)

--
Tred

Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 10:44 PM   in response to: John Treder in response to: John Treder
Am 12.03.2017 um 05:27 schrieb John Treder:
Rudy Velthuis (TeamB) wrote:

Quentin Correll wrote:

Rudy,

It were nice...

It would be nice...

Yeah, sorry. German uses "es wäre".

Hey, you were just using the subjunctive, and Q, old geezer that he is, has forgotten it. Your usage is technically correct, though it has fallen out of use in the barbarian land of Californiia. :-)


Which language issues are we discussing now? Delphi's or the English
ones? ;-)

Greetings

Markus
John Treder

Posts: 290
Registered: 8/2/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 12, 2017 10:30 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 12.03.2017 um 05:27 schrieb John Treder:
Rudy Velthuis (TeamB) wrote:

Quentin Correll wrote:

Rudy,

It were nice...

It would be nice...

Yeah, sorry. German uses "es wäre".

Hey, you were just using the subjunctive, and Q, old geezer that he is, has forgotten it. Your usage is technically correct, though it has fallen out of use in the barbarian land of Californiia. :-)


Which language issues are we discussing now? Delphi's or the English
ones? ;-)

Greetings

Markus

Yes, of course! ;^)

--
Tred
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 12, 2017 11:43 AM   in response to: John Treder in response to: John Treder
Am 12.03.2017 um 18:30 schrieb John Treder:
Markus Humm wrote:

Am 12.03.2017 um 05:27 schrieb John Treder:
Rudy Velthuis (TeamB) wrote:

Quentin Correll wrote:

Rudy,

It were nice...

It would be nice...

Yeah, sorry. German uses "es wäre".

Hey, you were just using the subjunctive, and Q, old geezer that he is, has forgotten it. Your usage is technically correct, though it has fallen out of use in the barbarian land of Californiia. :-)


Which language issues are we discussing now? Delphi's or the English
ones? ;-)

Greetings

Markus

Yes, of course! ;^)

Not an exact answer to my question ;-)

Greetings

Markus
John Treder

Posts: 290
Registered: 8/2/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 12, 2017 5:07 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Which language issues are we discussing now? Delphi's or the English
ones? ;-)

Greetings

Markus

Yes, of course! ;^)

Not an exact answer to my question ;-)

Greetings

Markus

Well, this IS the Non-Sensical section, isn't it?

--
Tred
Quentin Correll


Posts: 2,118
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 13, 2017 11:59 AM   in response to: John Treder in response to: John Treder
John,

| Well, this IS the Non-Sensical section, isn't it?

<g>

--

Q -- XanaNews 1.19.1.372 - 2017-03-13 11:59:44
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 13, 2017 3:19 PM   in response to: Quentin Correll in response to: Quentin Correll
Am 13.03.2017 um 19:59 schrieb Quentin Correll:
John,

| Well, this IS the Non-Sensical section, isn't it?

<g>

;-)
Quentin Correll


Posts: 2,118
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 12, 2017 11:50 AM   in response to: John Treder in response to: John Treder
John,

| Hey, you were just using the subjunctive, and Q, old geezer that he
| is, has forgotten it. Your usage is technically correct, though it
| has fallen out of use in the barbarian land of Californiia. :-)

<chuckle>

--

Q -- XanaNews 1.19.1.372 - 2017-03-12 11:50:49
Quentin Correll


Posts: 2,118
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 12, 2017 11:49 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy,

| | It would be nice...
|
| Yeah, sorry. German uses "es wäre".

No problem and NO reason to be "sorry." Your English is actually VERY
good! While I'm just a mono-linguist-English language speaker.

--

Q -- XanaNews 1.19.1.372 - 2017-03-12 11:45:41
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:14 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 05.03.2017 um 09:32 schrieb Rudy Velthuis (TeamB):
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:
Using reflection to undermine privacy in normal programming is
wrong. Privacy does not exist for nothing.

It shouldn't exist in the first place. There's no rational reason -
other than hiding buggy code - to ever make anything private.

That's pure bullshit. The reason to make things private is to
protect the integrity of the object, i.e. to ensure that no one can
(inadvertently, or on purpose) meddle with the internals of the
class or object and leave it in an invalid state.

Sheesh, do I really have to explain this basic principle to
professional programmers?


He thinks that every resonable programmer should be intelligent enough
to be able to meddle with these "basics" or "inner workings" of a
class without ruining them and so he'd have the complete flexibility.

I don't know what he thinks.

I am pretty sure that most "reasonable" programmers should not access
the private members of the classes they consume. So it is a Good
Thing(tm) this loophole was closed.
--
Rudy Velthuis http://www.rvelthuis.de

On the value of binary; the Bible says: "But let your communication
be Yea, yea; nay, nay: for whatsoever is more than these cometh
of evil." -- (Matthew 5:37)
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 9:43 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 08.03.2017 um 00:14 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:


He thinks that every resonable programmer should be intelligent enough
to be able to meddle with these "basics" or "inner workings" of a
class without ruining them and so he'd have the complete flexibility.

I don't know what he thinks.

I am pretty sure that most "reasonable" programmers should not access
the private members of the classes they consume. So it is a Good
Thing(tm) this loophole was closed.

And most resonable vendors should provide timely fixes for the bugs in
their classes so the wish to access these private things is lessend
quite a lot.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:46 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

I am pretty sure that most "reasonable" programmers should not
access the private members of the classes they consume. So it is a
Good Thing(tm) this loophole was closed.

And most resonable vendors should provide timely fixes for the bugs in
their classes

That is assumed, indeed. But often, the "bugs" are just perceived as
such, if a class does not exactly what the consumer of the class
expects from it, or is not fast enough doing so.
--
Rudy Velthuis http://www.rvelthuis.de

"Where are we going, and why am I in this handbasket?"
-- Bumper Sticker
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:44 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 05.03.2017 um 09:32 schrieb Rudy Velthuis (TeamB):
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:
Using reflection to undermine privacy in normal programming is
wrong. Privacy does not exist for nothing.

It shouldn't exist in the first place. There's no rational reason -
other than hiding buggy code - to ever make anything private.

That's pure bullshit. The reason to make things private is to
protect the integrity of the object, i.e. to ensure that no one can
(inadvertently, or on purpose) meddle with the internals of the
class or object and leave it in an invalid state.

Sheesh, do I really have to explain this basic principle to
professional programmers?


He thinks that every resonable programmer should be intelligent enough
to be able to meddle with these "basics" or "inner workings" of a
class without ruining them and so he'd have the complete flexibility.

He may think what he likes, fact is that this is seldom the case.

Issue is: most developers are not clever or experienced enough to not
break something. Most would not know who's really inheriting from
that class and thus relies on the exact working of these private inner
things.

Exactly.

--
Rudy Velthuis http://www.rvelthuis.de

"The full use of your powers along lines of excellence."
-- definition of "happiness" by John F. Kennedy (1917-1963)

Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:05 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

That's pure bullshit. The reason to make things private is to protect
the integrity of the object

"Protect the integrity"?

i.e. to ensure that no one can
(inadvertently, or on purpose) meddle with the internals of the class

There you go right there. It exists to prevent others from doing what they want to do. It's none of your business what someone else decides to do with that class. You document it and then you leave it up to them. You can't know what I may need to do with that class later on, perhaps many years later.

Sheesh, do I really have to explain this basic principle to
professional programmers?

This "basic principle" has been rejected by professional programmers, and even by entire programming languages, so it's clearly not a "basic principle". Perhaps it's a "school of thought", of which there are more than one on the matter.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:21 PM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:

That's pure bullshit. The reason to make things private is to
protect the integrity of the object

"Protect the integrity"?

Yes. That ensures that no invalid inner state can be created from
outside.

--
Rudy Velthuis http://www.rvelthuis.de

"I believe that sex is a beautiful thing between two people.
Between five, it's fantastic." -- Woody Allen

Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 6:20 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Sun, 5 Mar 2017 00:32:49 -0800:

(inadvertently, or on purpose)

I agree that private is useful to prevent the inadvertent use of
methods and fields that are intended for use internal to the object.
It also signals to someone consuming the object that they have no
expectation of public behavior.

But why should a programmer be prevented from accessing these *on
purpose*? That makes no sense. It is useless rigid ideology.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:22 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Sun, 5 Mar 2017 00:32:49 -0800:

(inadvertently, or on purpose)

I agree that private is useful to prevent the inadvertent use of
methods and fields that are intended for use internal to the object.
It also signals to someone consuming the object that they have no
expectation of public behavior.

But why should a programmer be prevented from accessing these *on
purpose*?

Because the designer of the class generally knows more about it than
the consumer. If the designer thinks it is safe to expose something
(usually through a property or access methods), he should do that.

--
Rudy Velthuis http://www.rvelthuis.de

"Humor is just another defense against the universe."
-- Mel Brooks (1926- )
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 5:49 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Tue, 7 Mar 2017 15:22:48 -0800:

Because the designer of the class generally knows more about it than
the consumer.

You qualified your statement with "generally." Some programmers have
to actually deal with non-general cases. Like when component vendors
hard-code pixel values and you need to work with multi-DPI.
"Generally," class designers are just as fallible as class consumers.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:48 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Tue, 7 Mar 2017 15:22:48 -0800:

Because the designer of the class generally knows more about it than
the consumer.

You qualified your statement with "generally."

Indeed. You can't deny that there are bad programmers too, who don't
really know what they are doing. But I would not use their classes, so
that is not my problem.

--
Rudy Velthuis http://www.rvelthuis.de

"A doctor can bury his mistakes but an architect can only advise
his clients to plant vines."
-- Frank Lloyd Wright (1868-1959)
Eivind Bakkestuen


Posts: 409
Registered: 5/8/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 4:23 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Indeed. You can't deny that there are bad programmers too, who don't
really know what they are doing. But I would not use their classes, so
that is not my problem.

I love such general statements. Do you think there's never been bad
programmers working on your favourite IDE/compiler/VCL/RTL/etc?

--
Eivind Bakkestuen [NDD]
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 6:55 PM   in response to: Eivind Bakkestuen in response to: Eivind Bakkestuen
Eivind Bakkestuen wrote:

Indeed. You can't deny that there are bad programmers too, who don't
really know what they are doing. But I would not use their classes,
so that is not my problem.

I love such general statements. Do you think there's never been bad
programmers working on your favourite IDE/compiler/VCL/RTL/etc?

There could have been, indeed. But generally, they are kept under
control.

--
Rudy Velthuis http://www.rvelthuis.de

"In all the disputes, which have excited Christians against
each other, Rome has invariably decided in favor of that
opinion which tended most towards the suppression of the human
intellect and the annihilation of the reasoning powers."
-- Voltaire
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 24, 2017 7:11 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Silly me. I am using too much Java lately. You know that language where
every darn thing is an object. So it is OOP, all right. And it has that thingy
called reflection, and you can access anything you want with it no matter
how private it is.

You should love this:

http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html

If you want to make religion out of OOP, knock your self out. I have better
things to do.

This isn't even about OOP. There's a tendency to confuse encapsulation (a principle of OOP) with information hiding (which is not).

http://wiki.c2.com/?EncapsulationIsNotInformationHiding
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 27, 2017 8:19 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:
Dalija Prasnikar wrote:

Silly me. I am using too much Java lately. You know that language where
every darn thing is an object. So it is OOP, all right. And it has that thingy
called reflection, and you can access anything you want with it no matter
how private it is.

You should love this:

http://steve-yegge.blogspot.com/2010/07/wikileaks-to-leak-5000-open-source-java.html

Hmmmm... actually not so much. BTW, if it is open source then anyone can adjust
the source so I don't see the point.

If you want to make religion out of OOP, knock your self out. I have better
things to do.

This isn't even about OOP. There's a tendency to confuse encapsulation (a principle of OOP) with information hiding (which is not).

http://wiki.c2.com/?EncapsulationIsNotInformationHiding

Confused or not, point is that all good coding practice and principles
evolved from need to structure and design code in way to minimize
accidental mistakes and to make code cleaner and its intent clearer.

Access modifiers are part of that. I used Swift before it got it's access modifier
support when everything was public. Even though I didn't have much code
it was really messy working with it. Yes, you can name things differently but
access modifiers are a bit more fool proof technique.

I like being able to say things are private, protected, public. I like when other
peoples code does the same (as long as I can easily change behavior).

Problem arises when people start interpreting names too literally and suddenly
private starts to be treated like Fort Knox. And it is not. It shouldn't be.

So while access modifiers should prevent accidental mistakes and usage
there is no reason to break them when needed. It is great if some code
works as intended and you don't have to dig deep to make it work, but
when you have to dig, having easy way to accomplish goal counts a lot.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 1:43 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Mon, 30 Jan 2017 02:18:53 -0800:

Having class helpers or any other
mechanism violate privacy is simply wrong

Why?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 5, 2017 6:13 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Mon, 30 Jan 2017 02:18:53 -0800:

Having class helpers or any other
mechanism violate privacy is simply wrong

Why?

Why? Do I really have to explain information hiding to professional
programmers?

OK, once again: because violating privacy is wrong. If a programmer
makes something private, he or she has good reasons for that and they
don't want others to be able to easily overcome that.

--
Rudy Velthuis http://www.rvelthuis.de

"First, solve the problem. Then, write the code." -- John Johnson
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:53 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Why? Do I really have to explain information hiding to professional
programmers?

No, you have to justify it, which is much harder and more controversial.


OK, once again: because violating privacy is wrong.

That's a circular argument.

If a programmer
makes something private, he or she has good reasons for that

Do they? It's never an issue of Cargo Cult programming? I can turn that argument right around: "If a programmer tries to access something private, they have good reasons for that." This argument doesn't tell us anything; it merely asserts the correctness of your position.

and they
don't want others to be able to easily overcome that.

And who are they to throw obstacles in someone else's way? The only thing you're doing is making my original point for me.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:28 PM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:

Why? Do I really have to explain information hiding to professional
programmers?

No, you have to justify it

I have to justify encapsulation? I don't think so. But I'll quote what
wikipedia says:

Encapsulation is an Object Oriented Programming concept that binds
together the data and functions that manipulate the data, and that
keeps both safe from outside interference and misuse. Data
encapsulation led to the important OOP concept of data hiding.

--
Rudy Velthuis http://www.rvelthuis.de

"Under conditions of competition, standards are set by the morally
least reputable agent." -- philosopher/economist John Stuart Mill

Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 10:02 AM   in response to: Dave Nottage in response to: Dave Nottage
"Dave Nottage" wrote on Mon, 16 Jan 2017 03:11:29 -0800:

Dalija Prasnikar wrote:

And how are we supposed to know that was a bug?

Anyone with a solid knowledge of OO should have at least had some inkling that it was not intentional.

This makes no sense. A class helper is a lateral function that
specifically allows you to avoid the consequences of strict OOP.
There is no reason, on the surface, to expect that this behavior was
unintentional. They were intentionally giving us a way to avoid
inheritance.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 2:14 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Rudy Velthuis (TeamB) wrote:
Brandon Staggs wrote:

Sure. Same outcome. Removing capabilities developers rely on to
fix bugs in code they can't control, like the VCL.

Developers should not have relied on what amounted to being a bug.
That was their problem. Now the bug is fixed and they start moaning.
<shaking head>

And how are we supposed to know that was a bug?

Very easily: if you can access what you should not be able to access,
it is a bug. It should have been clear to everyone that something was
wrong there.

--
Rudy Velthuis http://www.rvelthuis.de

"It always takes longer than you expect, even when you take into
account Hofstadter's Law." -- Hofstadter's Law

Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 1:44 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Mon, 30 Jan 2017 02:14:52 -0800:

Very easily: if you can access what you should not be able to access,
it is a bug. It should have been clear to everyone that something was
wrong there.

So RTTI is one big mistake?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 5, 2017 6:27 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Mon, 30 Jan 2017 02:14:52 -0800:

Very easily: if you can access what you should not be able to
access, it is a bug. It should have been clear to everyone that
something was wrong there.

So RTTI is one big mistake?

No, not at all. But using RTTI is far more tedious than using a simple
class helper. You are still able to hack (just like my locked front
door can still be opened by others, if the need arises), but it is not
easy anymore.

And the main purpose of RTTI is not making it easy to do bad things.
The main purpose is to provide meta-information for tools.

--
Rudy Velthuis http://www.rvelthuis.de

"Physics is not a religion. If it were, we'd have a much easier
time raising money." -- Leon Lenderman
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 10:01 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Mon, 16 Jan 2017 00:03:21 -0800:

Brandon Staggs wrote:

Sure. Same outcome. Removing capabilities developers rely on to fix
bugs in code they can't control, like the VCL.

Developers should not have relied on what amounted to being a bug.

It didn't seem like a bug to me when I started using it. It seemed
like a feature. And for a decade it was a highly-recommended (sure,
not by Emba) and used way of doing certain things.

I guess it was unintentional, but exactly who benefited from "fixing"
the bug? Who was able to do a better job coding with Delphi because
class helpers are no longer able to reference private members?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Tim Frost

Posts: 19
Registered: 11/21/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 16, 2017 3:48 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

And for a decade it was a highly-recommended (sure,
not by Emba) and used way of doing certain things.

Maybe not Emba, but perhaps Borland or Codegear. I first learned about
them from a book called Delphi 2007 Handbook, which described class
helpers in glowing terms as 'a quite astonishing trick' (page 89). I
wonder who it was who wrote that book....
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 17, 2017 9:46 AM   in response to: Tim Frost in response to: Tim Frost
Am 17.01.2017 um 00:48 schrieb Tim Frost:
Brandon Staggs wrote:

And for a decade it was a highly-recommended (sure,
not by Emba) and used way of doing certain things.

Maybe not Emba, but perhaps Borland or Codegear. I first learned about
them from a book called Delphi 2007 Handbook, which described class
helpers in glowing terms as 'a quite astonishing trick' (page 89). I
wonder who it was who wrote that book....

Hehe...
But just for the record: Marco wasn't yet employee at EMBT/Codegear back
then! ;-)

Greetings

Markus
Stefan Glienke

Posts: 589
Registered: 1/5/09
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 7:30 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
I guess it was unintentional, but exactly who benefited from "fixing"
the bug? Who was able to do a better job coding with Delphi because
class helpers are no longer able to reference private members?

Everyone that now don't have to deal with "After the update of your library xyz my code does not compile anymore" because someone intentionally
or unintentionally did access a private member which is implementation detail and usually not part of API that should not change between non breaking updates.

Seriously - get over it. I used this hack in the past and found other ways to fix broken code (or - surprise - said issues were fixed and I don't need these hacks at all anymore).
I know during the initial discussion about this fix many things in the RTL/VCL that were private before and required this hack were made protected so you can just access them.
If there are still issues which require you to use this hack - lean back, think about another way, check if the issue even exists anymore and if it does, report it.
In the time you spend here ranting you could have fixed how many bugs?
Lajos Juhasz

Posts: 587
Registered: 3/14/14
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 8:11 AM   in response to: Stefan Glienke in response to: Stefan Glienke
Stefan Glienke wrote:

Brandon Staggs wrote:
I guess it was unintentional, but exactly who benefited from
"fixing" the bug? Who was able to do a better job coding with
Delphi because class helpers are no longer able to reference
private members?

Everyone that now don't have to deal with "After the update of your
library xyz my code does not compile anymore" because someone
intentionally or unintentionally did access a private member which is
implementation detail and usually not part of API that should not
change between non breaking updates.

Seriously - get over it. I used this hack in the past and found other
ways to fix broken code (or - surprise - said issues were fixed and I
don't need these hacks at all anymore). I know during the initial
discussion about this fix many things in the RTL/VCL that were
private before and required this hack were made protected so you can
just access them. If there are still issues which require you to use
this hack - lean back, think about another way, check if the issue
even exists anymore and if it does, report it. In the time you spend
here ranting you could have fixed how many bugs?

Sometimes the only viable solution is to make a field protected instead
of private and some methods should be virtual protected.

Unfortunately QC's that asks to make these changes are not always
implemented. I wonder why is so hard to Embarcadero to make those
changes.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:35 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:

Unfortunately QC's that asks to make these changes are not always
implemented. I wonder why is so hard to Embarcadero to make those
changes.

Because every change can have a possible (not always very obvious) side
effect and must be tested, etc. again, and docs must be changed, etc.
They don't change functioning code unless there is a good reason for it.

--
Rudy Velthuis http://www.rvelthuis.de

"The nationalist not only does not disapprove of atrocities
committed by his own side, but he has a remarkable capacity for
not even hearing about them."
-- George Orwell
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 10:01 AM   in response to: Stefan Glienke in response to: Stefan Glienke
"Stefan Glienke" wrote on Thu, 19 Jan 2017 07:30:09 -0800:

Everyone that now don't have to deal with "After the update of your library xyz my code does not compile anymore" because someone intentionally

That's THEIR problem. You can STILL have all sorts of problems caused
by class helpers. If someone fixes something in your library by
directly addressing a private member, and then you change it, that's
on THEM. Why is it a problem? So you don't have to answer your
customers? So I am no longer allowed to cleanly address bugs in the
VCL just so that your customers won't do something that irritates you?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Stefan Glienke

Posts: 589
Registered: 1/5/09
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 10:17 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
That's THEIR problem. You can STILL have all sorts of problems caused
by class helpers. If someone fixes something in your library by
directly addressing a private member, and then you change it, that's
on THEM. Why is it a problem? So you don't have to answer your
customers? So I am no longer allowed to cleanly address bugs in the
VCL just so that your customers won't do something that irritates you?

You are serving the same strawman arguments over and over - yet I have not seen a specific bug that
you fixed with using a class helper that cannot be fixed nor could not be fixed before their introduction.

I know for sure that if I provide some closed source library I don't want to mess people around with private fields.
If something is private it is for a reason. And no, software is not about ultimate freedom to do whatever you want because you can (or think you can).

And to all the so called pragmatists (those that think all these OOP purists are just theorists). I have seen code of people like you solving problems without thinking
beyond the day after tomorrow and without thinking of anything else that can be affected by your "solutions".

Something is really ridiculous:
If something does not work and it is clearly a bug or wrong design people complain all day long.
If something does not work but its beneficial for them but someone fixes it people complain all day long.

Schizophrenia much?
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 11:30 AM   in response to: Stefan Glienke in response to: Stefan Glienke
"Stefan Glienke" wrote on Thu, 19 Jan 2017 10:17:45 -0800:

You are serving the same strawman arguments

Not really. The arguments in favor of being able to access a private
member of a class are valid. You may not agree that they are strong
arguments, but they are valid arguments nontheless. There is no
"straw man." It is manifestly true that class helpers could be used
to address problems in the VCL.

Again you bring up OOP purity. Then get rid of class helpers
altogether. They exist for the express purpose of avoiding
inheritance. As long as you have class helpers that let you extend a
class without descending from the class, you have something "impure."

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com

Stefan Glienke

Posts: 589
Registered: 1/5/09
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 11:34 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
Again you bring up OOP purity. Then get rid of class helpers
altogether. They exist for the express purpose of avoiding
inheritance. As long as you have class helpers that let you extend a
class without descending from the class, you have something "impure."

We can talk again once you learned more about software architecture and that inheritance
is not the only way (unfortunately to most Delphi developers it is) to extend classes.
Even though class helpers in its current form (and I am not referring to the fact that they cannot access private members) are very limited.
There are OO programming languages out there that go far beyond that - and they are not new.
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 11:41 AM   in response to: Stefan Glienke in response to: Stefan Glienke
"Stefan Glienke" wrote on Thu, 19 Jan 2017 11:34:52 -0800:

We can talk again once you learned more about software architecture and that inheritance
is not the only way (unfortunately to most Delphi developers it is) to extend classes.

Of course there are other ways. You seem to be missing the point.
But never mind.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 20, 2017 8:12 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 19.01.2017 um 20:30 schrieb Brandon Staggs:
"Stefan Glienke" wrote on Thu, 19 Jan 2017 10:17:45 -0800:

You are serving the same strawman arguments

Not really. The arguments in favor of being able to access a private
member of a class are valid. You may not agree that they are strong
arguments, but they are valid arguments nontheless. There is no
"straw man." It is manifestly true that class helpers could be used
to address problems in the VCL.

Again you bring up OOP purity. Then get rid of class helpers
altogether. They exist for the express purpose of avoiding
inheritance. As long as you have class helpers that let you extend a
class without descending from the class, you have something "impure."


Hello,

why don't you present a real world VCL bug which could not be fixed
whithout having access to some private field?
That would be easier than to argue over and over with Stefan. If you
present him a bug where he cannot solve it (except by making a copy of
that VCL unit) without that access he surely will calm down and that
will bring the discussion to a way more fruitful level.

Greetings

Markus
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 20, 2017 8:59 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Am 19.01.2017 um 20:30 schrieb Brandon Staggs:
"Stefan Glienke" wrote on Thu, 19 Jan 2017 10:17:45 -0800:

You are serving the same strawman arguments

Not really. The arguments in favor of being able to access a private
member of a class are valid. You may not agree that they are strong
arguments, but they are valid arguments nontheless. There is no
"straw man." It is manifestly true that class helpers could be used
to address problems in the VCL.

Again you bring up OOP purity. Then get rid of class helpers
altogether. They exist for the express purpose of avoiding
inheritance. As long as you have class helpers that let you extend a
class without descending from the class, you have something "impure."


Hello,

why don't you present a real world VCL bug which could not be fixed
whithout having access to some private field?
That would be easier than to argue over and over with Stefan. If you
present him a bug where he cannot solve it (except by making a copy of
that VCL unit) without that access he surely will calm down and that
will bring the discussion to a way more fruitful level.

I don't think Stefan needs proofs that class helpers can be used for fixing
bugs.

TRttiParameter.Parent not pointing to correct TRttiMethod instance
https://quality.embarcadero.com/browse/RSP-9824

fix:

https://bitbucket.org/sglienke/spring4d/commits/c610768bf2da712b96eddd26d56fa2790ea66d5b

It is just more question of getting over things we cannot influence.

Or there is a chance we might...

Add possibility to access to private properties and methods in natural way like it was for class helpers
https://quality.embarcadero.com/browse/RSP-15273

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 21, 2017 12:17 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Am 20.01.2017 um 17:59 schrieb Dalija Prasnikar:


I don't think Stefan needs proofs that class helpers can be used for fixing
bugs.

That's not the question. The question is, whether there are any bugs
which can only be fixed that way (or by copying the source file and
modifying it).

Greetings

Markus
Alexandre Machado

Posts: 1,433
Registered: 8/10/13
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 22, 2017 1:06 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Am 20.01.2017 um 17:59 schrieb Dalija Prasnikar:


I don't think Stefan needs proofs that class helpers can be used for fixing
bugs.

That's not the question. The question is, whether there are any bugs
which can only be fixed that way (or by copying the source file and
modifying it).

Greetings

Markus

You also have to see this from the perspective of 3rd party component vendors. When you support multiple versions of Delphi (some Delphi component vendors support more than 20 different versions of Delphi and C++), copying source code and modifying it is not an option. Your library needs some core functionality from Delphi, which is broken. You can't sell your components and say to your customer "look, the component that you have just purchased doesn't work as you expect because of a Delphi bug, not ours". This is unacceptable.
The most robust and viable way to fix such errors is via class helpers. RTTI may not be available, shadow classes may break between versions, runtime patching may not work for packages (and sometimes you need class helpers to create a viable patch). What's left??
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 23, 2017 12:44 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Am 22.01.2017 um 22:06 schrieb Alexandre Machado:
Markus Humm wrote:
Am 20.01.2017 um 17:59 schrieb Dalija Prasnikar:


I don't think Stefan needs proofs that class helpers can be used for fixing
bugs.

That's not the question. The question is, whether there are any bugs
which can only be fixed that way (or by copying the source file and
modifying it).

Greetings

Markus

You also have to see this from the perspective of 3rd party component vendors. When you support multiple versions of Delphi (some Delphi component vendors support more than 20 different versions of Delphi and C++), copying source code and modifying it is not an option. Your library needs some core functionality from Delphi, which is broken. You can't sell your components and say to your customer "look, the component that you have just purchased doesn't work as you expect because of a Delphi bug, not ours"
. This is unacceptable.
The most robust and viable way to fix such errors is via class helpers. RTTI may not be available, shadow classes may break between versions, runtime patching may not work for packages (and sometimes you need class helpers to create a viable patch). What's left??

What's left is to present at least one real case which happened out in
the wild and really couldn't get properly fixed otherwise.
A single one is sufficient. Describing the issue like you did helps a
bit to put it in perspective, but one such real case is required to
really influence the opinion of those claiming this stuff is not really
needed and it was correct to fix it.

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 23, 2017 1:03 PM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Mon, 23 Jan 2017 12:44:09 -0800:

but one such real case is required to
really influence the opinion of those claiming this stuff is not really
needed and it was correct to fix it.

I don't believe that you will be convinced by "one case." There are a
hundred VCL bugs that have been fixed that were "fixable" with class
helpers during the interim. Like this one:

https://quality.embarcadero.com/browse/RSP-12624

This bug has been fixed. That is to embarcadero's credit. But when I
found the bug myself, it had not been fixed, and the best way to fix
it was with a class helper and a detour function to correct the buggy
PPI behavior.

Yes, it was fixed. But does that mean I have no reasonable
expectation of being able to fix it myself before the updates are
released?

Does that example not count? Why not?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 24, 2017 11:55 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 23.01.2017 um 22:03 schrieb Brandon Staggs:
"Markus Humm" wrote on Mon, 23 Jan 2017 12:44:09 -0800:

but one such real case is required to
really influence the opinion of those claiming this stuff is not really
needed and it was correct to fix it.

I don't believe that you will be convinced by "one case." There are a
hundred VCL bugs that have been fixed that were "fixable" with class
helpers during the interim. Like this one:

https://quality.embarcadero.com/browse/RSP-12624

This bug has been fixed. That is to embarcadero's credit. But when I
found the bug myself, it had not been fixed, and the best way to fix
it was with a class helper and a detour function to correct the buggy
PPI behavior.

Yes, it was fixed. But does that mean I have no reasonable
expectation of being able to fix it myself before the updates are
released?

Does that example not count? Why not?

Hello,

hey, did I claim your example doesn't count? No!
The example may count if there's no other viable way besides making a
copy of that source file.

Folks arguing in favour of fixing that helper "hole" will not count the
example presented if it could have been fixed by some other method, even
if the other method is not as type safe etc.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:49 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Markus Humm" wrote on Mon, 23 Jan 2017 12:44:09 -0800:

but one such real case is required to
really influence the opinion of those claiming this stuff is not
really needed and it was correct to fix it.

I don't believe that you will be convinced by "one case." There are a
hundred VCL bugs that have been fixed that were "fixable" with class
helpers during the interim.

And also fixable without them. And are they real bugs, or just work
differently than you'd like? Who says that your access of these
internals does not cause new, perhaps not so obvious bugs? How thorough
are your tests?

Again: things are made private to protect the integrity of the object
or class. If you meddle with that, you may (inadvertently) put it in a
bad state.

--
Rudy Velthuis http://www.rvelthuis.de

"I have never let my schooling interfere with my education."
-- Mark Twain (1835-1910)
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 3:01 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 05.03.2017 um 09:49 schrieb Rudy Velthuis (TeamB):
Brandon Staggs wrote:

"Markus Humm" wrote on Mon, 23 Jan 2017 12:44:09 -0800:

but one such real case is required to
really influence the opinion of those claiming this stuff is not
really needed and it was correct to fix it.

I don't believe that you will be convinced by "one case." There are a
hundred VCL bugs that have been fixed that were "fixable" with class
helpers during the interim.

And also fixable without them.

DIsregarding your other statements which are ok: since we didn't get
presented such an exaple your conclusion that they're fixable without
this access (and without making a copy of the unit and maintining this
from that point on) is mood. Sorry. Since you don't know the exact case
you cannot prove that it's fixable wiothout this access strategy now no
longer working. Afaik the removed strategy was more save than the still
working alternatives.

The best solution would still be more timely fixes from EMBT, but I fear
this stays a dream for the time being.

Greetings

Markus
Quentin Correll


Posts: 2,118
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 11:36 AM   in response to: Markus Humm in response to: Markus Humm
Markus,

| mood

moot ;-)

--

Q -- XanaNews 1.19.1.372 - 2017-03-06 11:37:20
Alexandre Machado

Posts: 1,433
Registered: 8/10/13
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 12:05 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

since we didn't get presented such an exaple your conclusion that they're fixable without
this access

From the top of my head: TFields.FindField() and TParams.FindParam() methods both have poor (slow) implementations which can be made at least 3x faster (I've done it in one of my projects, where this was critical, and this was accomplished using class helpers). Show me a way to improve them without Class helpers.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 9:13 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Am 06.03.2017 um 21:07 schrieb Alexandre Machado:
Markus Humm wrote:

since we didn't get presented such an exaple your conclusion that they're fixable without
this access

From the top of my head: TFields.FindField() and TParams.FindParam() methods both have poor (slow) implementations which can be made at least 3x faster (I've done it in one of my projects, where this was critical, and this was accomplished using class helpers). Show me a way to improve them without Class helpers.

I won't as I don't know the solution, but the others quetioning that
it's necessary should do now.

I'm curious to see the alternative solutions now.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:34 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:

Markus Humm wrote:

since we didn't get presented such an exaple your conclusion that
they're fixable without this access

From the top of my head: TFields.FindField() and TParams.FindParam()
methods both have poor (slow) implementations which can be made at
least 3x faster (I've done it in one of my projects, where this was
critical, and this was accomplished using class helpers). Show me a
way to improve them without Class helpers.

FindField simply does:

FDict.TryGetValue(AnsiLowerCase(FieldName), Result);

So ISTM what needs to be improved is TDictionary<T>'s TryGetValue. Why
do you need class helpers for that?

--
Rudy Velthuis http://www.rvelthuis.de

"I have always wished that my computer would be as easy to use
as my telephone. My wish has come true. I no longer know how
to use my telephone." -- Bjarne Stroustrup
Lajos Juhasz

Posts: 587
Registered: 3/14/14
Re: Rant: Class Helpers Neutered [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 7:54 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Alexandre Machado wrote:

Markus Humm wrote:

since we didn't get presented such an exaple your conclusion that
they're fixable without this access

From the top of my head: TFields.FindField() and TParams.FindParam()
methods both have poor (slow) implementations which can be made at
least 3x faster (I've done it in one of my projects, where this was
critical, and this was accomplished using class helpers). Show me a
way to improve them without Class helpers.

FindField simply does:

FDict.TryGetValue(AnsiLowerCase(FieldName), Result);

So ISTM what needs to be improved is TDictionary<T>'s TryGetValue. Why
do you need class helpers for that?

Most probably Alexandre was talking about the previous implementation.
This is the improved version of the FindField in the recent versions. I
cannot remember in exactly which version was this introduced, maybe
Seattle?
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:30 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 05.03.2017 um 09:49 schrieb Rudy Velthuis (TeamB):
Brandon Staggs wrote:

"Markus Humm" wrote on Mon, 23 Jan 2017 12:44:09 -0800:

but one such real case is required to
really influence the opinion of those claiming this stuff is not
really needed and it was correct to fix it.

I don't believe that you will be convinced by "one case." There
are a >> hundred VCL bugs that have been fixed that were "fixable"
with class >> helpers during the interim.

And also fixable without them.

DIsregarding your other statements which are ok: since we didn't get
presented such an exaple your conclusion that they're fixable without
this access (and without making a copy of the unit and maintining this
from that point on) is mood.

You probably meant "moot".

I never had problems finding a way to achieve what I wanted, even
before class helpers were introduced.

So let's wait for that example.

--
Rudy Velthuis http://www.rvelthuis.de

"When did I realize I was God? Well, I was praying and I
suddenly realized I was talking to myself."
-- Jack Gurney - "The Ruling Class"
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 6:22 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Sun, 5 Mar 2017 00:49:28 -0800:

And are they real bugs, or just work
differently than you'd like?

Why is the even relevant? What if somebody needs to change how it
works for their own use and they don't want to rewrite or copy and
paste the whole unit to do it? Seriously, what is with the code nazi?
NO FIELDS FOR YOU!

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:35 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Sun, 5 Mar 2017 00:49:28 -0800:

And are they real bugs, or just work
differently than you'd like?

Why is the even relevant?

It is terribly relevant. If you call things that simply don't match
your expectations, but work correctly and as designed, "bugs", we have
a big problem.
--
Rudy Velthuis http://www.rvelthuis.de

"A picture is worth a thousand words (which is why it takes a
thousand times longer to load...)"
-- Eric Tilton, Composing Good HTML
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 5:50 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Tue, 7 Mar 2017 15:35:58 -0800:

It is terribly relevant. If you call things that simply don't match
your expectations, but work correctly and as designed, "bugs", we have
a big problem.

Both are perfectly valid reasons to change behavior. In case you've
forgotten, most of us are paying customers of Embarcadero. They
aren't just gracing us with their public methods and fields. We are
actually PAYING THEM FOR CODE WE NEED.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:51 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

In case you've forgotten, most of us are paying customers of
Embarcadero.

I have absolutely no clue how that matters. I am a paying customer of
BMW, but am not allowed to meddle with many of the inner workings of my
car.

--
Rudy Velthuis http://www.rvelthuis.de

"Distrust all in whom the impulse to punish is powerful."
-- Nietzsche
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 6:12 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Brandon Staggs wrote:

In case you've forgotten, most of us are paying customers of
Embarcadero.

I have absolutely no clue how that matters. I am a paying customer of
BMW, but am not allowed to meddle with many of the inner workings of
my car.

And I probably paid much more for my car than you paid for Delphi. <g>

--
Rudy Velthuis http://www.rvelthuis.de

"A printer consists of three main parts: the case, the jammed
paper tray and the blinking red light" -- unknown
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:45 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 22.01.2017 um 22:06 schrieb Alexandre Machado:
Markus Humm wrote:
Am 20.01.2017 um 17:59 schrieb Dalija Prasnikar:


I don't think Stefan needs proofs that class helpers can be used
for fixing >>> bugs.

That's not the question. The question is, whether there are any
bugs >> which can only be fixed that way (or by copying the source
file and >> modifying it).

Greetings

Markus

You also have to see this from the perspective of 3rd party
component vendors. When you support multiple versions of Delphi
(some Delphi component vendors support more than 20 different
versions of Delphi and C++), copying source code and modifying it
is not an option. Your library needs some core functionality from
Delphi, which is broken. You can't sell your components and say to
your customer "look, the component that you have just purchased
doesn't work as you expect because of a Delphi bug, not our
s"
. This is unacceptable.
The most robust and viable way to fix such errors is via class
helpers. RTTI may not be available, shadow classes may break
between versions, runtime patching may not work for packages (and
sometimes you need class helpers to create a viable patch). What's
left??

What's left is to present at least one real case which happened out in
the wild and really couldn't get properly fixed otherwise.

There is none. The author may think there is no other way, but that
is usually his or her problem. And that other way may not be so
convenient, and that is why people complain: it was sooooo easy.

Note that before class helpers, people managed to work around (real
or perceived) bugs too. The only thing that you can't really work
around are bugs in the compiler or code generator. But for that, class
helpers won't help either.

--
Rudy Velthuis http://www.rvelthuis.de

Brilliant's Law Of Limited Ambition: If you can't learn how to do
it well, learn how to enjoy doing it poorly.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 3:03 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 05.03.2017 um 09:45 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:


What's left is to present at least one real case which happened out in
the wild and really couldn't get properly fixed otherwise.

There is none. The author may think there is no other way, but that
is usually his or her problem. And that other way may not be so
convenient, and that is why people complain: it was sooooo easy.

Note that before class helpers, people managed to work around (real
or perceived) bugs too. The only thing that you can't really work
around are bugs in the compiler or code generator. But for that, class
helpers won't help either.

People complain because the other ways do not seem to be as type save as
the removed way via class helpers. And sorry to say, esp. FMX still has
quite some bugs.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:37 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 05.03.2017 um 09:45 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:


What's left is to present at least one real case which happened
out in >> the wild and really couldn't get properly fixed otherwise.

There is none. The author may think there is no other way, but that
is usually his or her problem. And that other way may not be so
convenient, and that is why people complain: it was sooooo easy.

Note that before class helpers, people managed to work around (real
or perceived) bugs too. The only thing that you can't really work
around are bugs in the compiler or code generator. But for that,
class helpers won't help either.

People complain because the other ways do not seem to be as type save
as the removed way via class helpers.

You mean type safe.

Class helpers, as they were, were terribly unsafe, although perhaps not
really type unsafe. They broke the protection given by private.

--
Rudy Velthuis http://www.rvelthuis.de

"The vast majority of mankind is trapped within perceptual
prisons."
-- Shawn Mikula
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 9:45 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 08.03.2017 um 00:37 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:


People complain because the other ways do not seem to be as type save
as the removed way via class helpers.

You mean type safe.

Yes, typo.


Class helpers, as they were, were terribly unsafe, although perhaps not
really type unsafe. They broke the protection given by private.

Which is something else and has already been discussed.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:52 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 08.03.2017 um 00:37 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:


People complain because the other ways do not seem to be as type
save >> as the removed way via class helpers.

You mean type safe.

Yes, typo.


Class helpers, as they were, were terribly unsafe, although perhaps
not really type unsafe. They broke the protection given by private.

Which is something else and has already been discussed.

So they may have been type safe, but otherwise terribly unsafe, and
that was fixed.

--
Rudy Velthuis http://www.rvelthuis.de

"Clothes make the man. Naked people have little or no influence
on society." -- Mark Twain
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 10:46 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 11.03.2017 um 16:52 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

Am 08.03.2017 um 00:37 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:


People complain because the other ways do not seem to be as type
save >> as the removed way via class helpers.

You mean type safe.

Yes, typo.


Class helpers, as they were, were terribly unsafe, although perhaps
not really type unsafe. They broke the protection given by private.

Which is something else and has already been discussed.

So they may have been type safe, but otherwise terribly unsafe, and
that was fixed.

Afaik the other workarounds aren't even type safe.
Is this really better?

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 15, 2017 12:26 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

So they may have been type safe, but otherwise terribly unsafe, and
that was fixed.

Afaik the other workarounds aren't even type safe.
Is this really better?

Yes, because it makes people aware they are hacking and doing something
they shouldn't actually be doing. With the convenient "type safe" class
helper method, they weren't.
--
Rudy Velthuis http://www.rvelthuis.de

"A good sermon should be like a woman's skirt: short enough to
arouse interest but long enough to cover the essentials."
-- Ronald Knox.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 16, 2017 10:13 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 15.03.2017 um 20:26 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

So they may have been type safe, but otherwise terribly unsafe, and
that was fixed.

Afaik the other workarounds aren't even type safe.
Is this really better?

Yes, because it makes people aware they are hacking and doing something
they shouldn't actually be doing. With the convenient "type safe" class
helper method, they weren't.

No. I still can use them. Will they emit any compiler warnings? I guess
not. So they're not better. If that class helper stuff used that way
which no longer works would issue a non silenceable warning, it would
make people way more aware of what they're doing!

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 17, 2017 9:19 AM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Thu, 16 Mar 2017 10:13:39 -0700:

No. I still can use them. Will they emit any compiler warnings? I guess
not. So they're not better. If that class helper stuff used that way
which no longer works would issue a non silenceable warning, it would
make people way more aware of what they're doing!

Exactly. Delphi allows a lot of easy unsafe actions, and a lot of
those emit a warning. I wouldn't want it to be impossible to suppress
the warning, but I would never have objected to being warned that I
was crossing into private fields when doing so with a class helper.
At the very least, Embarcadero could have shown a little bit of
concern for their customers who have been using the feature for a
decade and deprecated it for a release before breaking it...

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 6:15 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Markus Humm" wrote on Thu, 16 Mar 2017 10:13:39 -0700:

No. I still can use them. Will they emit any compiler warnings? I
guess not. So they're not better. If that class helper stuff used
that way which no longer works would issue a non silenceable
warning, it would make people way more aware of what they're doing!

Exactly. Delphi allows a lot of easy unsafe actions,

And now one that was pretty dangerous was made less easy. Very good.
--
Rudy Velthuis http://www.rvelthuis.de

"I'd stop eating chocolate, but I'm no quitter." -- Unknown
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 6:14 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 15.03.2017 um 20:26 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

So they may have been type safe, but otherwise terribly unsafe,
and >>> that was fixed.

Afaik the other workarounds aren't even type safe.
Is this really better?

Yes, because it makes people aware they are hacking and doing
something they shouldn't actually be doing. With the convenient
"type safe" class helper method, they weren't.

No. I still can use them.

Yes, you can hack. You can also break into someone's garage and have
fun with their car. Does that mean you should? Does that mean it should
be made easy, by providing a key that can open any door without any
damage? I don't think so.
--
Rudy Velthuis http://www.rvelthuis.de

"You can't have everything. Where would you put it?"
-- Steven Wright
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 7:31 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 19.03.2017 um 14:14 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

Am 15.03.2017 um 20:26 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

So they may have been type safe, but otherwise terribly unsafe,
and >>> that was fixed.

Afaik the other workarounds aren't even type safe.
Is this really better?

Yes, because it makes people aware they are hacking and doing
something they shouldn't actually be doing. With the convenient
"type safe" class helper method, they weren't.

No. I still can use them.

Yes, you can hack. You can also break into someone's garage and have
fun with their car. Does that mean you should? Does that mean it should
be made easy, by providing a key that can open any door without any
damage? I don't think so.

Hm, in case of Delphis RTL/VCL and FMX you even bought a usage right...
=> Nick is one more time correct about car analogies...

Btw. Nick changed job slightly...

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 7:37 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 19.03.2017 um 14:14 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

Am 15.03.2017 um 20:26 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

So they may have been type safe, but otherwise terribly unsafe,
and >>> that was fixed.

Afaik the other workarounds aren't even type safe.
Is this really better?

Yes, because it makes people aware they are hacking and doing
something they shouldn't actually be doing. With the convenient
"type safe" class helper method, they weren't.

No. I still can use them.

Yes, you can hack. You can also break into someone's garage and have
fun with their car. Does that mean you should? Does that mean it
should be made easy, by providing a key that can open any door
without any damage? I don't think so.

Hm, in case of Delphis RTL/VCL and FMX you even bought a usage
right...

Yes, so what? I have the usage rights of my car too, but I am not
allowed to change the inner workings anyway.

I don't agree with Nick. Car analogies work, if you don't take them too
far.

In this case it was a lock analogy anyway (private is a lock, but it
can be overcome, although it should not be too easy).
--
Rudy Velthuis http://www.rvelthuis.de

"There are two ways to write error-free programs; only the third
works." -- Alan J. Perlis
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 10:12 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 19.03.2017 um 15:37 schrieb Rudy Velthuis (TeamB):

Yes, so what? I have the usage rights of my car too, but I am not
allowed to change the inner workings anyway.

I don't agree with Nick. Car analogies work, if you don't take them too
far.

In this case it was a lock analogy anyway (private is a lock, but it
can be overcome, although it should not be too easy).

Hello,

issue is: you have no usage right on your neighbours garage ;-)
So your lock analogy doesn't 100% fit.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 10:50 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

In this case it was a lock analogy anyway (private is a lock, but it
can be overcome, although it should not be too easy).

Hello,

issue is: you have no usage right on your neighbours garage ;-)

You have no access rights to the private members of my classes either.
<g>

--
Rudy Velthuis http://www.rvelthuis.de

"The church tries to save sinners, but science seeks to stop
their manufacture."
-- Elbert Hubbard
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 20, 2017 1:18 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 19.03.2017 um 18:50 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

In this case it was a lock analogy anyway (private is a lock, but it
can be overcome, although it should not be too easy).

Hello,

issue is: you have no usage right on your neighbours garage ;-)

You have no access rights to the private members of my classes either.
<g>

No, but if I have the source I can say "I don't care" ;-)
And as long as I don't bother you with support requests about these
things it's only my issue if something doesn't work as I expect and you
even might never know that I did get access to them ;-)

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 20, 2017 1:29 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 19.03.2017 um 18:50 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

In this case it was a lock analogy anyway (private is a lock, but
it >>> can be overcome, although it should not be too easy).

Hello,

issue is: you have no usage right on your neighbours garage ;-)

You have no access rights to the private members of my classes
either. <g>

No, but if I have the source I can say "I don't care" ;-)

Having the source is like knowing how a house is built (e.g. because
you lived there before). That doesn't mean you can enter it now.
--
Rudy Velthuis http://www.rvelthuis.de

"Where humor is concerned there are no standards - no one can
say what is good or bad, although you can be sure that everyone
will." -- John Kenneth Galbraith (1908-2006)
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 21, 2017 5:23 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Mon, 20 Mar 2017 13:29:15 -0700:

Having the source is like knowing how a house is built (e.g. because
you lived there before). That doesn't mean you can enter it now.

Pfft. I would never use a third party component for anything important
if I didn't get the source. Not because I want to be able to "know
how it was built," but because I may need to change it some day.

This is not some silly analogy for many of us. One simple example
would be hard-coded pixel sizes for controls that should never have
been hard-coded. Raize components is otherwise good, but there are
fixed pixel values that make high-DPI and especially mixed-DPI support
very poor. Your ridiculous idea that I have no "right" to alter
private elements of controls would mean that the controls are not
useful to me at all and I would have to use a different component.
But that is just silly, since it was not difficult to fix the
controls so that they render properly on high-DPI. And I have the
source code. Your sensibilities may be offended, but I am going to
update the source code myself because I do not want to change out
controls I have been using for over a decade.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 21, 2017 9:51 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 21.03.2017 um 13:23 schrieb Brandon Staggs:
"Rudy Velthuis" wrote on Mon, 20 Mar 2017 13:29:15 -0700:

Having the source is like knowing how a house is built (e.g. because
you lived there before). That doesn't mean you can enter it now.

Pfft. I would never use a third party component for anything important
if I didn't get the source. Not because I want to be able to "know
how it was built," but because I may need to change it some day.

This is not some silly analogy for many of us. One simple example
would be hard-coded pixel sizes for controls that should never have
been hard-coded. Raize components is otherwise good, but there are
fixed pixel values that make high-DPI and especially mixed-DPI support
very poor. Your ridiculous idea that I have no "right" to alter
private elements of controls would mean that the controls are not
useful to me at all and I would have to use a different component.
But that is just silly, since it was not difficult to fix the
controls so that they render properly on high-DPI. And I have the
source code. Your sensibilities may be offended, but I am going to
update the source code myself because I do not want to change out
controls I have been using for over a decade.

Hello,

did you report this issue with the fixed pixel sizes not working for
High DPI?

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 21, 2017 11:06 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Mon, 20 Mar 2017 13:29:15 -0700:

Having the source is like knowing how a house is built (e.g. because
you lived there before). That doesn't mean you can enter it now.

Pfft. I would never use a third party component for anything important
if I didn't get the source. Not because I want to be able to "know
how it was built," but because I may need to change it some day.

Sure. But I guess you would start doing that if the component was
discontinued or all of a sudden extremely buggy. Then you would not
care about support much anymore, I guess.

I am not a component vendor, but if I were, I would refuse to support
any code that was modified by the user.
--
Rudy Velthuis http://www.rvelthuis.de

"Behind every successful man is a woman, behind her is his wife."
-- Groucho Marx
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 21, 2017 1:31 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 21.03.2017 um 19:06 schrieb Rudy Velthuis (TeamB):
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Mon, 20 Mar 2017 13:29:15 -0700:

Having the source is like knowing how a house is built (e.g. because
you lived there before). That doesn't mean you can enter it now.

Pfft. I would never use a third party component for anything important
if I didn't get the source. Not because I want to be able to "know
how it was built," but because I may need to change it some day.

Sure. But I guess you would start doing that if the component was
discontinued or all of a sudden extremely buggy. Then you would not
care about support much anymore, I guess.

I am not a component vendor, but if I were, I would refuse to support
any code that was modified by the user.

Nobody asked for that support on a user modified 3rd party (or EMBT)
unit. Or did anybody?

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 24, 2017 5:22 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

I am not a component vendor, but if I were, I would refuse to
support any code that was modified by the user.

Nobody asked for that support on a user modified 3rd party (or EMBT)
unit. Or did anybody?

How do you know? Ask the 3rd party vendors.

--
Rudy Velthuis http://www.rvelthuis.de

"Manuscript: something submitted in haste and returned at
leisure." -- Oliver Herford (1863-1935)
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 24, 2017 9:25 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 24.03.2017 um 13:22 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

I am not a component vendor, but if I were, I would refuse to
support any code that was modified by the user.

Nobody asked for that support on a user modified 3rd party (or EMBT)
unit. Or did anybody?

How do you know? Ask the 3rd party vendors.

Nobody here asked for EMBT support of such code.
So they're all ok with maintaining such fixes themselves as it seems.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 24, 2017 12:10 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 24.03.2017 um 13:22 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

I am not a component vendor, but if I were, I would refuse to
support any code that was modified by the user.

Nobody asked for that support on a user modified 3rd party (or
EMBT) >> unit. Or did anybody?

How do you know? Ask the 3rd party vendors.

Nobody here asked for EMBT support of such code.

Of course not. Because they know they won't get it.

--
Rudy Velthuis http://www.rvelthuis.de

"Not everything that can be counted counts, and not everything
that counts can be counted." -- Albert Einstein (1879-1955)
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2017 3:03 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 24.03.2017 um 20:10 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

Am 24.03.2017 um 13:22 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

I am not a component vendor, but if I were, I would refuse to
support any code that was modified by the user.

Nobody asked for that support on a user modified 3rd party (or
EMBT) >> unit. Or did anybody?

How do you know? Ask the 3rd party vendors.

Nobody here asked for EMBT support of such code.

Of course not. Because they know they won't get it.

So your previous point is moot. ;-)

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 22, 2017 5:59 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Tue, 21 Mar 2017 11:06:19 -0700:

I am not a component vendor, but if I were, I would refuse to support
any code that was modified by the user.

Of course. That is only reasonable.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 25, 2017 6:12 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Tue, 21 Mar 2017 11:06:19 -0700:

I am not a component vendor, but if I were, I would refuse to
support any code that was modified by the user.

Of course. That is only reasonable.

And I would make it hard to modify my code. I hate it when people ruin
my well crafted code with their own mods. If I think something must be
accessible, I'll make it accessible, but in a way that it can't
directly ruin the internal state.

--
Rudy Velthuis http://www.rvelthuis.de

"A time will come when a politician who has willfully made war
and promoted international dissension will be ... surer of the
noose than a private homicide."
-- H. G. Wells
Lajos Juhasz

Posts: 587
Registered: 3/14/14
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 20, 2017 3:41 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 19.03.2017 um 15:37 schrieb Rudy Velthuis (TeamB):

Yes, so what? I have the usage rights of my car too, but I am not
allowed to change the inner workings anyway.

I don't agree with Nick. Car analogies work, if you don't take them
too far.

In this case it was a lock analogy anyway (private is a lock, but it
can be overcome, although it should not be too easy).

Hello,

issue is: you have no usage right on your neighbours garage ;-)
So your lock analogy doesn't 100% fit.
Of course you don't have right for a neighbours garage, but for on open
parking place can happen quite frequently that somebody will park
her/his car even when it's a private parking spot although it's still
not legal to do that.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:40 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:

The most
robust and viable way to fix such errors is via class helpers. RTTI
may not be available, shadow classes may break between versions,

So may class helpers (ifthe private field was changed -- after all,
that is what you can do with a private member: change it because it is
not accessible anyway), and they may not be available in all versions
of Delphi either. That's a bogus argument, sorry.

--
Rudy Velthuis http://www.rvelthuis.de

"I dream that someday the United States will be on the side of
the peasants in some civil war. I dream that we will be the
ones who will help the poor overthrow the rich, who will talk
about land reform and education and health facilities for
everyone, and that when the Red Cross or Amnesty International
comes to count the bodies and take the testimony of women
raped, that our side won't be the heavies."
-- Richard Cohen

Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 20, 2017 6:08 PM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Fri, 20 Jan 2017 08:12:55 -0800:

why don't you present a real world VCL bug which could not be fixed
whithout having access to some private field?

No, he already qualified that he regards some fixes as unnecessary and
wrong, so what is the point? It hardly takes much effort to look
through the quality portal to see VCL bugs that people can fix with
access to private members.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dean Hill

Posts: 16
Registered: 10/5/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 23, 2017 3:48 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Hello,

why don't you present a real world VCL bug which could not be fixed
whithout having access to some private field?
That would be easier than to argue over and over with Stefan. If you
present him a bug where he cannot solve it (except by making a copy of
that VCL unit) without that access he surely will calm down and that
will bring the discussion to a way more fruitful level.

Greetings

Markus

I already gave a real world example. Is it a bug? No, but a 2000% speed difference is not negligible when we use the Delphi streaming system to load and save data. We need access to FStream and FBufPos to get around this.

Want another one? We have a custom high DPI system that we put together before Emb added one to Delphi. That involves changing TCustomForm.ReadState, where we need access to FClientWidth, etc. Part of the issue is that third party components save their forms with Scaled = true so we need to work around this. Part of the problem is the way that Delphi saves fonts and automatically uses the DPI to change the height. We also have a bunch of changes that we hook in when we build for WINE. There is no way that Emb will is going to switch FCurrentFilterIndex and FFilterIndex in TOpenDialog to protected because we need things changed to properly support save dialogs in WINE which isn't a supported platform for them. I am not even talking about changes that we made for DevExpress.

These aren't changes that we just slapped on one day. They are fixes for situations that our clients encountered. In each case we researched them in depth and as a last resort opted to add a code hook to change some behavior in the VCL. In all cases we seriously considered the implications because ALL of these changes need to be investigated again when we upgrade Delphi. We have {$IFDEF VER300} in our code to make sure that they are investigated fully. In other words. Opting to go this route makes a lot of work for us when we upgrade so it's only done when absolutely necessary.

Could we find other ways around these? Of course. Is it a lot of work? Definitely and right now it's stopping us from upgrading because the new features in the latest version aren't nearly enough to justify the extra work in upgrading. Again I will ask the question. If Emb is so worried about language purity then why the hell is "goto" and "with" still in the language? You know why? Because they use it inside the VCL. Class helpers probably shouldn't be in the language from a strict purity point of view. All of the people here defending the purity of removing the "hack" aren't inconvenienced by having it removed. They didn't need to work around things. Stefan mentioned a back and forth between Emb and the developers where they move certain fields to protected. That was in a private beta. We weren't informed of the change before it happened and asked for feedback. Now my question to Marco on his blog asking where we should make these requests is sitting unanswered at the moment and any changes from now will be rather formal so us "needing" some fields changed because it probably only effects us is very unlikely to happen.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 24, 2017 11:58 AM   in response to: Dean Hill in response to: Dean Hill
Am 24.01.2017 um 00:48 schrieb Dean Hill:
Markus Humm wrote:
Hello,

why don't you present a real world VCL bug which could not be fixed
whithout having access to some private field?
That would be easier than to argue over and over with Stefan. If you
present him a bug where he cannot solve it (except by making a copy of
that VCL unit) without that access he surely will calm down and that
will bring the discussion to a way more fruitful level.

Greetings

Markus

We also have a bunch of changes that we hook in when we build for WINE.
There is no way that Emb will is going to switch FCurrentFilterIndex and
FFilterIndex in TOpenDialog to protected because we need things changed
to properly support save dialogs in WINE which isn't a supported platform
for them.


Did you enter those into QP as feature request?
If not you really should do! Don't prematurely claim "there's no way" if
you havenb't done that simple and not too time consuming step first!

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 24, 2017 1:49 PM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Tue, 24 Jan 2017 11:58:48 -0800:

Did you enter those into QP as feature request?

Let's say Embarcadero decides to implement his request to make the
fields protected.

Why shouldn't he be able to use a class helper to implement it himself
while he waits for Embarcadero to do it?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 25, 2017 8:53 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 24.01.2017 um 22:49 schrieb Brandon Staggs:
"Markus Humm" wrote on Tue, 24 Jan 2017 11:58:48 -0800:

Did you enter those into QP as feature request?

Let's say Embarcadero decides to implement his request to make the
fields protected.

Why shouldn't he be able to use a class helper to implement it himself
while he waits for Embarcadero to do it?

That's a different topic and the short answer is: because it enables
access to other fields where he should not have access to.

My pount is, that he should enter these requests into QP as feature
requests.

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 25, 2017 2:51 PM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Wed, 25 Jan 2017 08:53:35 -0800:

That's a different topic and the short answer is: because it enables
access to other fields where he should not have access to.

That's not a different topic at all. The argument is that class
helpers provide a clean way to fix bugs in objects you don't own the
source to.

"he should not have access to" -- so no RTTI then? No access to the
original source files either? Where's the consistency? Again it is
clear that breaking the most useful feature of class helpers in Delphi
comes down to ideology. Your ideology says there should be no way for
someone to touch a field in a parent class. Mine says that you should
avoid touching parent fields as much as possible and do so only as a
last resort, and that the language should give you clean ways to deal
with edge cases.

My pount is, that he should enter these requests into QP as feature
requests.

Isn't THAT the separate topic? Making feature requests is not a
viable replacement for class helpers. That should be obvious.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 26, 2017 9:03 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 25.01.2017 um 23:51 schrieb Brandon Staggs:
"Markus Humm" wrote on Wed, 25 Jan 2017 08:53:35 -0800:

That's a different topic and the short answer is: because it enables
access to other fields where he should not have access to.

That's not a different topic at all. The argument is that class
helpers provide a clean way to fix bugs in objects you don't own the
source to.

"he should not have access to" -- so no RTTI then? No access to the
original source files either? Where's the consistency? Again it is
clear that breaking the most useful feature of class helpers in Delphi
comes down to ideology. Your ideology says there should be no way for
someone to touch a field in a parent class. Mine says that you should
avoid touching parent fields as much as possible and do so only as a
last resort, and that the language should give you clean ways to deal
with edge cases.

Maybe.


My pount is, that he should enter these requests into QP as feature
requests.

Isn't THAT the separate topic? Making feature requests is not a
viable replacement for class helpers. That should be obvious.

Not making those will not get you ANYWHERE with this topic. That also
should be obvious by now. That might trigger some changes in future
releases. Discussing the helper issue here will not lead anywhere with EMBT.

Greetings

Markus
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 12:59 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Isn't THAT the separate topic? Making feature requests is not a
viable replacement for class helpers. That should be obvious.

Not making those will not get you ANYWHERE with this topic. That also
should be obvious by now. That might trigger some changes in future
releases.

When has doing so ever changed anything? When have features ever appeared because people requested them? How often have feature requests been ignored for DECADES on the other hand (strings in case statements, step for for loop, etc.)? The Powers That Be simply descend from Mount Olympus to tell us how they're going to do things. As David I. once said to me "...we just keep doing what we're doing." Delphi has never been a community-driven product.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 11:11 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Am 05.03.2017 um 21:59 schrieb Joseph Mitzen:
Markus Humm wrote:

Isn't THAT the separate topic? Making feature requests is not a
viable replacement for class helpers. That should be obvious.

Not making those will not get you ANYWHERE with this topic. That also
should be obvious by now. That might trigger some changes in future
releases.

When has doing so ever changed anything? When have features ever appeared because people requested them?

May well be, but not issung the request will leave everything to pure
luck or coincidence while submitting a request sometimes indeed helped.

Greetings

Markus
Alexandre Machado


Posts: 13
Registered: 1/16/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 25, 2017 12:48 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
"Markus Humm" wrote on Tue, 24 Jan 2017 11:58:48 -0800:

Did you enter those into QP as feature request?

Let's say Embarcadero decides to implement his request to make the
fields protected.

Why shouldn't he be able to use a class helper to implement it himself
while he waits for Embarcadero to do it?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com

Hi Brandon,

it is useless to discuss this.

It is just like trying to explain to some one who only knows Venice that you actually need a car to go to work and not a venetian gondola.

(just to use a different car/gondola analogy here! :-) )

Regards
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 25, 2017 2:52 PM   in response to: Alexandre Machado in response to: Alexandre Machado
"Alexandre Machado" wrote on Wed, 25 Jan 2017 12:48:24 -0800:

It is just like trying to explain to some one who only knows Venice that you actually need a car to go to work and not a venetian gondola.

LOL!

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dominique Willems

Posts: 513
Registered: 10/26/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 25, 2017 2:55 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:
you actually need a car to go to work and not a venetian gondola.

You must be a manager; I'm stuck on a vaporetto.
Alexandre Machado


Posts: 13
Registered: 1/16/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 25, 2017 4:10 PM   in response to: Dominique Willems in response to: Dominique Willems
You must be a manager; I'm stuck on a vaporetto.

No I'm not! But I bet you got it ;-)
Dominique Willems

Posts: 513
Registered: 10/26/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 26, 2017 7:59 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:
You must be a manager; I'm stuck on a vaporetto.

No I'm not! But I bet you got it ;-)

I got it all right, but you're still the one taking daily romantic
trips to work and back. ;)
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 5:49 PM   in response to: Stefan Glienke in response to: Stefan Glienke
Stefan Glienke wrote:

I know for sure that if I provide some closed source library I don't want to mess people around with private fields.

If you provided it, it's NOT YOURS ANYMORE. This reminds me of a woman I encountered selling puppies. She wanted references. She wanted to do a home inspection. She had a contract that dictated what brand of dog food you could feed the dog. She wanted to be able to conduct yearly (unannounced!) home inspections AFTER you bought the dog. And if you ever wanted to get rid of the dog, you had to give (not sell) the dog back to her. Someone put it perfectly: "It seems she isn't selling dogs but rather renting them."

This goes back to what Rudy tried to deny... it all boils down to "I want to control the code". Poke at the other arguments and they all fall away except this one. People are trying to hide code they're embarrassed about.

If something is private it is for a reason.

And there's that circular argument again. Whether there is a reason is the whole point we're debating. Actually I encountered a developer who said, "Unless I have a good reason, I seal ALL my classes!" to which I immediately replied, "Why am I not surprised that you work for Microsoft?" ;-) Basically, since no one here really can give a valid reason that stands up to scrutiny (and eventually they seem to admit it), it appears to be a case of cargo cult programming. People do it because they were taught to do it, even if they don't understand or can't explain why they do it. They certainly can't tell us what would happen if they didn't do it.

And no, software is not about ultimate freedom to do whatever you want because you can (or think you can).

Actually, open source rules the world now, so yes, it is about ultimate freedom to do whatever you want because you can. Proprietary code and file formats are going the way of the telegraph.

And to all the so called pragmatists (those that think all these OOP purists are just theorists). I have seen code of people like you solving problems without thinking
beyond the day after tomorrow and without thinking of anything else that can be affected by your "solutions".

So the only arguments boil down to "I don't want other people touching my code (even though I let them use it), I have my reasons (which I won't tell you), and anyone who wants to poke around in my code is a stupid programmer, unlike myself"?

I'll ask again - how does a language like Python, where information hiding is only by convention, manage to become one of the most popular languages in the world and not collapse in on itself, since it must be filled with non-OOP purists who don't think beyond the day after tomorrow?

The main reason for making (nearly) everything discoverable was debugging: when debugging you often need to break through the abstractions (since bugs don't confine them[selves] to the nice abstractions you've created for your program :-) so I
thought it would be handy to be able to see anything from the debugger. And since the debugger is written in Python itself (for flexibility and a number of other reasons) I figured the same would apply to other forms of programming -- after all, sometimes
debugging doesn't imply using a debugger, it may just imply printing a certain value. Again, too much data hiding would make things more complicated here.

The other observation was that even in C++, there are usually ways around the data hiding (e.g. questionable casts). Which made me realize that apparently other languages could live just fine with less-than-perfect hiding, and that hiding was an
advisory mechanism, not an enforcement mechanism. So Python could probably be just fine with even-less-than-perfect hiding. :-)

-Guido Van Rossum

Something is really ridiculous:
If something does not work and it is clearly a bug or wrong design people complain all day long.
If something does not work but its beneficial for them but someone fixes it

Something is ridiculous indeed.

If something is beneficial to someone, how does it "not work"? Isn't "makes my life easier" the only reason we use a development tool? And how is making something less beneficial "fixing it"?

Schizophrenia much?

Masochism much? Only in this community do I find so many developers who believe that things being hard and painful and slow is actually a good thing.
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 6:01 PM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Stefan Glienke wrote:

I know for sure that if I provide some closed source library I
don't want to mess people around with private fields.

If you provided it, it's NOT YOURS ANYMORE.

Huh? Oh, you can always copy the source code and do whatever you like,
of course, but if I had to provide support, that would not be covered.

If you meddle with the internals of my carefully crafted classes, you
are on your own.

--
Rudy Velthuis http://www.rvelthuis.de

"I'm living so far beyond my income that we may almost be said
to be living apart." -- e e cummings (1894-1962)
Dan Barclay

Posts: 701
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 19, 2017 10:11 AM   in response to: Stefan Glienke in response to: Stefan Glienke
Stefan Glienke wrote:
Seriously - get over it. I used this hack in the past and found other ways to fix broken code (or - surprise - said issues were fixed and I don't need these hacks at all anymore).

I think you misunderstand the actual problem.

The response isn't "get over it", the problem is more related to

"get over it",
"get over it",
"get over it",
"get over it",
"get over it",
"get over it",
...

I've never used the specific hack being discussed. OTOH, a build in one of my apps shows 750k lines. That's a lot for some folks, not much for others. While others certainly have larger apps, it does not diminish the work (or reliability/stability) problems that just one "get over it" causes even if only half of them affect me.

I had to "get over it" by placing a hold on Delphi upgrades. I don't like that, and it's bad for Delphi, but I (and I'm certain many others) are bleeding from the thousand cuts.

You may not like my view on that. If not, get over it. EMB needs to pay attention to that. They're losing well earned trust among a lot of developers. I don't think they (or many here) believe that but it's true. Nick and I have discussed it before, I'm not sure he is convinced either. Question: How do you spell VB?
http://vb.mvps.org/tips/stability/

Dan
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 2:22 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Mon, 16 Jan 2017 00:03:21 -0800:

Brandon Staggs wrote:

Sure. Same outcome. Removing capabilities developers rely on to
fix >> bugs in code they can't control, like the VCL.

Developers should not have relied on what amounted to being a bug.

It didn't seem like a bug to me when I started using it.

Oh? So if you walk around and see a wide open backdoor, it doesn't look
weird to you? Would you go inside and look in the drawers an under the
bed?

It totally circumvented privacy, which is one of the basic tenets of
OO. Of course it had to be a bug, what else?

--
Rudy Velthuis http://www.rvelthuis.de

Bove's Theorem: The remaining work to finish in order to reach
your goal increases as the deadline approaches.
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 30, 2017 1:45 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Mon, 30 Jan 2017 02:22:04 -0800:

Of course it had to be a bug, what else?

A very efficient way of addressing shortcomings in the VCL and other
third party libraries for which I do not control the source. And that
is exactly how I and others used it.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 5, 2017 6:33 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Mon, 30 Jan 2017 02:22:04 -0800:

Of course it had to be a bug, what else?

A very efficient way of addressing shortcomings in the VCL

I don't know if it was efficient, but it was convenient. And doing
things you should normally not do should never be convenient. The fact
I lock my front door doesn't stop everyone from entering, but it makes
it harder and most people won't think of entering my house uninvited.
And if they do, they violate laws.

I really fail to understand why professional programmers don't
understand this and that it takes a dentist, who programs as a hobby,
to tell them.
--
Rudy Velthuis http://www.rvelthuis.de

"Momma always said life was like a box of chocolates. You never
know what you're gonna get." -- Forest Gump
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Feb 6, 2017 6:17 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Sun, 5 Feb 2017 18:33:34 -0800:

I really fail to understand why professional programmers don't
understand this and that it takes a dentist, who programs as a hobby,
to tell them.

Because professional programmers actually have to deliver solutions.
And when your library contains a bug you need to fix, you need a way
to fix the bug before the tool vendor does. Before class helpers made
it possible to horizontally access class members, the usual way to do
this was by making a local copy of the tool source code, which is the
absolute worst of any option.

I don't know why you think this is controversial. The source code to
these units are not trade secrets. Programming tools exist to give us
ways to accomplish things. If we wanted an extremely strict
environment that didn't offer power when it was needed, we would be
using something else.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 1:30 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Sun, 5 Feb 2017 18:33:34 -0800:

I really fail to understand why professional programmers don't
understand this and that it takes a dentist, who programs as a
hobby, to tell them.

Because professional programmers actually have to deliver solutions.

Ah yes, they are "pragmatic", in other words, they don't like to be
obstructed if they want to do something they shouldn't.

<shaking head>

It is very well possible to produce proper programs without hving to
resort to such practices.

--
Rudy Velthuis http://www.rvelthuis.de

"In the End, we will remember not the words of our enemies, but
the silence of our friends."
-- Martin Luther King Jr. (1929-1968)
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 3:04 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 05.03.2017 um 10:30 schrieb Rudy Velthuis (TeamB):
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Sun, 5 Feb 2017 18:33:34 -0800:

I really fail to understand why professional programmers don't
understand this and that it takes a dentist, who programs as a
hobby, to tell them.

Because professional programmers actually have to deliver solutions.

Ah yes, they are "pragmatic", in other words, they don't like to be
obstructed if they want to do something they shouldn't.

<shaking head>

It is very well possible to produce proper programs without hving to
resort to such practices.

Hm? As far as I've understood the alternative ways to get access to fix
things EMBT has no fix for yet are more brittle. Or am I wrong?

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:57 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

It is very well possible to produce proper programs without hving to
resort to such practices.

Hm? As far as I've understood the alternative ways to get access to
fix things EMBT has no fix for yet are more brittle. Or am I wrong?

But usually, it is a false sense that you must acess these things to
achieve what you want. It is my experiecne that, most of the time,
there are many other, better ways to achieve what I want without
resorting to hacks.

Often, these are some kind of XY problems. The notion is: I must
achieve X, so I must have access to Y, and I can't get at it. But
often, there is a way to achieve X without direct access to Y.

http://xyproblem.info/

--
Rudy Velthuis http://www.rvelthuis.de

"Twenty years from now you will be more disappointed by the
things that you didn't do than by the ones you did do."
-- Samuel Clemens
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 9:48 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 08.03.2017 um 00:57 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

It is very well possible to produce proper programs without hving to
resort to such practices.

Hm? As far as I've understood the alternative ways to get access to
fix things EMBT has no fix for yet are more brittle. Or am I wrong?

But usually, it is a false sense that you must acess these things to
achieve what you want. It is my experiecne that, most of the time,
there are many other, better ways to achieve what I want without
resorting to hacks.

Often, these are some kind of XY problems. The notion is: I must
achieve X, so I must have access to Y, and I can't get at it. But
often, there is a way to achieve X without direct access to Y.

That may be in some case and may not be in others.
Unless we're discussing real cases (too few have been presented here)
the discussion is moot on both sides!

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 6:16 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 08.03.2017 um 00:57 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

It is very well possible to produce proper programs without hving
to >>> resort to such practices.

Hm? As far as I've understood the alternative ways to get access to
fix things EMBT has no fix for yet are more brittle. Or am I wrong?

But usually, it is a false sense that you must acess these things to
achieve what you want. It is my experiecne that, most of the time,
there are many other, better ways to achieve what I want without
resorting to hacks.

Often, these are some kind of XY problems. The notion is: I must
achieve X, so I must have access to Y, and I can't get at it. But
often, there is a way to achieve X without direct access to Y.

That may be in some case and may not be in others.

Yes. That is why I said "often" and not "always".

--
Rudy Velthuis http://www.rvelthuis.de

"Grasshopper, look beyond the game, as you look beneath the
surface of the pool to see its depths."
-- Master Po
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 5, 2017 3:06 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

Ah yes, they are "pragmatic", in other words, they don't like to be
obstructed if they want to do something they shouldn't.

You don't get to decide what I should or shouldn't do though. Neither does Embarcadero. I always say regarding freedom and decisions: "Those who have to suffer the consequences get to make the decisions". This applies as well to politics or morality as coding. Unless you or Marco are physically looking over my shoulder, able to weigh all the pros and cons of what I'm contemplating, you can't know what I should or shouldn't do in the circumstance I find myself in.

Heck, even the Catholic Church, which claims to speak for an omnipotent being, has a doctrine of primacy of conscience. :-) Your .sig file often contains great quotes from atheist thinkers, but you're sounding a bit Pope-y on this one. ;-)

Regarding obstruction, language design should embrace the concept of "the right thing to do should be the easiest thing to do". Sadly, Delphi was never designed with this in mind (or we wouldn't have needed the "with" statement). You're advocating a bondage and discipline approach to language development.

http://wiki.c2.com/?BondageAndDisciplineLanguage

As the Jargon File puts it,

bondage-and-discipline language: n.
A language (such as Pascal, Ada, APL, or Prolog) that, though ostensibly general-purpose, is designed so as to enforce an author's theory of ‘right programming’ even though said theory is demonstrably inadequate for systems hacking or even vanilla
general-purpose programming. Often abbreviated ‘B&D’; thus, one may speak of things “having the B&D nature”.
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 6, 2017 11:13 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Am 06.03.2017 um 00:06 schrieb Joseph Mitzen:
I always say regarding freedom and decisions: "Those who have to suffer the consequences get to make the decisions".

Issue with your saying is: most of the time the world doesn't work that
way :-(

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 6:29 AM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Mon, 6 Mar 2017 11:13:33 -0800:

Issue with your saying is: most of the time the world doesn't work that
way :-(

In this case it should. If I access a private field and my code
breaks the next time I upgrade the vendor source code, the consequence
is mine, not Embarcadero's. The choice to do it is mine, and nobody
but me pays a price when something changes.

I can just imagine some arrogant component vendor complaining during
beta that his reckless customers can change his precious private
fields (waaa waaa) and they shouldn't be allowed to do that (sniffle).

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dan Barclay

Posts: 701
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 7:42 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
"Markus Humm" wrote on Mon, 6 Mar 2017 11:13:33 -0800:

Issue with your saying is: most of the time the world doesn't work that
way :-(

In this case it should. If I access a private field and my code
breaks the next time I upgrade the vendor source code, the consequence
is mine, not Embarcadero's. The choice to do it is mine, and nobody
but me pays a price when something changes.

I can just imagine some arrogant component vendor complaining during
beta that his reckless customers can change his precious private
fields (waaa waaa) and they shouldn't be allowed to do that (sniffle).

You done broke da code.

Dan
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 9:16 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 07.03.2017 um 15:29 schrieb Brandon Staggs:
"Markus Humm" wrote on Mon, 6 Mar 2017 11:13:33 -0800:

Issue with your saying is: most of the time the world doesn't work that
way :-(

In this case it should. If I access a private field and my code
breaks the next time I upgrade the vendor source code, the consequence
is mine, not Embarcadero's. The choice to do it is mine, and nobody
but me pays a price when something changes.

Issue with this is: there are too many arrogant customers out there who
would bitterly complaining that the vendor is breajking their stuff,
even if it's their issue to deal with such changes.

Thing is: having some things private may help to have a more stable
interface which doesn't change so often since some of the necessary
changes can be done without affecting the users of the class.

Greetings

Markus
Dan Barclay

Posts: 701
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 2:15 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:.

Issue with this is: there are too many arrogant customers out there who
would bitterly complain...

Yea, the arrogance of those darned customers. How dare they...

Dan <anybody spot a free clue? Naaa, I didn't think so.>
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 6:27 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:
Issue with this is: there are too many arrogant customers out there who
would bitterly complaining that the vendor is breajking their stuff,
even if it's their issue to deal with such changes.

I've seen this claim for years, and honestly it's silly.

Let me illustrate:

You release your program for Windows only. It says on the box "For Windows." Someone tries to use it on OS X and it doesn't work. Does anyone actually complain to you that your program doesn't work on OS X and demand you make it work? And if they did, would you? Of course not!

It's no different here. "I dug into your code and found an undocumented class. I tried to use it for something different than intended and it didn't work. I DEMAND YOU FIX IT." Has that ever happened in the history of software development?

On the other hand, the great Barry Kelly once wisely said that since there is no formal language specification, "If it compiles, it's valid Delphi." He then went on to describe being surprised by some of the things that actually compiled. :-) Marco is... well, he's not Barry Kelly. He's thrown this rule out the window more than once and now there's no way to tell what's valid Delphi or not, even if the compiler accepts it. I've seen him insist on the bug tracker, "Well, it should never have compiled in the first place!" That's a bad situation for customers to be in, because in the end anything can change at any time for any reason.

Thing is: having some things private may help to have a more stable
interface which doesn't change so often since some of the necessary
changes can be done without affecting the users of the class.

You don't need to make anything private. You simply don't document what isn't public. You have privacy by convention, not by enforcing it.

In Python, you can't truly make anything private. Privacy is only by naming convention. Raymond Hettinger has described it like this: "Python is a consenting adults language. We don't put locks on the doors. But if you open a door, you have to deal with what's on the other side."
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 9:55 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Am 08.03.2017 um 03:27 schrieb Joseph Mitzen:
Markus Humm wrote:
Issue with this is: there are too many arrogant customers out there who
would bitterly complaining that the vendor is breajking their stuff,
even if it's their issue to deal with such changes.

I've seen this claim for years, and honestly it's silly.

Let me illustrate:

You release your program for Windows only. It says on the box "For Windows." Someone tries to use it on OS X and it doesn't work. Does anyone actually complain to you that your program doesn't work on OS X and demand you make it work? And if they did, would you? Of course not!

It's no different here. "I dug into your code and found an undocumented class. I tried to use it for something different than intended and it didn't work. I DEMAND YOU FIX IT." Has that ever happened in the history of software development?

On the other hand, the great Barry Kelly once wisely said that since there is no formal language specification, "If it compiles, it's valid Delphi." He then went on to describe being surprised by some of the things that actually compiled. :-) Marco is... well, he's not Barry Kelly. He's thrown this rule out the window more than once and now there's no way to tell what's valid Delphi or not, even if the compiler accepts it. I've seen him insist on the bug tracker, "Well, it should never have compiled in th
e first place!" That's a bad situation for customers to be in, because in the end anything can change at any time for any reason.

Thing is: having some things private may help to have a more stable
interface which doesn't change so often since some of the necessary
changes can be done without affecting the users of the class.

You don't need to make anything private. You simply don't document what isn't public. You have privacy by convention, not by enforcing it.

In Python, you can't truly make anything private. Privacy is only by naming convention. Raymond Hettinger has described it like this: "Python is a consenting adults language. We don't put locks on the doors. But if you open a door, you have to deal with what's on the other side."

Be carefull with your arguments:

1. The claim is not so silly as you think as there are just too many
silly customers out there. I know it from the customers of our
products where I often enough provide support.

2. How shall somebody know from an undocumented method what's it really
supposed to do? He might try to look at how it works or is being
used, but this might not be the complete picture and if it indeed
contains a bug it's sometimes questionable whether it's a bug or
a misunderstanding of what the method is supposed to do (according
to its creator)

3. If it compiles it's valid Delphi? Oh dear.
If the compiler should get a bug which emnables me to pass a signed
integer to a function which expects a UInt32 value and it compiles
it became valid Delphi? Hm...
If that's the case EMBT doesn't need to fix this.

4. About not documenting stuff you want to see as private: what kind of
doumentation? WIll you leave out ordinary code comments as well?
That would either mean you don't have that documentation yourself
when you need to change something years later and don't remember
100% how it works or you need proper external documentation
just accessible for you.

I'm not completely conviced yet, even if I think a few more things
should be protected at least.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 19, 2017 6:18 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Markus Humm wrote:
Issue with this is: there are too many arrogant customers out there
who would bitterly complaining that the vendor is breajking their
stuff, even if it's their issue to deal with such changes.

I've seen this claim for years, and honestly it's silly.

Let me illustrate:

You release your program for Windows only. It says on the box "For
Windows." Someone tries to use it on OS X and it doesn't work. Does
anyone actually complain to you that your program doesn't work on OS
X and demand you make it work? And if they did, would you? Of course
not!

It's no different here. "I dug into your code and found an
undocumented class. I tried to use it for something different than
intended and it didn't work. I DEMAND YOU FIX IT." Has that ever
happened in the history of software development?

This time I fully agree. And that is why such classes are made private:
they were not designed for public, general use, they were designed for
one single situation.

One more argument pro private.
--
Rudy Velthuis http://www.rvelthuis.de

"#3 pencils and quadrille pads."
-- Seymoure Cray (1925-1996) when asked what CAD tools he used
to design the Cray I supercomputer; he also recommended using
the back side of the pages so that the lines were not so
dominant.
Joseph Mitzen

Posts: 280
Registered: 6/9/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 6:16 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

In this case it should. If I access a private field and my code
breaks the next time I upgrade the vendor source code, the consequence
is mine, not Embarcadero's. The choice to do it is mine, and nobody
but me pays a price when something changes.

I can just imagine some arrogant component vendor complaining during
beta that his reckless customers can change his precious private
fields (waaa waaa) and they shouldn't be allowed to do that (sniffle).

I've got a real-world example. The popular GIS (Geographical Information System) program ArcGIS uses the old dBase format as its container for its data files. One time I needed to access some old dBase files from a language. I had a library that could process ArcGIS files, which turned out to have internal classes to read dBase. If I attempted to use these internal classes to read a non-ArcGIS dBase file and it didn't work, of course I wasn't going to complain to the author of the ArcGIS library that her internal classes needed to be made more general so I could use them for something completely unrelated. :-) Now on the other hand, why should these classes be private? If they actually could read a generic dBase file, why couldn't I use them for something the author never intended so long as I had legal access to the library? They weren't part of the API, so it was clear that no support would be demanded. A library author can't imagine every possible use their code could be put to for all time under all conditions.

I remember a Stack Overflow question in which the author wanted information on hiding their classes because they were worried that if they didn't, someone might try to use their internal classes to create a different container than they were implementing. Someone wisely asked them, "So what?" If someone found a use for your code you hadn't anticipated, what's the big deal?

Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 8, 2017 9:59 AM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Am 08.03.2017 um 03:16 schrieb Joseph Mitzen:

They weren't part of the API, so it was clear that no support would be demanded.

That's the issue: you might be sensible enough to not demabd support for
such stuff, but quite a lot customers would simply try to get support
anyway and thus cost the time and money of the vendor.

I know our customers well enough. They even once demanded I change my
application to suit ther use case in a way which would have brokent the
protocol to be used. Customer didn't understand this (was in time
pressure) and later on it turned out that some other equipment had a
different issue which caused his problems and where I could help him
getting that other equipment which was not ours to work with my
software. I was quite angry on that person because she tried to use
something untested in a production scenario and I had to try to give
support, but I couldn't help it... And in the end it worked.

Greetings

Markus
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 6:16 PM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

I've got a real-world example. The popular GIS (Geographical
Information System) program ArcGIS uses the old dBase format as its
container for its data files. One time I needed to access some old
dBase files from a language. I had a library that could process
ArcGIS files, which turned out to have internal classes to read
dBase. If I attempted to use these internal classes to read a
non-ArcGIS dBase file and it didn't work, of course I wasn't going to
complain to the author of the ArcGIS library that her internal
classes needed to be made more general so I could use them for
something completely unrelated. :-) Now on the other hand, why should
these classes be private?

Because they may not have been usable outside the context of for other
purposes than the specific ones for which they were designed. If the
program is only meant to read ArcGIS files, these classes probably cut
corners and are not fit for general use to read any kind of dBase.
E.g., chances are they do not check any errors, because the author of
the public classes knows how to always feed them with valid data and
provide the necessary preconditions. And perhaps they are only able to
read a subset of the types a proper dBase accessing class should
provide. Etc.

One reason not to publish classes is that they are not meant, nor are
fit for general purpose public consumption. They only do what they must
do for their specific purpose.

Sheesh. This is not rocket science, is it? Does it really take a
dentist to tell you this?

--
Rudy Velthuis http://www.rvelthuis.de

"I have always wished that my computer would be as easy to use
as my telephone. My wish has come true. I no longer know how
to use my telephone." -- Bjarne Stroustrup
Quentin Correll


Posts: 2,118
Registered: 12/1/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 12, 2017 11:52 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy,

| Does it really take a dentist to tell you this?

<giggling OL>

--

Q -- XanaNews 1.19.1.372 - 2017-03-12 11:53:16
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 6:06 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Markus Humm" wrote on Mon, 6 Mar 2017 11:13:33 -0800:

Issue with your saying is: most of the time the world doesn't work
that way :-(

In this case it should. If I access a private field and my code
breaks the next time I upgrade the vendor source code, the consequence
is mine, not Embarcadero's. The choice to do it is mine, and nobody
but me pays a price when something changes.

I can just imagine some arrogant component vendor complaining during
beta that his reckless customers can change his precious private
fields (waaa waaa) and they shouldn't be allowed to do that (sniffle).

Arrogant? No, not at all, the vendor is being responsible and careful.

If you meddle with the internals of my carefully crafted classes (even
without any direct access from code, you could always make a copy of
the source code and make everything public, right?), don't ask for help
(from *anyone*), because no one will be able to help you. And chances
are great you introduce bugs. Your problem.

--
Rudy Velthuis http://www.rvelthuis.de

"If we knew what it was we were doing, it would not be called
research, would it?" -- Albert Einstein
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 3:39 PM   in response to: Joseph Mitzen in response to: Joseph Mitzen
Joseph Mitzen wrote:

Rudy Velthuis (TeamB) wrote:

Ah yes, they are "pragmatic", in other words, they don't like to be
obstructed if they want to do something they shouldn't.

You don't get to decide what I should or shouldn't do though.

I get to decide which parts of my class you can easily access and which
you can't. <g>

--
Rudy Velthuis http://www.rvelthuis.de

"Some cause happiness wherever they go; others, whenever
they go." -- Oscar Wilde
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 7, 2017 5:53 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Tue, 7 Mar 2017 15:39:11 -0800:

I get to decide which parts of my class you can easily access and which
you can't. <g>

Nonsense. Nobody will use your code if they can't get the source for
it. That is the ultimate in information availability.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Rudy Velthuis (...


Posts: 6,446
Registered: 9/22/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 11, 2017 7:57 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:

"Rudy Velthuis" wrote on Tue, 7 Mar 2017 15:39:11 -0800:

I get to decide which parts of my class you can easily access and
which you can't. <g>

Nonsense. Nobody will use your code if they can't get the source for
it. That is the ultimate in information availability.

All my apps and classes come in source code form ONLY. But having the
source code doesn't mean you can easily access (from code) the members
of my classes without meddling with the source code. But you can do the
same with the Delphi-provided classes, right? That was not the issue
here.

--
Rudy Velthuis http://www.rvelthuis.de

"One man's magic is another man's engineering. Supernatural is
a null word."
-- Robert Heinlein
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 13, 2017 6:07 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
"Rudy Velthuis" wrote on Sat, 11 Mar 2017 07:57:17 -0800:

But you can do the
same with the Delphi-provided classes, right? That was not the issue
here.

What you don't seem to understand is that there are bugs in the VCL
that need fixing and whether those bugs are limited to a few months
between releases or several years of neglect, some of us need to
actually correct the problems immediately to finish projects. Before
class helpers, this was typically done with local copies (forks) of
the source code, if making an inherited version wasn't an option. That
is probably the absolute worst way to have to work with it. After
class helpers came, and Marco wrote in his book about how they could
be used to access private fields, that methodology changed for many of
us, and we could handle changes to the VCL in a much more robust
manner. This was a problem for NO ONE. Instead of fixing the broken
structural syntax highlighting in the IDE, or one of the other
hundreds of open bugs in QA, they decided to "plug a hole" that harmed
nobody except OOP purists and their ideology, taking away a useful
tool from developers instead of fixing actual problems for them. The
owners of Delphi have squandered so much trust over the last several
years. You have no idea the real-world implications of such arrogance
and the dissatisfaction it breeds with the tool among those who once
supported it. You have no clue.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 13, 2017 3:21 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 13.03.2017 um 14:07 schrieb Brandon Staggs:
"Rudy Velthuis" wrote on Sat, 11 Mar 2017 07:57:17 -0800:

But you can do the
same with the Delphi-provided classes, right? That was not the issue
here.

What you don't seem to understand is that there are bugs in the VCL
that need fixing and whether those bugs are limited to a few months
between releases or several years of neglect, some of us need to
actually correct the problems immediately to finish projects. Before
class helpers, this was typically done with local copies (forks) of
the source code, if making an inherited version wasn't an option. That
is probably the absolute worst way to have to work with it. After
class helpers came, and Marco wrote in his book about how they could
be used to access private fields, that methodology changed for many of
us, and we could handle changes to the VCL in a much more robust
manner. This was a problem for NO ONE. Instead of fixing the broken
structural syntax highlighting in the IDE, or one of the other
hundreds of open bugs in QA, they decided to "plug a hole" that harmed
nobody except OOP purists and their ideology, taking away a useful
tool from developers instead of fixing actual problems for them. The
owners of Delphi have squandered so much trust over the last several
years. You have no idea the real-world implications of such arrogance
and the dissatisfaction it breeds with the tool among those who once
supported it. You have no clue.

Hello,

without listing the exact bugs they will always claim that those you are
referring to 8but didn't list) can be fixed with other techniques as
well. If this discussion should not run in circles, you need provide
some real cases.

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 15, 2017 5:05 PM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Mon, 13 Mar 2017 15:21:07 -0700:

without listing the exact bugs they will always claim that those you are
referring to 8but didn't list) can be fixed with other techniques as
well. If this discussion should not run in circles, you need provide
some real cases.

THAT HAS BEEN DONE ALREADY. And you can look at QA reports or Stack
Overflow threads. I have a bug report on QA that resorts to detours
as a workaround, and that is not elegant -- should they plug the holes
that let detours work!? That isn't even the issue. Of course you can
always do it some other way, like copying the VCL source code to your
project's source path. That hardly means it is bad to be able to use
a robust and elegant thing like class helpers.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Markus Humm

Posts: 4,333
Registered: 11/9/03
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 16, 2017 10:15 AM   in response to: Brandon Staggs in response to: Brandon Staggs
Am 16.03.2017 um 01:05 schrieb Brandon Staggs:
"Markus Humm" wrote on Mon, 13 Mar 2017 15:21:07 -0700:

without listing the exact bugs they will always claim that those you are
referring to 8but didn't list) can be fixed with other techniques as
well. If this discussion should not run in circles, you need provide
some real cases.

THAT HAS BEEN DONE ALREADY. And you can look at QA reports or Stack
Overflow threads. I have a bug report on QA that resorts to detours
as a workaround, and that is not elegant -- should they plug the holes
that let detours work!? That isn't even the issue. Of course you can
always do it some other way, like copying the VCL source code to your
project's source path. That hardly means it is bad to be able to use
a robust and elegant thing like class helpers.

Hello,

issue is: the folks disputing that these issues are severe etc. always
want to see concrete cases and they will not bother to look out for
those on their own. They want to be able to have a list of issues where
they do not need to search for first.

Greetings

Markus
Brandon Staggs

Posts: 500
Registered: 3/3/01
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 17, 2017 9:20 AM   in response to: Markus Humm in response to: Markus Humm
"Markus Humm" wrote on Thu, 16 Mar 2017 10:15:22 -0700:

issue is: the folks disputing that these issues are severe etc. always
want to see concrete cases and they will not bother to look out for
those on their own. They want to be able to have a list of issues where
they do not need to search for first.

Apparently the links to QA items that have been provided here are not
enough. Besides, they will just say "there are other ways" and of
course there always are. That isn't the issue and never has been.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Alexandre Machado

Posts: 1,433
Registered: 8/10/13
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 13, 2017 6:35 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Instead of fixing the broken
structural syntax highlighting in the IDE, or one of the other
hundreds of open bugs in QA, they decided to "plug a hole" that harmed
nobody except OOP purists and their ideology, taking away a useful
tool from developers instead of fixing actual problems for them. The
owners of Delphi have squandered so much trust over the last several
years. You have no idea the real-world implications of such arrogance
and the dissatisfaction it breeds with the tool among those who once
supported it. You have no clue.

EXACTLY!!!!

Want another example?
They have been refactoring the whole RTL for years now, replacing the good old TList with, guess what, the bloated generics version!
In my dictionary this is called: How to spend your precious - and scarces - resources doing something that will bring no benefit and will piss off the only few remaining loyal customers that your product still have.
And they keep neglecting it.
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 14, 2017 2:53 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:
Instead of fixing the broken
structural syntax highlighting in the IDE, or one of the other
hundreds of open bugs in QA, they decided to "plug a hole" that harmed
nobody except OOP purists and their ideology, taking away a useful
tool from developers instead of fixing actual problems for them. The
owners of Delphi have squandered so much trust over the last several
years. You have no idea the real-world implications of such arrogance
and the dissatisfaction it breeds with the tool among those who once
supported it. You have no clue.

EXACTLY!!!!

Want another example?
They have been refactoring the whole RTL for years now, replacing the good old TList with, guess what, the bloated generics version!
In my dictionary this is called: How to spend your precious - and scarces - resources doing something that will bring no benefit and will piss off the only few remaining loyal customers that your product still have.
And they keep neglecting it.

TList does not work under ARC, since RTL has to work under ARC, of
course they replaced it with existing collections that do.

Bloat is completely different issue.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Alexandre Machado

Posts: 1,433
Registered: 8/10/13
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 14, 2017 1:16 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
TList does not work under ARC, since RTL has to work under ARC, of
course they replaced it with existing collections that do.

They could have introduced a TList<TObject> descendant and use it with ARC code and keep Windows code using the classic TList. It was simple to do actually. But of course, they will push the burden to the user.

Bloat is completely different issue.

Different, but direct consequence.

TComponent in Delphi 10 Berlin consumes 96 bytes more than a XE2 one, just because of this "replacement". Probably the whole instance size has grown much beyond this. I'm just talking about the TList replacement.
Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 15, 2017 8:10 AM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre Machado wrote:
TList does not work under ARC, since RTL has to work under ARC, of
course they replaced it with existing collections that do.

They could have introduced a TList<TObject> descendant and use it with ARC code and keep Windows code using the classic TList. It was simple to do actually. But of course, they will push the burden to the user.

I have no idea what are you talking about. They are using TList<T> for
components. Having different code for Windows side would be horror
to maintain.

Bloat is completely different issue.

Different, but direct consequence.

TComponent in Delphi 10 Berlin consumes 96 bytes more than a XE2 one, just because of this "replacement". Probably the whole instance size has grown much beyond this. I'm just talking about the TList replacement.

How many components does one use? While I am all for
having optimized core libraries, you are exaggerating the
problems.

Well, TComponent and TControl sizes also grew since Delphi 7.
That is called introducing new features people need and use.

Also TComponent does not create lists it does not use, so
leaf nodes occupy only pointer size.

TList<T> instance size grew gradually, there was certainly
less difference between XE2 one and XE4 one.

You make it sound like people at Embarcadero had nothing
better to do than introducing "bad" classes just to mess up
with their customers.

Recent size increase in TList<T> instance is result of trying to
reduce generic code bloat in exe size, because customers were
complaining... So they do listen...

"Road to hell is paved with good intentions" I guess this is one
of those times when good intentions don't always yield completely
satisfying results.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
wenjie zhou

Posts: 366
Registered: 6/28/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 15, 2017 8:21 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
So, The bloated TList<T> and all class used TList<T> proved that "ARC is evil " again .
Just ARC lead so many performance, size problem.But the benifit for ARC is seldom.
Lajos Juhasz

Posts: 587
Registered: 3/14/14
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 15, 2017 8:47 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

So, The bloated TList<T> and all class used TList<T> proved that "ARC
is evil " again . Just ARC lead so many performance, size
problem.But the benifit for ARC is seldom.

You should really explain why is TLIST<T> so evil.
wenjie zhou

Posts: 366
Registered: 6/28/02
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 15, 2017 8:16 PM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:
wenjie zhou wrote:

So, The bloated TList<T> and all class used TList<T> proved that "ARC
is evil " again . Just ARC lead so many performance, size
problem.But the benifit for ARC is seldom.

You should really explain why is TLIST<T> so evil.

It based on logical relations for what Dalija Prasnikar says.

"Recent size increase in TList<T> instance is result of trying to
reduce generic code bloat in exe size, because customers were
complaining"

And replace TList in classes.pas with TList<T> just because ARC. Otherwise, I just can't figure out what it means for such replacing.
In my opinion,such replacing lead bloated and slow but no any benifiy for customers.

In another word, ARC lead such bad change.
Lajos Juhasz

Posts: 587
Registered: 3/14/14
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 16, 2017 4:20 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Lajos Juhasz wrote:
wenjie zhou wrote:

So, The bloated TList<T> and all class used TList<T> proved that
"ARC is evil " again . Just ARC lead so many performance, size
problem.But the benifit for ARC is seldom.

You should really explain why is TLIST<T> so evil.

It based on logical relations for what Dalija Prasnikar says.

"Recent size increase in TList<T> instance is result of trying to
reduce generic code bloat in exe size, because customers were
complaining"

And replace TList in classes.pas with TList<T> just because ARC.
Otherwise, I just can't figure out what it means for such replacing.
In my opinion,such replacing lead bloated and slow but no any benifiy
for customers.

In another word, ARC lead such bad change.

No it's not just ARC. TList is a generic list for a list of pointers.
It was missused by the RTL for a long time. It does makes sense to use
a proper list when it's available.

You should learn by now for any language if you're for memory
efficiency you should never use objects. Objects are never the most
efficient solution. For those structures records are a better choice.

PS. I wonder whenever they could redouce the exe size by using a type
TComponentList = class(TList<Tcomponent>) or not.

Dalija Prasnikar

Posts: 2,078
Registered: 11/9/99
Re: Rant: Class Helpers Neutered
Click to report abuse...   Click to reply to this thread Reply
  Posted: Mar 16, 2017 7:05 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:

PS. I wonder whenever they could redouce the exe size by using a type
TComponentList = class(TList<Tcomponent>) or not.

No.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar