On Tuesday 03 October 2006 16:26, Flávio Etrusco wrote:
At my workplace we've standardized on using three scope prefixes:
p_ for function parameter, m_ for members/fields, and g_ for global.
I know that discussion, I lost it at work already, but apart from C
where every identifier is sort of
On Tue, Oct 03, 2006 at 07:36:11AM +, Vinzent Hoefler wrote:
On Monday 02 October 2006 17:16, Micha Nelissen wrote:
Ok, so enforcing different names is good then, that makes code more
context insensitive, since identifiers won't suddenly resolve to
parameters with the same name.
No,
There's a reason, I always write self.Identifier and I also refuse to
revert back to the so called Hungarian notation (like AParameter). Even
if there is *no* parameter and/or field with that name it's always
clear which part is meant.
This is not Hungarian notation. Hungarian is to prefix
C'est magnifique, mais ce n'est pas la guerre.
Two Very Bad Things:
* The restriction increases the context sensitivity of the language.
* The restriction increases the number of incompatibilities with Delphi
and therefore increases the difficulty of porting existing programs.
The restriction
Chris Cheney schreef:
C'est magnifique, mais ce n'est pas la guerre.
Two Very Bad Things:
* The restriction increases the context sensitivity of the language.
What do you mean? It thought it reduces the context sensitivity, because the context
is less important to determine what a
On Monday 02 October 2006 10:40, Vincent Snijders wrote:
Chris Cheney schreef:
C'est magnifique, mais ce n'est pas la guerre.
Two Very Bad Things:
* The restriction increases the context sensitivity of the language.
What do you mean? It thought it reduces the context
Having same function names as parameter names per se isn't a biggy but
the biggest problem is:
TFirst = class
protected
FFirst: Integer;
public
property First: Integer read FFirst write FFirst;
end;
TTest = class(TFirst)
FSomething: Integer;
public
procedure DoWithFirst(a, First:
On Monday 02 October 2006 11:46, Ales Katona wrote:
Having same function names as parameter names per se isn't a biggy but
the biggest problem is:
TFirst = class
protected
FFirst: Integer;
public
property First: Integer read FFirst write FFirst;
end;
TTest = class(TFirst)
On Thursday 28 September 2006 10.54, Chris Cheney wrote:
The restriction could be subject to a configurable option (perhaps it is
already) but, without a configurable option, the restriction should be
omitted. If the language is changed to suit the whims of the developers,
it might end up as
Ales, there is _no_ confusion here.
Oh believe me there is. Especialy if you're writing just some little
overriden method in a class which doesn't even have property visible
anymore. You don't think about it and bang, error and a very neatly
hidden one at that.
It's not that I don't know what
Here's the better example:
TTest = class
protected
FField: Integer;
public
procedure Helper(Field: Integer);
property Field: Integer read FField write FField;
end;
{ TTest }
procedure TTest.Helper(Field: Integer);
begin
with Self do
Field:=Field;
Christian Iversen wrote:
On Monday 02 October 2006 10:40, Vincent Snijders wrote:
* The restriction increases the number of incompatibilities with Delphi
and therefore increases the difficulty of porting existing programs.
For porting Delphi programs, compile the unit with -Sd.
That's true,
Chris Cheney wrote:
I'm pretty sure he means that no can no longer, for example, copy a function
from one class to another, without risking having to rewrite all the
parameter names.
You have understood me correctly - I would have expressed it a little
differently, but not as succinctly.
On Monday 02 October 2006 19:20, Micha Nelissen wrote:
Christian Iversen wrote:
procedure TTest.DoWithFirst(a, First: Integer);
begin
First:=a; // ???
FSomething:=First; // ???
end;
Ales, there is _no_ confusion here. Normal scope rules ensures that the
first line only assigns
On Wednesday 27 September 2006 20:50, ik wrote:
Let me give you an example of a real bug that allow attackers to gain
root access using X-server, and I hope you will understand why such
checking can be a good thing.
It *can*. But as usual the pros and cons should be weighted properly.
On Wed, 27 Sep 2006, Christian Iversen wrote:
Hi all.
I was hoping there could be a discussion of a certain feature in FPC, which
doesn't work very well for us. Ultimately, I would like to see it gone
completely. It's a very small extra-strong syntax check, appearantly
implemented
Christian Iversen wrote:
rare, however - and you have to be careful anyway, because this restriction
is not consistent:
var
wait: boolean;
procedure tfoo.ReadStuff(buffer: tbuffer; wait: boolean);
begin
// In here, wait could refer either to the parameter, or the global var.
Hi all.
I was hoping there could be a discussion of a certain feature in FPC, which
doesn't work very well for us. Ultimately, I would like to see it gone
completely. It's a very small extra-strong syntax check, appearantly
implemented to avoid bad code. However, it's not entirely obvious why
Am Mittwoch, 27. September 2006 22:36 schrieb Christian Iversen:
Hi all.
I was hoping there could be a discussion of a certain feature in FPC,
which doesn't work very well for us. Ultimately, I would like to see
it gone completely. It's a very small extra-strong syntax check,
appearantly
Hi,
Let me give you an example of a real bug that allow attackers to gain
root access using X-server, and I hope you will understand why such
checking can be a good thing.
On C you can have a function and a variable with the same name, and
the only way that you can make a difference, is to use
20 matches
Mail list logo
