Re: [fpc-pascal] Enum scope
On Fri, Feb 28, 2014 at 4:44 PM, Marcos Douglas m...@delfire.net wrote:
On Fri, Feb 28, 2014 at 4:22 PM, Sven Barth pascaldra...@googlemail.com
wrote:
On 28.02.2014 19:59, Marcos Douglas wrote:
On Fri, Feb 28, 2014 at 3:47 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 28 Feb 2014 15:29:03 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
These properties are defined in Process unit. My class is in myprocess
unit
(or something like that).
The problem is: I can not use the enums values because they don't exists
in
my unit (myprocess) but if these enums were defined inside TProcess
class
(public type), I can use them without problem.
So, what do you think about it?
Enums are always public and global.
For example:
TMyClass = class
private
type
MyEnums = (enum1, enum2);
public
e: MyEnums;
end;
enum1 can be used in other units.
But that's what I'm talking about! :)
So if the TProcessOptions, TProcessPriority and TStartupOptions was
declared as a type inside TProcess I do not needed to import (uses)
two units (follow the example: process and myprocess) in a third unit.
I propose migrate these enums from units to be member of classes.
Sidenote: What you propose would work only if {$scopedenums on} is used in
the unit which defines the enums and in that case you'd have the problem
with backwards compatibility.
Do not need {$scopedenums on}.
See example bellow. Unit1 uses Unit2 and this uses Unit3.
The problem with backwards compatibility could be resolved using {$IFDEF}
IMHO.
I do not know if that was clear.
The big problem is the dependence of the third unit to use,
necessarily, another unit (in this case, Unit3). The correct way would
be to use only Unit2 (encapsulation).
Do you agree?
Regards,
Marcos Douglas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Enum scope
Hi, The FPC stable version allow to declare a new type, as private/protected/public, inside a class. So, I propose migrate enums to your own classes... why? Well, I have my own TProcess so TMyProcess inherit from TProcess. Perfectly. But I need to use some properties like: Property Options : TProcessOptions Property Priority : TProcessPriority Property StartupOptions : TStartupOptions These properties are defined in Process unit. My class is in myprocess unit (or something like that). The problem is: I can not use the enums values because they don't exists in my unit (myprocess) but if these enums were defined inside TProcess class (public type), I can use them without problem. So, what do you think about it? Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum scope
On Fri, 28 Feb 2014 15:29:03 -0300 Marcos Douglas m...@delfire.net wrote: [...] These properties are defined in Process unit. My class is in myprocess unit (or something like that). The problem is: I can not use the enums values because they don't exists in my unit (myprocess) but if these enums were defined inside TProcess class (public type), I can use them without problem. So, what do you think about it? Enums are always public and global. For example: TMyClass = class private type MyEnums = (enum1, enum2); public e: MyEnums; end; enum1 can be used in other units. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum scope
On 28.02.2014 19:59, Marcos Douglas wrote:
On Fri, Feb 28, 2014 at 3:47 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 28 Feb 2014 15:29:03 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
These properties are defined in Process unit. My class is in myprocess unit
(or something like that).
The problem is: I can not use the enums values because they don't exists in
my unit (myprocess) but if these enums were defined inside TProcess class
(public type), I can use them without problem.
So, what do you think about it?
Enums are always public and global.
For example:
TMyClass = class
private
type
MyEnums = (enum1, enum2);
public
e: MyEnums;
end;
enum1 can be used in other units.
But that's what I'm talking about! :)
So if the TProcessOptions, TProcessPriority and TStartupOptions was
declared as a type inside TProcess I do not needed to import (uses)
two units (follow the example: process and myprocess) in a third unit.
I propose migrate these enums from units to be member of classes.
Sidenote: What you propose would work only if {$scopedenums on} is used
in the unit which defines the enums and in that case you'd have the
problem with backwards compatibility.
Regards,
Sven
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Enum scope
On Fri, Feb 28, 2014 at 4:22 PM, Sven Barth pascaldra...@googlemail.com wrote:
On 28.02.2014 19:59, Marcos Douglas wrote:
On Fri, Feb 28, 2014 at 3:47 PM, Mattias Gaertner
nc-gaert...@netcologne.de wrote:
On Fri, 28 Feb 2014 15:29:03 -0300
Marcos Douglas m...@delfire.net wrote:
[...]
These properties are defined in Process unit. My class is in myprocess
unit
(or something like that).
The problem is: I can not use the enums values because they don't exists
in
my unit (myprocess) but if these enums were defined inside TProcess
class
(public type), I can use them without problem.
So, what do you think about it?
Enums are always public and global.
For example:
TMyClass = class
private
type
MyEnums = (enum1, enum2);
public
e: MyEnums;
end;
enum1 can be used in other units.
But that's what I'm talking about! :)
So if the TProcessOptions, TProcessPriority and TStartupOptions was
declared as a type inside TProcess I do not needed to import (uses)
two units (follow the example: process and myprocess) in a third unit.
I propose migrate these enums from units to be member of classes.
Sidenote: What you propose would work only if {$scopedenums on} is used in
the unit which defines the enums and in that case you'd have the problem
with backwards compatibility.
Do not need {$scopedenums on}.
See example bellow. Unit1 uses Unit2 and this uses Unit3.
The problem with backwards compatibility could be resolved using {$IFDEF} IMHO.
Regards,
Marcos Douglas
=== BEGIN ===
unit Unit3;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils;
type
TFoo = class
public type
TEnum = (fooA, fooB, fooC);
public
FValue: TEnum;
end;
implementation
end.
unit Unit2;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Unit3;
type
TNewFoo = class(TFoo)
end;
implementation
end.
unit Unit1;
{$mode objfpc}{$H+}
interface
uses
Classes, SysUtils, Forms, StdCtrls,
Unit2;
type
TForm1 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
public
{ public declarations }
end;
var
Form1: TForm1;
implementation
{$R *.lfm}
{ TForm1 }
procedure TForm1.Button1Click(Sender: TObject);
var
F: TNewFoo;
begin
F := TNewFoo.Create;
try
F.FValue := TNewFoo.TEnum.fooA;
finally
F.Free;
end;
end;
end.
===END===
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
