On Tue, Jul 27, 2010 at 11:10 AM, Martin wrote:
> [snip]
>> IMO, if there is no further concept of child units (maybe similar to Ada)
>> there is no point in adding namespaces to FPC, it's not worth the trouble.
>> After all, it's still a name and if somebody else already uses it, you still
>> nee
On 27/07/2010 14:28, "Vinzent Höfler" wrote:
Marcos Douglas:
You right about "constants.pas".
Then I would like to give other example: StrUtils.pas
What we expect in unit StrUtils or "Strings Utilities". Is very clear.
But we can't use this name. That is the problem (no for FPC's units
becau
On Tue, Jul 27, 2010 at 10:28 AM, "Vinzent Höfler"
wrote:
> Marcos Douglas :
>
>> > But then, IME (most) name conflicts are a sure sign of inproper names.
>> Take the
>> > example of "constants.pas": What sort of constants shall I expect there?
>> Screen sizes,
>> > color codes, electron mass or t
On 27 Jul 2010, at 15:38, Jonas Maebe wrote:
BTW, LGPL v3 explicitly allows subclassing:
"Defining a subclass of a class defined by the Library is deemed a
mode
of using an interface provided by the Library."
That section was added for the purpose of C++ classes
... C++ *template* classe
On 27 Jul 2010, at 14:32, Vladimir Zhirov wrote:
Reading gnu.org does not clarify the situation because:
A) GPL FAQ states that "Subclassing is creating a derivative work."
(http://www.gnu.org/licenses/gpl-faq.html#OOPLang)
That's normal *in the context of the GPL*: to subclass you have to
On Tue, 27 Jul 2010 17:32:12 +0500
Vladimir Zhirov wrote:
> Hi,
>
> There was a question raised in Russian FPC forum about whether LCL
> license (modified LGPL) should be applied to a subclass of LCL class:
> TMyButton = class(TButton)
> This turned out to be a deeper problem, since it would a
Marcos Douglas :
> > But then, IME (most) name conflicts are a sure sign of inproper names.
> Take the
> > example of "constants.pas": What sort of constants shall I expect there?
> Screen sizes,
> > color codes, electron mass or the gravitational constant?
>
> You right about "constants.pas".
>
Am 27.07.2010 14:32, schrieb Vladimir Zhirov:
>
> So this seems unclear whether application that subclasses from
> RTL/FCL/LCL is a derived work of RTL/FCL/LCL and must itself be
> licensed under Modified LGPL, making source code open.
>
> BTW, LGPL v3 explicitly allows subclassing:
> "Defining a
Hi,
There was a question raised in Russian FPC forum about whether LCL
license (modified LGPL) should be applied to a subclass of LCL class:
TMyButton = class(TButton)
This turned out to be a deeper problem, since it would also affect
subclassing from RTL/FCL classes:
TMyObject = class(TObject
On Tue, Jul 27, 2010 at 5:44 AM, "Vinzent Höfler"
wrote:
>> On 26 July 2010 19:26, Thierry Coq wrote:
>> >
>> > I see units as namespaces already existing: we use the unit names to
>> > prefix
>> > ambiguous function or variable names for example.
>>
>> Unit Names give very limited namespace supp
In our previous episode, Anthony Walter said:
> I'd say that the way FPC handles things different than Delphi in some cases
> is worse. Take generics, which you mentioned.
Worse or not is a personal matter of taste.
Keep in mind that the Delphi syntax (since essentially C++) was considered
too.
On Mon, 26 Jul 2010 14:49:02 +0200
Jonas Maebe wrote:
>
> On 26 Jul 2010, at 14:18, Bernd Kreuss wrote:
>
> > What is the easiest way to have a second installation of FPC around that
> > I can easily switch to on the same machine without having to change half
> > a dozen paths and moving config
Jonas Maebe wrote:
... How to combine this with Lazarus, I don't know.
Lazarus has the --pcp= commandline option which defines the primary
configuration path, hence the location of the FPC compiler binary and
library sources. I've copied the source tree into an appropriate place
in /usr/loc
> On 26 July 2010 19:26, Thierry Coq wrote:
> >
> > I see units as namespaces already existing: we use the unit names to
> > prefix
> > ambiguous function or variable names for example.
>
> Unit Names give very limited namespace support - which only applies to
> types or procedures/functions or g
14 matches
Mail list logo
