Dear Sir,
I had sent a query regarding fpc 3.0.0 yesterday. In it, I forgot to
mention that I am not there in the mailing list.
Waiting for a reply!
On Wed, Jan 27, 2016 at 2:46 PM, Ranjani Krishnan
wrote:
> Dear Sir,
>
> We have a Pascal program using recursion feature. We are using free pasc
Guys 3 observations.
1) if dots do not allow me to do something along the lines of
Uses
Core.Text;
Instead of
Uses
Core.Text, Core.TExt.XML, core.Text.Json;
Then I would prefer to avoid having to type the dots and stick to the
camel case unit names only, same effect in my book.
On 27/01/2016 00:27 πμ, Anthony Walter wrote:
I guess this is good time to ask, how would the community feel about
setting a new standard for Free Pascal units going forward? I am
thinking that since FPC 3.0 is now official we don't really have a good
excuse to start using many of the great new l
Am 27.01.2016 23:41 schrieb "Maciej Izak" :
>
> 2016-01-27 17:24 GMT+01:00 Sven Barth :
>>
>> I'll need to look at your code again, but even for class functions the
same rules (and worries) as for normal methods apply.
>
> I hope that your research in Generics.Defaults will be successful for
manual
2016-01-28 0:38 GMT+01:00 Sven Barth :
> Why would each collection instance need to contain an instance of the
> comparer? They don't contain state and are reentrant, so they can be easily
> shared with ARC singletons.
>
> Note: there would either need to be a global variable for each instance or
2016-01-27 17:24 GMT+01:00 Sven Barth :
> I'll need to look at your code again, but even for class functions the
> same rules (and worries) as for normal methods apply.
>
I hope that your research in Generics.Defaults will be successful for
manual interfaces :P
Most important about manual interfa
2016-01-27 21:01 GMT+01:00 Anthony Walter :
> I've just like to point out that with Svens new support for generic
> functions, we actually have template like functionality in Free Pascal. You
> can now write functions which will verify at compile time the support of a
> method or operator for a pa
In our previous episode, Sven Barth said:
> >
> > What do you make about the piece of code that Dimitry quoted ( "in this..) ?
> >
> > I tried to read the link above, but it doesn't explicitly say that you can
> > import "mycompany.projectx.projecty" (and that the system then must figure
> > out
On 27.01.2016 17:54, Marco van de Voort wrote:
> In our previous episode, Sven Barth said:
>>> See:
>> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/usingnamespaces_xml.html
>>>
>>> For example: section "Multi-unit Namespaces"
>>> unit MyCompany.Proj
> Unlike Delphi, we have TCompare class and TEquals class, which is used
> for manual interfaces (together with TRawInterface and
TComTypeSizeInterface).
> Additionally (unlike in Delphi which has hidden regular functions for
this in
> implementation section with fake self parameter) TCompare and T
++ 1 !
We need to somehow clarify many things in this field. My next big
milestone is RTTI.Invoke method (I'd like to omit implementing this
:P). For example only in FPC dyn. array parameter is passed on stack
instead of by reference (in opposition to Delphi)... with small change
in r30870 fo
In our previous episode, Sven Barth said:
> > See:
> http://docs.embarcadero.com/products/rad_studio/delphiAndcpp2009/HelpUpdate2/EN/html/devcommon/usingnamespaces_xml.html
> >
> > For example: section "Multi-unit Namespaces"
> > unit MyCompany.ProjectX.ProgramY.Unit1
> > unit MyCompany.ProjectX.Pr
Am 27.01.2016 16:31 schrieb "Dmitry Boyarintsev" :
>
> On Wed, Jan 27, 2016 at 8:46 AM, Maciej Izak wrote:
>>
>> 2016-01-27 14:44 GMT+01:00 Michael Van Canneyt :
>>>
>>> On Wed, 27 Jan 2016, Juha Manninen wrote:
>>>
Hey guys ...
Now this Generics.Collections is completely hijacked b
2016-01-27 17:24 GMT+01:00 Sven Barth :
> I'll need to look at your code again, but even for class functions the
> same rules (and worries) as for normal methods apply.
>
Unlike Delphi, we have TCompare class and TEquals class, which is used for
manual interfaces (together with TRawInterface and
Am 27.01.2016 15:52 schrieb "Maciej Izak" :
>> The point is that it is not necessarily guaranteed on each and every
platform that the parameter passing of a (interface) method is the same as
for a global function with an additional instance parameter. This *might*
be true for those platforms on whi
Am 27.01.2016 16:51 schrieb "Maciej Izak" :
>
> 2016-01-27 15:03 GMT+01:00 Sven Barth :
>>
>> The point is that it is not necessarily guaranteed on each and every
platform that the parameter passing of a (interface) method is the same as
for a global function with an additional instance parameter.
2016-01-27 15:03 GMT+01:00 Sven Barth :
> The point is that it is not necessarily guaranteed on each and every
> platform that the parameter passing of a (interface) method is the same as
> for a global function with an additional instance parameter. This *might*
> be true for those platforms on w
On Wed, Jan 27, 2016 at 8:46 AM, Maciej Izak wrote:
> 2016-01-27 14:44 GMT+01:00 Michael Van Canneyt :
>
>> On Wed, 27 Jan 2016, Juha Manninen wrote:
>>
>> Hey guys ...
>>>
>>> Now this Generics.Collections is completely hijacked by a namespace
>>> discussion. Does it mean the original issue is a
2016-01-27 15:03 GMT+01:00 Sven Barth :
> Thank you for the link, because now I know what was *really* bugging me
> about the code all the time (you know that feeling that you instinctively
> know that something is wrong, but you can't really pinpoint.it? ;) ).
>
I have those feeling half of my li
On Wed, 27 Jan 2016, Sven Barth wrote:
http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use
Thank you for the link, because now I know what was *really* bugging me
about the code all the time (you know that feeling that
In our previous episode, Sven Barth said:
>
> So if you would instead change the code to use real class instances that
> implement the interfaces (they can be lazily allocated singletons or so)
> then I'd definitely be inclined to include the code in trunk.
Is there any hope for 3.0.2 ?
_
Am 27.01.2016 12:15 schrieb "Maciej Izak" :
>
> 2016-01-27 12:07 GMT+01:00 Michael Van Canneyt :
>>
>> On Wed, 27 Jan 2016, Juha Manninen wrote:
>>>
>>> Yes, that is about your Generics.Collections compatibility.
>>> I was more interested why fcl-stl is not Delphi compatible while many
>>> other li
2016-01-27 14:44 GMT+01:00 Michael Van Canneyt :
> On Wed, 27 Jan 2016, Juha Manninen wrote:
>
> Hey guys ...
>>
>> Now this Generics.Collections is completely hijacked by a namespace
>> discussion. Does it mean the original issue is again buried and
>> forgotten for another year or two?
>>
>
> No
On Wed, 27 Jan 2016, Juha Manninen wrote:
Hey guys ...
Now this Generics.Collections is completely hijacked by a namespace
discussion. Does it mean the original issue is again buried and
forgotten for another year or two?
No. Sven is on it.
Michael.
Hey guys ...
Now this Generics.Collections is completely hijacked by a namespace
discussion. Does it mean the original issue is again buried and
forgotten for another year or two?
You could easily move the unrelated discussion to another thread by
indicating this thread in the subject, like:
"Do
On Wed, 27 Jan 2016, Marco van de Voort wrote:
In our previous episode, Marcos Douglas said:
On Wed, Jan 27, 2016 at 7:22 AM, Michael Van Canneyt
wrote:
I don't think namespaces are the holy grail.
Assume we introduce namespaces, do things 'Properly' and introduce
Core.FileUtils
Core.Strin
On Wed, Jan 27, 2016 at 10:06 AM, Ondrej Pokorny wrote:
> On 27.01.2016 14:05, Marco van de Voort wrote:
>
>> fpc.core.filesystem.file.utils is better I think.
>>
>
> +1 :D
Or:
System.File:
...
TUtils
static methods for file utilities;
TFile
static methods for file operations;
The fpc.co
On Wed, 27 Jan 2016, silvioprog wrote:
On Wed, Jan 27, 2016 at 6:22 AM, Michael Van Canneyt
wrote:
[...]
Assume we introduce namespaces, do things 'Properly' and introduce
Core.FileUtils
Core.StringUtils
(the names are just examples, to make a point)
Now let's take example existing routin
On Wed, 27 Jan 2016, Marcos Douglas wrote:
On Wed, Jan 27, 2016 at 7:22 AM, Michael Van Canneyt
wrote:
I don't think namespaces are the holy grail.
Assume we introduce namespaces, do things 'Properly' and introduce
Core.FileUtils
Core.StringUtils
(the names are just examples, to make a poin
On Wed, Jan 27, 2016 at 6:22 AM, Michael Van Canneyt wrote:
[...]
> Assume we introduce namespaces, do things 'Properly' and introduce
> Core.FileUtils
> Core.StringUtils
> (the names are just examples, to make a point)
>
> Now let's take example existing routines such as
> ExtractFilePath
> Extr
On Wed, Jan 27, 2016 at 11:05 AM, Marco van de Voort wrote:
> In our previous episode, Marcos Douglas said:
>> On Wed, Jan 27, 2016 at 7:22 AM, Michael Van Canneyt
>> wrote:
>> > I don't think namespaces are the holy grail.
>> >
>> > Assume we introduce namespaces, do things 'Properly' and introd
On 27.01.2016 14:05, Marco van de Voort wrote:
fpc.core.filesystem.file.utils is better I think.
+1 :D
Ondrej
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
In our previous episode, Marcos Douglas said:
> On Wed, Jan 27, 2016 at 7:22 AM, Michael Van Canneyt
> wrote:
> > I don't think namespaces are the holy grail.
> >
> > Assume we introduce namespaces, do things 'Properly' and introduce
> > Core.FileUtils
> > Core.StringUtils
> > (the names are just
In our previous episode, Maciej Izak said:
> > Wouldn't it be possible to take my idea and start developing a new library
> > which contains the generic containers you need?
> >
>
> As Sven said. All is ready. Anyway I like the idea of new namespaces more
> C# like (or even new namespaces should b
On Wed, Jan 27, 2016 at 7:22 AM, Michael Van Canneyt
wrote:
> I don't think namespaces are the holy grail.
>
> Assume we introduce namespaces, do things 'Properly' and introduce
> Core.FileUtils
> Core.StringUtils
> (the names are just examples, to make a point)
>
> Now let's take example existing
On Wed, Jan 27, 2016 at 7:20 AM, Tomas Hajny wrote:
> On Wed, January 27, 2016 09:46, Anthony Walter wrote:
>
>
> Anthony,
>
>> Do you care to address the issues I raised with the inconsistency of
>> string related functions I raised? Specifically the part about string
>> functions in SysUtils, St
On Wed, Jan 27, 2016 at 1:14 PM, Maciej Izak wrote:
> http://stackoverflow.com/questions/17951412/what-does-the-default-tarray-sort-comparator-actually-do-and-when-would-you-use
The Delphi code listed there looks implementation specific, too,
although I don't understand many details.
pinfo :
In our previous episode, Michael Van Canneyt said:
> >> https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf
> >
> > Yes, that is about your Generics.Collections compatibility.
> > I was more interested why fcl-stl is not Delphi compatible while many
> > other l
y
On Wed, 27 Jan 2016, Michael Van Canneyt wrote:
On Wed, 27 Jan 2016, Anthony Walter wrote:
Micahel,
Do you care to address the issues I raised with the inconsistency of string
related functions I raised? Specifically the part about string functions in
SysUtils, StrUtils, LCLProcs, LazUTF
On Wed, 27 Jan 2016, Maciej Izak wrote:
2016-01-27 12:07 GMT+01:00 Michael Van Canneyt :
On Wed, 27 Jan 2016, Juha Manninen wrote:
Yes, that is about your Generics.Collections compatibility.
I was more interested why fcl-stl is not Delphi compatible while many
other libraries provided by F
2016-01-27 11:36 GMT+01:00 Anthony Walter :
>
> Wouldn't it be possible to take my idea and start developing a new library
> which contains the generic containers you need?
>
As Sven said. All is ready. Anyway I like the idea of new namespaces more
C# like (or even new namespaces should be compati
2016-01-27 12:07 GMT+01:00 Michael Van Canneyt :
>
> On Wed, 27 Jan 2016, Juha Manninen wrote:
>>
>> Yes, that is about your Generics.Collections compatibility.
>> I was more interested why fcl-stl is not Delphi compatible while many
>> other libraries provided by FPC project are.
>>
>
> It was don
On Wed, 27 Jan 2016, Juha Manninen wrote:
On Wed, Jan 27, 2016 at 12:32 PM, Maciej Izak wrote:
about compatibility and bugs:
https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf
Yes, that is about your Generics.Collections compatibility.
I was more inte
2016-01-27 11:38 GMT+01:00 Sven Barth :
> If you want to use them *now* you should put them into components/sparta,
> though then again they only work with trunk anyway because of that one
> bug... It's not easy -.-
>
Half of year sounds reasonable. I can wait. 2 years delay is too long. Btw.
we n
On Wed, Jan 27, 2016 at 12:32 PM, Maciej Izak wrote:
> about compatibility and bugs:
> https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf
Yes, that is about your Generics.Collections compatibility.
I was more interested why fcl-stl is not Delphi compatible w
Am 27.01.2016 11:36 schrieb "Anthony Walter" :
>
> Maciej,
>
> Wouldn't it be possible to take my idea and start developing a new
library which contains the generic containers you need? I have a nice
generic container unit you could use or just pull out the classes you need
out of the existing FPC
Am 27.01.2016 11:30 schrieb "Maciej Izak" :
>
> 2016-01-27 11:26 GMT+01:00 Sven Barth :
>>
>> Even if I'd add them now it would be at least half a year for them to
appear in a stable release if we merge them to fixes_3_0 (which is not a
given!). And if not it would probably be at least 2 years till
Maciej,
Wouldn't it be possible to take my idea and start developing a new library
which contains the generic containers you need? I have a nice generic
container unit you could use or just pull out the classes you need out of
the existing FPC generics unit, duplicate them in their your own unit,
2016-01-27 11:28 GMT+01:00 Juha Manninen :
> Are there technical reasons against Delphi compatibility?
> Can I find information about this issue somewhere?
>
about compatibility and bugs:
https://github.com/dathox/generics.collections/raw/master/GenericsCompatibilityMatrix.pdf
--
Best regards
2016-01-27 11:26 GMT+01:00 Sven Barth :
> Even if I'd add them now it would be at least half a year for them to
> appear in a stable release if we merge them to fixes_3_0 (which is not a
> given!). And if not it would probably be at least 2 years till the next
> major release.
>
so what should I d
On Wed, Jan 27, 2016 at 9:57 AM, Sven Barth wrote:
> As long as it's not in the bootstrapping RTL I don't really care where we
> put it ;)
So it could be added to FPC trunk soon?
This issue has been open for a long time. I hope some decision can be made.
I don't understand many things around FPC
Tomas,
> Alright. So what is the authorship of the default units and how does it
> fit to Delphi compatibility?
At some point (soon) I hope Free Pascal and Lazarus will expand beyond
being Delphi compatible. In my recommendations I did not mean to infer that
Delphi compatibility should be broken
Am 27.01.2016 09:11 schrieb "Maciej Izak" :
>
> 2016-01-27 8:06 GMT+01:00 Sven Barth :
>>
>> I'm definitely not a fan of the manual interface building it does,
because I don't want to have to maintain that, just in case we change some
implementation detail in FPC that this unit happens to rely on,
Am 27.01.2016 11:10 schrieb "Maciej Izak" :
>
> 2016-01-27 10:51 GMT+01:00 Ondrej Pokorny :
>>
>>
>> And then there is the problem with duplicate unit names. The Lazarus
version of your units could e.g. use an extra namespace.
>>
>
> Maybe is good idea to follow Delphi standards and add System.* na
2016-01-27 10:51 GMT+01:00 Ondrej Pokorny :
>
> And then there is the problem with duplicate unit names. The Lazarus
> version of your units could e.g. use an extra namespace.
>
>
Maybe is good idea to follow Delphi standards and add System.* namespace
for FPC RTL modules. Delphi allows following
On 27.01.2016 9:11, Maciej Izak wrote:
Just let me know what is your plan. If you wan't it in FPC RTL then it
will became part of sparta packages in Lazarus.
It has tu be duplicated in Lazarus anyway if you plan to use it in
Sparta code. The same was with AdvancedIPC unit.
The problem is tha
On Wed, 27 Jan 2016, Tomas Hajny wrote:
On Wed, January 27, 2016 09:46, Anthony Walter wrote:
Anthony,
Do you care to address the issues I raised with the inconsistency of
string related functions I raised? Specifically the part about string
functions in SysUtils, StrUtils, LCLProcs, LazUT
On Wed, 27 Jan 2016, Anthony Walter wrote:
Micahel,
Do you care to address the issues I raised with the inconsistency of string
related functions I raised? Specifically the part about string functions in
SysUtils, StrUtils, LCLProcs, LazUTF8, among other units where string
related routines ar
On Wed, January 27, 2016 09:46, Anthony Walter wrote:
Anthony,
> Do you care to address the issues I raised with the inconsistency of
> string related functions I raised? Specifically the part about string
> functions in SysUtils, StrUtils, LCLProcs, LazUTF8, among other units where
> string rel
On Wed, January 27, 2016 08:57, Anthony Walter wrote:
Hello,
> I see the many benefits of dotted namespace units.
>
> 1) Authorship.
>
> Instead of using cryptic prefixes (Rx, Syn, Id, and so on) if we promoted
> the use of namespaces we might someday the full names denoting ownership
> more cle
Micahel,
Do you care to address the issues I raised with the inconsistency of string
related functions I raised? Specifically the part about string functions in
SysUtils, StrUtils, LCLProcs, LazUTF8, among other units where string
related routines are scattered. Also strings aren't the only types
On Wed, 27 Jan 2016, Anthony Walter wrote:
Michael,
I see the many benefits of dotted namespace units.
Yes, they are the same ones everyone cites.
None are very convincing. The only one - and minor at that - is the discovery.
Take for example your "TEdit" versus "TWebedit" argument:
I WA
2016-01-27 8:06 GMT+01:00 Sven Barth :
> I'm definitely not a fan of the manual interface building it does, because
> I don't want to have to maintain that, just in case we change some
> implementation detail in FPC that this unit happens to rely on, maybe even
> only in a subtle way. No performan
63 matches
Mail list logo
