Am 28.07.2010 23:18, schrieb Daniël Mantione:
> Op Wed, 28 Jul 2010, schreef Hans-Peter Diettrich:
>
>> Daniël Mantione schrieb:
>>
>>> If I understand it well this patch will disable not only the fpc
>>> externsion:
>>>
>>> writeln(name_of_function);
>>>
>>> ... but also the standard Pascal:
>>>
Op Wed, 28 Jul 2010, schreef Hans-Peter Diettrich:
Daniël Mantione schrieb:
If I understand it well this patch will disable not only the fpc
externsion:
writeln(name_of_function);
... but also the standard Pascal:
name_of_function:=value;
Why would we want to disable the standard Pascal s
Jonas Maebe schrieb:
Thanks, I'll check it, and possibly add it to my OO rewrite branch
:-)
Just to make sure: please do not add any new features to your OO
rewrite branch. Reviewing it for potential merging into trunk will be
hard enough already without any new features added to it.
I only
Daniël Mantione schrieb:
If I understand it well this patch will disable not only the fpc
externsion:
writeln(name_of_function);
... but also the standard Pascal:
name_of_function:=value;
Why would we want to disable the standard Pascal solution?
Why not disable the Borland "result" extenti
On 28 Jul 2010, at 15:24, Hans-Peter Diettrich wrote:
> Thanks, I'll check it, and possibly add it to my OO rewrite branch :-)
Just to make sure: please do not add any new features to your OO rewrite
branch. Reviewing it for potential merging into trunk will be hard enough
already without any
On 28 Jul 2010, at 17:08, Florian Klaempfl wrote:
> Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich:
>> Florian Klaempfl schrieb:
>>
IMO we should have at least an option, that a function name can *not* be
used for the function result any more, for the result we have the Result
Florian Klaempfl skrev:
Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
IMO we should have at least an option, that a function name can *not* be
used for the function result any more, for the result we have the Result
variable. Then we can safely distinguis
Op Wed, 28 Jul 2010, schreef Florian Klaempfl:
Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich:
Florian Klaempfl schrieb:
IMO we should have at least an option, that a function name can *not* be
used for the function result any more, for the result we have the Result
variable. Then we can
Am 28.07.2010 15:10, schrieb Hans-Peter Diettrich:
> Florian Klaempfl schrieb:
>
>>> IMO we should have at least an option, that a function name can *not* be
>>> used for the function result any more, for the result we have the Result
>>> variable. Then we can safely distinguish between function c
Jeppe Johansen schrieb:
[please quote inline]
>>> I wouldn't miss not having the name of the function as a result
>>> variable in mode objfpc, at all. I think it would be a valid
>>> addition, as a compiler directive that was turned on as default, as
>>> not to break existing code
>>
>> It would
The procedure property_dec exists twice, in pdecl.pas and pdecobj.pas.
The pdecobj version seems to handle (old) syntax only, does not accept
unit properties nor multiple property declarations. Should it be
dropped, in favor of the pdecl version? If not, I'd suggest to rename
one of these proc
Florian Klaempfl schrieb:
IMO we should have at least an option, that a function name can *not* be
used for the function result any more, for the result we have the Result
variable. Then we can safely distinguish between function calls (by
function name) and results (by "Result"). If ever requir
Touché
But still. I don't even know how it'll be resolved. There's a function
with name "functionname", and there's a variable with name "functionname"
I've stumbled into this problem a couple of times in the past, and all
times it's been hard to figure out why it didn't work as
intended(tho
In our previous episode, Jeppe Johansen said:
>
> The semantics are really hard to figure out too, whereas it makes
> perfect sense when you use "result". I don't think it follows logically
> whether it'll call the function or set the result
Is this so? If result is a procvar, can't you call it
How would it? As I wrote, I suggested that you should be able to disable
the function name result variable with a compiler directive. That
wouldn't break anything since normal code wouldn't have the compiler
directive
I know why the functionality is there, but I just think it's unnecessary
ba
On 28/07/2010 11:20, Sven Barth wrote:
Am 28.07.2010 11:31, schrieb Martin:
True, please add to wiki, so it doesn't get forgotten
Done.
What about the uses clause I wrote by mistake (I corrected that in the
wiki entry):
uses
Windows, Graphics, Graphics in GraphicsPkg as PkgGraphics;
How
Am 28.07.2010 11:31, schrieb Martin:
True, please add to wiki, so it doesn't get forgotten
Done.
What about the uses clause I wrote by mistake (I corrected that in the
wiki entry):
uses
Windows, Graphics, Graphics in GraphicsPkg as PkgGraphics;
How should the compiler resolve (the LCL's)
On 28/07/2010 10:23, Sven Barth wrote:
Am 27.07.2010 13:27, schrieb Martin:
Great feedback, thanks.
I added several point to
http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path
Regarding the following point:
It may be proposed, that if 2 units Utils exists,
Am 27.07.2010 13:27, schrieb Martin:
Great feedback, thanks.
I added several point to
http://wiki.lazarus.freepascal.org/Namespaces#Mapping_Namespace_to_each_search_path
Regarding the following point:
It may be proposed, that if 2 units Utils exists, both must be aliased. Even
though, if on
Am 27.07.2010 18:24, schrieb Hans-Peter Diettrich:
> I just had to chase an strange bug, in a local (nested) subroutine. When
> I made several functions (if_statement() ...) local subroutines of
> method statement(), they stopped to work properly :-(
>
> After many tries I concluded, that every (r
20 matches
Mail list logo
