On Tue, Nov 5, 2013 at 12:10 PM, leledumbo wrote:
>> The packages are defined using directories. Is Java a mess too?
>
> Yes, exactly, that's what makes Java package system messy. It makes
> refactoring (or restructurization) extremely difficult for deep package
> hierarchy.
So I proposed somethi
On Tue, 5 Nov 2013 07:10:21 -0800 (PST)
leledumbo wrote:
> > The packages are defined using directories. Is Java a mess too?
>
> Yes, exactly, that's what makes Java package system messy. It makes
> refactoring (or restructurization) extremely difficult for deep package
> hierarchy.
Java has
> The packages are defined using directories. Is Java a mess too?
Yes, exactly, that's what makes Java package system messy. It makes refactoring
(or restructurization) extremely difficult for deep package hierarchy.
On Tuesday, November 5, 2013 6:37 PM, Marcos Douglas [via Free Pascal -
Ge
On Mon, Nov 4, 2013 at 10:44 PM, Dmitry Boyarintsev
wrote:
> On Mon, Nov 4, 2013 at 6:07 PM, Marcos Douglas wrote:
>>
>> Sorry, but this is boring.
>> Do you not agree that is much better propose a solution to be possible
>> to use two -- or more -- units that have the same name but works
>> toge
On Mon, Nov 4, 2013 at 6:07 PM, Marcos Douglas wrote:
> Sorry, but this is boring.
> Do you not agree that is much better propose a solution to be possible
> to use two -- or more -- units that have the same name but works
> together at the same project?
Thought process is a boring thing in natu
On Mon, Nov 4, 2013 at 1:31 PM, Dmitry Boyarintsev
wrote:
> On Mon, Nov 4, 2013 at 10:06 AM, Marcos Douglas wrote:
>>
>> On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev
>> wrote:
>> > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote:
>> >>
>> >> 2- If ExtraUtils depends on StrUtils.pas
On Mon, Nov 4, 2013 at 10:06 AM, Marcos Douglas wrote:
> On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev
> wrote:
> > On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote:
> >>
> >> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is
> >> not a subdirectory of lib then th
On Mon, Nov 4, 2013 at 11:36 AM, Dmitry Boyarintsev
wrote:
> On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote:
>>
>> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is
>> not a subdirectory of lib then the "otherlib needs to be compiled
>> using a ALIAS:
>> -ALIAS=TheLib@l
On Mon, Nov 4, 2013 at 9:08 AM, Marcos Douglas wrote:
> 2- If ExtraUtils depends on StrUtils.pas from "lib". But "otherlib" is
> not a subdirectory of lib then the "otherlib needs to be compiled
> using a ALIAS:
> -ALIAS=TheLib@lib\*
>
Ah, yes, you've mentioned the necessity for two steps compila
On Mon, Nov 4, 2013 at 10:45 AM, Dmitry Boyarintsev
wrote:
> On Mon, Nov 4, 2013 at 8:07 AM, Marcos Douglas wrote:
>>
>> >> First, if you have a lib that have dependencies to another lib, you
>> >> have to provide all sources together -- in the same directory or
>> >> subdirectories. For this ca
On Mon, Nov 4, 2013 at 8:07 AM, Marcos Douglas wrote:
> >> First, if you have a lib that have dependencies to another lib, you
> >> have to provide all sources together -- in the same directory or
> >> subdirectories. For this case just use the rule #1.
> >> But, if you did not provide the sourc
On Sun, Nov 3, 2013 at 10:22 PM, Dmitry Boyarintsev
wrote:
> On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas wrote:
>>
>> Wrong. Do not breaks the compiler backward compatibility.
>> I said " in the same directory and/or own tree", ie, in the same
>> directory and subdirectories. For these cases,
On Sun, Nov 3, 2013 at 10:27 AM, Marcos Douglas wrote:
> Wrong. Do not breaks the compiler backward compatibility.
> I said " in the same directory and/or own tree", ie, in the same
> directory and subdirectories. For these cases, the compiler do not
> need changes.
>
The compiler doesn't use a u
On Sun, Nov 3, 2013 at 1:25 PM, Marco van de Voort wrote:
> In our previous episode, Benito van der Zander said:
>> > Then the John Douglas and Douglas McKey are running into the same issue.
>> > Both guys (while living on different parts of the world) created the
>> > same "douglas" namespace!
>>
On Sun, Nov 3, 2013 at 12:06 AM, Dmitry Boyarintsev
wrote:
> On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote:
>>
>> On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev
>> wrote:
>> >
>> > On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote:
>>
>> This works only if you don't want use Str
In our previous episode, Benito van der Zander said:
> > Then the John Douglas and Douglas McKey are running into the same issue.
> > Both guys (while living on different parts of the world) created the
> > same "douglas" namespace!
>
> That's why most languages use domains as namespace
> Then yo
Then the John Douglas and Douglas McKey are running into the same issue.
Both guys (while living on different parts of the world) created the
same "douglas" namespace!
That's why most languages use domains as namespace
Then you would have
net.delfire.douglas.*
org.msegui.*
and no collision
On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote:
> On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev
> wrote:
> >
> > On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote:
>
This works only if you don't want use StrUtils of your project and,
> IMHO, this is more complex solution. You wi
On Sat, Nov 2, 2013 at 7:44 PM, Dmitry Boyarintsev
wrote:
> On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote:
>>
>> > compiling with
>> > fpc -ALIAS /lib/* TheLib
>> >
>> > won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils
>>
>> Well, is more common to use just ppu files
On Sat, Nov 2, 2013 at 12:19 PM, Marcos Douglas wrote:
> > compiling with
> > fpc -ALIAS /lib/* TheLib
> >
> > won't help, unless you change "ExtraUtils.pas" to use TheLib.StrUtils
>
> Well, is more common to use just ppu files to not compile these files
> every compilation. So, the Lib was alrea
On Sat, Nov 2, 2013 at 12:32 PM, Dmitry Boyarintsev
wrote:
>
> On Sat, Nov 2, 2013 at 6:55 AM, Marcos Douglas wrote:
>>
>> On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev
>> wrote:
>> > Technical problem:
>> > * a unit name collision of two independent library code. Either library
>> > are
>
Hmm, let me extend your example:
/project/unit1.pas
/project/StrUtils.pas
/lib/StrUtils.pas
/lib/ExtraUtils.pas
---code---
unit ExtraUtils;
uses StrUtils; // assumed library StrUtils, not project
===code===
However, since StrUtils is present in project directory, it will be used
instead, causin
On Fri, Nov 1, 2013 at 11:54 PM, Dmitry Boyarintsev
wrote:
> Technical problem:
> * a unit name collision of two independent library code. Either library are
> using unit with the same name. The code in the conflicting units is
> different. Thus one library should use its own unit, the other shoul
Technical problem:
* a unit name collision of two independent library code. Either library are
using unit with the same name. The code in the conflicting units is
different. Thus one library should use its own unit, the other should use
its own.
Since FPC allows to specify the search path for the w
On Wed, Oct 30, 2013 at 3:45 PM, Marco van de Voort wrote:
> What if unitaa needs recompilation, and it is not in the dir it was
> originally
> compiled in. .\some\other\place then has a different meaning.
>
> Specially if the relative paths are short (like ..\src\ or so), there is
> still
> quit
In our previous episode, Dmitry Boyarintsev said:
> I guess, technically it should be possible to use two different units with
> the same name.
>
> I recall there was a discussion a while (few years) ago, about (re)using
> Delphi introduced 'in' syntax (afaik, it is not available in pascal).
> use
On Wed, Oct 30, 2013 at 1:35 PM, Marcos Douglas wrote:
> IMO, the problem is:
> You can not use two unit with the same name.
> So, you can point -- using -Fu -- which unit the compiler will compile
> but you can't used both at the same project.
>
I guess, technically it should be possible to use
On Tue, Oct 29, 2013 at 5:05 PM, Dmitry Boyarintsev
wrote:
> On Tue, Oct 29, 2013 at 3:50 PM, Marcos Douglas wrote:
>>
>> Yes, works... but the language allow hide the unit name and nobody
>> uses unit name as an identifier in 99% of cases, Am I right? So,
>> problems can be happen.
>>
> From my
On Tue, Oct 29, 2013 at 4:51 PM, Dmitry Boyarintsev
wrote:
> On Tue, Oct 29, 2013 at 8:02 AM, Marcos Douglas wrote:
>>
>> You didn't understand.
>> The namespace we talk about is like a "dinamic namespace". The
>> programmer can choose which "names" he will use in your projects when
>> these proj
On Tue, Oct 29, 2013 at 3:50 PM, Marcos Douglas wrote:
> Yes, works... but the language allow hide the unit name and nobody
> uses unit name as an identifier in 99% of cases, Am I right? So,
> problems can be happen.
>
> From my experience I'd say no.
I actually had to use the explicit unit name
On Tue, Oct 29, 2013 at 8:02 AM, Marcos Douglas wrote:
> You didn't understand.
> The namespace we talk about is like a "dinamic namespace". The
> programmer can choose which "names" he will use in your projects when
> these projects are using third-party frameworks.
> In Java, eg, you can change
On Tue, Oct 29, 2013 at 3:01 PM, Ewald wrote:
> Once upon a time, Marcos Douglas said:
>> Do you (all) use prefix in Procedures and/or Functions too? ;-)
> Unitname.GetHandler() ?
Yes, works... but the language allow hide the unit name and nobody
uses unit name as an identifier in 99% of cases, A
On Tue, Oct 29, 2013 at 1:31 PM, leledumbo wrote:
>> Another type of conflict happens -- but no one talks about it -- using
> procedure/function with the same parameters in different units.
> Eg: GetHandler(); If you use two units that have a GetHandler
> function, in a third unit, you have a tro
On Tue, Oct 29, 2013 at 12:55 PM, Reimar Grabowski wrote:
> On Tue, 29 Oct 2013 13:22:47 -0200
> Marcos Douglas wrote:
>
>> Do you (all) use prefix in Procedures and/or Functions too? ;-)
> Nope, we use classes and methods instead of global procedures and functions.
> ;)
Me too but, unfortunat
Once upon a time, Marcos Douglas said:
> Do you (all) use prefix in Procedures and/or Functions too? ;-)
Unitname.GetHandler() ?
--
Ewald
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pasca
> Another type of conflict happens -- but no one talks about it -- using
procedure/function with the same parameters in different units.
Eg: GetHandler(); If you use two units that have a GetHandler
function, in a third unit, you have a trouble.
Do you (all) use prefix in Procedures and/or Fun
On Tue, 29 Oct 2013 13:22:47 -0200
Marcos Douglas wrote:
> Do you (all) use prefix in Procedures and/or Functions too? ;-)
Nope, we use classes and methods instead of global procedures and functions. ;)
R.
___
fpc-pascal maillist - fpc-pascal@lists.
On Tue, Oct 29, 2013 at 4:10 AM, Graeme Geldenhuys
wrote:
>
> On Tuesday 29/10/2013 at 03:50, Dmitry Boyarintsev wrote:
>
>>
>> Then the John Douglas and Douglas McKey are running into the same issue.
>>
>> Both guys (while living on different parts of the world) created the same
>> "douglas" nam
In our previous episode, Graeme Geldenhuys said:
> > Both guys (while living on different parts of the world) created the
> > same "douglas" namespace!
>
> OK, ok, my example was bad. I would apply the exact same namespace
> rules as recommended by Java. In a real situation you should use your
On Mon, Oct 28, 2013 at 10:48 PM, Dmitry Boyarintsev
wrote:
> On Mon, Oct 28, 2013 at 9:27 AM, Graeme Geldenhuys
> wrote:
>>
>> I would have thought that is exactly what namespaces will be handy for! Or
>> at least a popular use-case. Macros Douglas could define a "douglas"
>> namespace, and the
On Mon, Oct 28, 2013 at 10:27 AM, Graeme Geldenhuys
wrote:
>
>
> On Monday 28/10/2013 at 15:20, leledumbo wrote:
>
>
> Namespace does NOT solve the problem. If MSE units uses M. for their
> units and you have yours the same as well, you'll end up renaming either
> anyway.
>
>
> I would have though
On Tuesday 29/10/2013 at 03:50, Dmitry Boyarintsev wrote:
Then the John Douglas and Douglas McKey are running into the same
issue.
Both guys (while living on different parts of the world) created the
same "douglas" namespace!
OK, ok, my example was bad. I would apply the exact same
On Mon, 28 Oct 2013 21:48:33 -0400
Dmitry Boyarintsev wrote:
> Is it much different than just extending the prefix "M" to "MFP"?
Of course it is not, actually it's about the same, as you know. IMHO it's not
even a feature just another horrible idea of the Delphi guys used to get their
VCL and F
On Tuesday 29 October 2013 02:48:33 Dmitry Boyarintsev wrote:
>
> P.S. Offtopic: I personally find it horrible to call a unit "classes" (it's
> fine for RTL, since it's started this way, but any other library - it is
> horrible). Nobody calls their units like "functions" or
> "functionsandprodures"
On Mon, Oct 28, 2013 at 9:27 AM, Graeme Geldenhuys
wrote:
> I would have thought that is exactly what namespaces will be handy for! Or
> at least a popular use-case. Macros Douglas could define a "douglas"
> namespace, and the MSEide+MSEgui project could define a "msegui" namespace.
> Units, Class
On Monday 28/10/2013 at 15:20, leledumbo wrote:
Namespace does NOT solve the problem. If MSE units uses M. for
their units and you have yours the same as well, you'll end up
renaming either anyway.
I would have thought that is exactly what namespaces will be handy
for! Or at least a pop
So, what you're looking for is to change a "unit search priority" for a
specific units compiled:
// use a unit.
-Fu/path/mse/msegui.pas
// set the units search priority path
-Fs/path/mse/msegui.pas@/path/mse
In that case, if MClasses is used by "msegui.pas", "Mclasses" from
/path/mse will be used
On Mon, Oct 28, 2013 at 10:17 AM, leledumbo wrote:
>> 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 --
> 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. :(
Namesp
49 matches
Mail list logo
