Re: [fpc-pascal] WHY compiler should be public?
On Sun, 27 Oct 2013, Xiangrong Fang wrote:
2013/10/25 Michael Van Canneyt
Why not simply make it a procedure that is called by ver-2 and ver-3.
If it cannot be called directly from external code, and will called only from
inside a visible consructor, there is simply no reason to make this procedure a
constructor. A simple procedure will do.
Because I don't know how to make it non-constructor. See the following code:
1 unit wtree;
2 {$mode objfpc}{$H+}
3 interface
4 uses tree;
5 type
6 TQWordTree = specialize TTree;
7 TWTree = class(TQWordTree)
8 private
9 FModel: string;
10 public
11 property Model: string read FModel;
12 constructor Create(AData: QWord; AParent: TWTree; AModel: string);
13 constructor Create(HeadNode, TailNode: QWord);
14 end;
15 implementation
16
17 constructor TWTree.Create(AData: QWord; AParent: TWTree; AModel: string);
18 begin
19 inherited Create(AData, AParent);
20 FModel := AModel;
21 end;
22
23 constructor TWTree.Create(HeadNode, TailNode: QWord);
24 begin
25 inherited Create(0, nil);
26 Data := HeadNode;
27 with TWTree do Create(TailNode, Create(HeadNode, Self, 'h'), 't');
28 FModel := 'R';
29 end;
30
31 end.
Please tell me how to deal with line 27, which called the should-be-private
constructor.
Ah. The 'private' constructor is called FROM ANOTHER INSTANCE. You didn't say
that.
That currently can't be done.
Michael.
BTW, this code uses TTree class, which is here:
https://github.com/xrfang/fpcollection/blob/master/src/units/tree.pas
Also,
I don't understand why this does not work:
f := TFileStream.Create;
I know that TFileStream's Create require a file name parameter, but as
TFileStream is inherited from TObject, which has a Create without parameter.
This is why I feel that it is possible to HIDE a public
constructor from ancestor.
I think this is a bug :)
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WHY compiler should be public?
Am 27.10.2013 12:18 schrieb "Michael Van Canneyt" : >> Also, >> I don't understand why this does not work: >> >> f := TFileStream.Create; >> >> I know that TFileStream's Create require a file name parameter, but as TFileStream is inherited from TObject, which has a Create without parameter. This is why I feel that it is possible to HIDE a public >> constructor from ancestor. > > > I think this is a bug :) No, I don't think so. If you want users to use the original constructor as well you'd need to declare yours as "overload". If it would be possible to call TFileStream.Create without parameters then the instance would be in an inconsistent state, so only calling the constructor with arguments should be possible (which is the case for TFileStream. So this is definitely by design. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WHY compiler should be public?
Am 27.10.2013 02:12 schrieb "Xiangrong Fang" : > Also, > > I don't understand why this does not work: > > f := TFileStream.Create; > > I know that TFileStream's Create require a file name parameter, but as TFileStream is inherited from TObject, which has a Create without parameter. This is why I feel that it is possible to HIDE a public constructor from ancestor. Yes, it's possible to hide a public constructor (or any method for that matter), but it's not possible to decrease the visibility of a constructor (or any method for that.matter). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
In our previous episode, Fabr?cio Srdic said: > > used in Java and .NET as either languages don't have "units". > > Adding "features" just because "enterpise-class dev platforms" have them > > is more marketing move, than actual technical need. > > > > We can't nest units to form a hierarchical content. With namespaces, we > can. Yes. But that doesn't need renaming all existing units. It is that part that I think that is excessive. Embarcadero did it probably to keep their hands free for some long term VCL phase-out (IOW that they wouldn't have to rename FM to avoid VCL names). We don't have any major such problems, and thus renaming everything is a bit draconical to me. At least till we really have a reason to do so. > Furthermore, namespaces can be used to disambiguate identifiers with > the same name, eliminating the need to prefix our identifiers. That is the main reason why it is added to so many languages; BUT, Unit based Pascal never had that problem, since units already have their own namespace. Namespaces are only for pseudo hierarchical disambiguation of unit names in Pascal. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
2013/10/27 Marco van de Voort > In our previous episode, Fabr?cio Srdic said: > > > used in Java and .NET as either languages don't have "units". > > > Adding "features" just because "enterpise-class dev platforms" have > them > > > is more marketing move, than actual technical need. > > > > > > > We can't nest units to form a hierarchical content. With namespaces, we > > can. > > Yes. But that doesn't need renaming all existing units. It is that part > that > I think that is excessive. > > Embarcadero did it probably to keep their hands free for some long term VCL > phase-out (IOW that they wouldn't have to rename FM to avoid VCL names). > > We don't have any major such problems, and thus renaming everything is a > bit > draconical to me. At least till we really have a reason to do so. > > > Furthermore, namespaces can be used to disambiguate identifiers with > > the same name, eliminating the need to prefix our identifiers. > > That is the main reason why it is added to so many languages; > > BUT, Unit based Pascal never had that problem, since units already have > their own namespace. > > Namespaces are only for pseudo hierarchical disambiguation of unit names in > Pascal. > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > In my opinion, the change of the fpc's base units to use namespaces is a positive change. The side effect is that requires adjustment of the existing codebase. I believe there are some approaches to address this problem, if the fpc dev team decide to namespace base units. Maybe, unit aliasing can be used. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] WHY compiler should be public?
2013/10/27 Michael Van Canneyt > > > Ah. The 'private' constructor is called FROM ANOTHER INSTANCE. You didn't > say that. > > That currently can't be done. > > Michael. So, in this case, can/should I make my constructor private, ignoring the warning, or just make it public to "play it safe"? Regards, Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
On Sun, Oct 27, 2013 at 11:13 AM, Marco van de Voort wrote: > In our previous episode, Fabr?cio Srdic said: >> > used in Java and .NET as either languages don't have "units". >> > Adding "features" just because "enterpise-class dev platforms" have them >> > is more marketing move, than actual technical need. >> > >> >> We can't nest units to form a hierarchical content. With namespaces, we >> can. > > Yes. But that doesn't need renaming all existing units. It is that part that > I think that is excessive. > > Embarcadero did it probably to keep their hands free for some long term VCL > phase-out (IOW that they wouldn't have to rename FM to avoid VCL names). > > We don't have any major such problems, and thus renaming everything is a bit > draconical to me. At least till we really have a reason to do so. > >> Furthermore, namespaces can be used to disambiguate identifiers with >> the same name, eliminating the need to prefix our identifiers. > > That is the main reason why it is added to so many languages; > > BUT, Unit based Pascal never had that problem, since units already have > their own namespace. > > Namespaces are only for pseudo hierarchical disambiguation of unit names in > Pascal. Very true. I agree with everything. BUT, IMHO, the only problem is if you have two 3rd frameworks that use the same unit name. In that case I can not add 2 units with the same name in my project. So, only in that case, we could use 'namespaces' to 'rename' these units only for use in our projects without change the original source. Best regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
In our previous episode, Marcos Douglas said: > > Namespaces are only for pseudo hierarchical disambiguation of unit names in > > Pascal. > > Very true. I agree with everything. > BUT, IMHO, the only problem is if you have two 3rd frameworks that use > the same unit name. In that case I can not add 2 units with the same > name in my project. So, only in that case, we could use 'namespaces' > to 'rename' these units only for use in our projects without change > the original source. In theory yes, in practice no, since that would be incompatible with anything below XE2+ (and most commercial component builders still support D7). As with any feature, there are people that already design it in after the first beta, but it will be rare, very rare, in the wild. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
2013/10/27 Marco van de Voort > In our previous episode, Marcos Douglas said: > > > Namespaces are only for pseudo hierarchical disambiguation of unit > names in > > > Pascal. > > > > Very true. I agree with everything. > > BUT, IMHO, the only problem is if you have two 3rd frameworks that use > > the same unit name. In that case I can not add 2 units with the same > > name in my project. So, only in that case, we could use 'namespaces' > > to 'rename' these units only for use in our projects without change > > the original source. > > In theory yes, in practice no, since that would be incompatible with > anything below XE2+ (and most commercial component builders still support > D7). > > As with any feature, there are people that already design it in after the > first beta, but it will be rare, very rare, in the wild. > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > Namespace address this problem, but as the Marco said, not to anything below XE2. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
On Sun, Oct 27, 2013 at 11:59 AM, Marco van de Voort wrote: > In our previous episode, Marcos Douglas said: >> > Namespaces are only for pseudo hierarchical disambiguation of unit names in >> > Pascal. >> >> Very true. I agree with everything. >> BUT, IMHO, the only problem is if you have two 3rd frameworks that use >> the same unit name. In that case I can not add 2 units with the same >> name in my project. So, only in that case, we could use 'namespaces' >> to 'rename' these units only for use in our projects without change >> the original source. > > In theory yes, in practice no, since that would be incompatible with > anything below XE2+ (and most commercial component builders still support > D7). Yes and how I still use D7 at work I still have this problem. This problem happen not only for unit names but component names too. I can not register two components with the same name. So, because that, programmers around the world use prefix in class names. If the components were registered using 'unit+class_name' and when we drop a component on the Form the IDE write the unit name as a prefix, this problem not will happen. My more fresh example is: I have, for years, many units that have the prefix 'M'. So I have MClasses, MCore, MTasks, MSystem, etc. Now MSEgui (by Martin Schreiber) introduced a mclasses unit -- your own implementation of classes unit -- and I can not use both units in the same project. :( > As with any feature, there are people that already design it in after the > first beta, but it will be rare, very rare, in the wild. Sorry, I didn't understand what you mean. :( Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
On Sun, Oct 27, 2013 at 12:04 PM, Fabrício Srdic wrote: > 2013/10/27 Marco van de Voort >> >> In our previous episode, Marcos Douglas said: >> > > Namespaces are only for pseudo hierarchical disambiguation of unit >> > > names in >> > > Pascal. >> > >> > Very true. I agree with everything. >> > BUT, IMHO, the only problem is if you have two 3rd frameworks that use >> > the same unit name. In that case I can not add 2 units with the same >> > name in my project. So, only in that case, we could use 'namespaces' >> > to 'rename' these units only for use in our projects without change >> > the original source. >> >> In theory yes, in practice no, since that would be incompatible with >> anything below XE2+ (and most commercial component builders still support >> D7). >> >> As with any feature, there are people that already design it in after the >> first beta, but it will be rare, very rare, in the wild. >> ___ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/mailman/listinfo/fpc-pascal > > > Namespace address this problem, but as the Marco said, not to anything below > XE2. As Dmitry Boyarintsev wrote -- as Marco said before: Adding "features" just because "enterpise-class dev platforms" have them is more marketing move, than actual technical need. Pascal do not need 'namespaces' like Java or .NET have. Units are namespaces. Point. But I think, IMHO, that missing something to the design be perfect: "rename unit virtually" We already had many discussions about it on this list, but nothing is good enough and/or nobody have time to implement it; or nobody agrees. I think it was Graeme Geldenhuys wrote this page: http://wiki.lazarus.freepascal.org/Namespaces Regards, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] How to detect if my program is running with root/elevated privileges?
Hi, In my program I have some functions that must only be enabled if the program is invoked as root (linux) / administrator (windows). Is there some cross platform way to detect this? I thought of trying to write to a "protected" location (/etc/something on linux, C:\ProgramData\something on Windows), but the problem is that Windows virtualizes these calls (it'll end up somewhere lse, where your program will never find it again), so writing will succeed even if user has no administrator rights. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to detect if my program is running with root/elevated privileges?
In our previous episode, Bart said: > > I thought of trying to write to a "protected" location (/etc/something > on linux, C:\ProgramData\something on Windows), but the problem is > that Windows virtualizes these calls (it'll end up somewhere lse, > where your program will never find it again), so writing will succeed > even if user has no administrator rights. For windows there is winutils.iswindowsadmin(), for unix likes there is fpgeteuid (which should return zero for root). ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Namespaces Support
In our previous episode, Marcos Douglas said: > Yes and how I still use D7 at work I still have this problem. > This problem happen not only for unit names but component names too. I > can not register two components with the same name. True. But is maybe because RTTI (and .classname) didn't allow to get the unitname for a class. Since D2009 that afaik is possible, and it is unrelated to namespaces. Keep in mind that Delphi (1)'s original design was still 16-bit, and thus they tried to minimize memory use. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to detect if my program is running with root/elevated privileges?
On 10/27/13, Marco van de Voort wrote: > For windows there is winutils.iswindowsadmin(), for unix likes there is > fpgeteuid (which should return zero for root). Thanks a lot. Bart ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
