On Tue, Nov 19, 2013 at 10:12 PM, Sieghard <s_c_...@arcor.de> wrote:
> Hallo Marcos,
>
> Du schriebst am Tue, 19 Nov 2013 00:25:26 -0200:
>
>> > There's no "new ALIAS compiler parameter" neccessary.
>>
>> I know there is no new ALIAS parameter... So I'm proposing one.
>
> Read completely - there is no ALIAS parameter _neccessary_.
Sorry, my mistake.
>> Ok.
>> So, please, explain how we can use __TWO__ units which have the
>> __same name__ in the same project using their approach.
>
> They cannot. Why'd you want that?
Because a 3rd lib could have an unit that have the same name that
other 3rd lib or the same name my own unit -- as happened when Martin
renamed classes.pas to mclasses.pas.
> BTW, you could always build a secondary project, a library, say, using one
> of them and include this into your main project.
And anyway, this is won't fix my problem with 'm' prefix units
(mclasses, etc) because mclasses unit is required in MSE. But this is
only one example.
> You split your project
> into several units anyway, why not split it into several subprojects also,
> especially when it is already so complex that you feel not being able to
> avoid using the same name multiply for the same purpose?
Sometimes this is good... but you have more work of course. You can
create a library, eg Synapse, to encapsulate all classes/functions you
will use in your project... but you need to reimplement all call for
classes/functions creating a "new API" -- that already exists and work
very well -- to use in your project ... why I would that??
> ...
>> Using my approach...
>>
>> [project file]
>> @lib1=/src/dir_1/*
>> @lib2=/src/dir_2/*
>>
>> "
>> unit Core;
>> interface
>> uses lib1.UnicodeUtils, lib2.UnicodeUtils;
>> "
>> Did you understand now?
>
> I did understand before. Now, how will you refer to some element in either
> "unit" that has the same name, but different function?
> Will you have to write "lib1.UnicodeUtils.ambigousname", forcing the
> compiler to add a new level of qualification above the real unit names?
Yes, like that, because this is the only way -- by design -- to do
that in Pascal. But this is better than Java, for example, because if
you have, in Java, two 'imports' that have the same Class, the
compiler show an error "ambigous name", ie, you do not have this
option... but Pascal does.
Because that (too) is a good practice in Object Pascal -- IMO of
course -- put your units always in last in queue because the compiler
will look the identifiers (class, function, const, whatever) from last
unit to the first.
Example:
unit1 -> procedure Foo;
unit2 -> procedure Foo;
unit3;
interface
uses unit1 {first}, unit2 {last};
[...]
end;
if you call Foo, the compiler will use unit2.Foo procedure.
So, I want to use MY class/functions then I always put my units on the last.
> Now, the contents of the project file show up in your source code, too.
>
Yes, you're right, but this is not my mistake. The compiler was designed so!
BUT, if we have the ALIAS parameter like I proposed, this "real file
names" could disappear from our sources. Every unit could be pointed
using an alias parameter.
>> > Anyway, we'll have to wait what will be implemented.
>>
>> I think so. Perhaps you understand the benefits.
>
> I don't see any.
Fortunately, Martin Schreiber saw the benefits and he said he will
implement this feature. ;-)
--
Marcos Douglas
------------------------------------------------------------------------------
Shape the Mobile Experience: Free Subscription
Software experts and developers: Be at the forefront of tech innovation.
Intel(R) Software Adrenaline delivers strategic insight and game-changing
conversations that shape the rapidly evolving mobile landscape. Sign up now.
http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
_______________________________________________
mseide-msegui-talk mailing list
mseide-msegui-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mseide-msegui-talk
