Hi,
- snip --
Include(WindowAttributes, waStayOnTop); // == doesn't compile with FPC 2.3.1
WindowAttributes:=WindowAttributes +[waStayOnTop]; // == this does
- end --
As far as I understood,
Graeme Geldenhuys wrote:
WindowAttributes are defined as follows:
...
property WindowAttributes: TWindowAttributes read FWindowAttributes
write FWindowAttributes;
...
It's the same thing as mentioned before, FPC now guarantees you can
change that into GetWindowAttributes function. If this
Graeme Geldenhuys wrote:
Hi,
- snip --
Include(WindowAttributes, waStayOnTop); // == doesn't compile with FPC 2.3.1
WindowAttributes:=WindowAttributes +[waStayOnTop]; // == this does
- end
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys:
It compiles without issues under FPC 2.2.3 and prior. What is wrong
with using Include() to add to a set? I do it all the time, plus
WindowAttribute is a read/write property, unlike the compiler error in
2.0.4 where you could use Include()
Op Wed, 16 Jul 2008, schreef Daniël Mantione:
2.3 prevents you form taking the address of a property, because that way you
can read/write its value directly, circumventing the getter/setter. So you
cannot use the @ operator, but neither can you pass properties to var
parameters. Include is
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation detail
should be hidden and this can/should be allowed; the
compiler internally should convert it into
2.3 prevents you form taking the address of a property, because that
way you can read/write its value directly, circumventing the
getter/setter. So you cannot use the @ operator, but neither can you
pass properties to var parameters. Include is an internal procedure
that calls an rtl
Op Wed, 16 Jul 2008, schreef Graeme Geldenhuys:
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation detail
should be hidden and this can/should be allowed; the
On 16 Jul 2008, at 10:01, Graeme Geldenhuys wrote:
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation
detail
should be hidden and this can/should be allowed; the
2008/7/16 Jonas Maebe [EMAIL PROTECTED]:
I think this would be ideal. Using Include() is much cleaner than set
:= set + [member]. And yes I understand that as it was implement, you
could circumvent the getter/setter, but I believe it's something the
compiler must handle correctly.
Adding
Hi,
just to add another opinion. Personally, I would thing that it was nice
to allow (write-able) Properties to any var-param (even out-param).
Write-able include properties with a setter-procedure.
IMHO the way it could be done would be for the compiler to create a
temporary variable. This
On Wed, Jul 16, 2008 at 9:40 AM, Daniël Mantione
[EMAIL PROTECTED] wrote:
I think there can be two visions here:
- Include is not a real procedure, so this internal implementation detail
should be hidden and this can/should be allowed; the
compiler internally should convert it into
I think this is also same in Delphi, but I agree that passing pure
properties (without getter/setter) to var should possibly be reduced to
warning or even hint.
Ales
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
Op Wed, 16 Jul 2008, schreef Ales Katona:
I think this is also same in Delphi, but I agree that passing pure properties
(without getter/setter) to var should possibly be reduced to warning or even
hint.
This was discussed before and rejected.
The reason is that a change in implementation
On 16 Jul 2008, at 11:58, Graeme Geldenhuys wrote:
OK, I understand you point over the long term. So would the following
still be okay?
set += [member];
Not that I ever use the C style operators like '+=', but it does act
as nice shorthand for code - replacing the need for Include().
It
On 16 Jul 2008, at 12:16, Martin Friebe wrote:
IMHO the way it could be done would be for the compiler to create a
temporary variable. This could be passed in as var/out-param, and
then be assigned to the property, using the proper setter-procedure.
That results in semantics than a
On Wed, Jul 16, 2008 at 2:43 PM, Jonas Maebe [EMAIL PROTECTED] wrote:
OK, I understand you point over the long term. So would the following
still be okay?
set += [member];
Not that I ever use the C style operators like '+=', but it does act
as nice shorthand for code - replacing the need
17 matches
Mail list logo
