> On Oct 4, 2018, at 9:19 PM, Michael Van Canneyt
> wrote:
>
> And was this not the whole idea of introducing a default property in the
> first place ?
It is but I just wanted to make sure that this particular ambiguity with
initializing classes wasn’t concerning for anyone.
So far I’ve i
On Thu, 4 Oct 2018, Ryan Joseph wrote:
On Oct 4, 2018, at 8:34 PM, Michael Van Canneyt wrote:
Technical issues aside, it kind of defeats the purpose of the default
property...
Then just tolerate the fact we have a dual meaning for assignments? Looks wrong
but maybe not a problem.
var
> On Oct 4, 2018, at 8:34 PM, Michael Van Canneyt
> wrote:
>
> Technical issues aside, it kind of defeats the purpose of the default
> property...
Then just tolerate the fact we have a dual meaning for assignments? Looks wrong
but maybe not a problem.
var
wrapper: TWrapper;
begin
On Thu, 4 Oct 2018, Ryan Joseph wrote:
On Sep 26, 2018, at 1:14 AM, Benito van der Zander wrote:
Hi,
perhaps everything would be clearer, if the default property was accessed with ^ ?
var
wrapper: TWrapper;
begin
wrapper := TWrapper.Create;
wrapper^ := THelpe
> On Sep 26, 2018, at 1:14 AM, Benito van der Zander wrote:
>
> Hi,
>
> perhaps everything would be clearer, if the default property was accessed
> with ^ ?
>
>
> var
> wrapper: TWrapper;
> begin
> wrapper := TWrapper.Create;
> wrapper^ := THelperA.Create;
> end.
>
Sor
Hi,
perhaps everything would be clearer, if the default property was
accessed with ^ ?
var
wrapper: TWrapper;
begin
wrapper := TWrapper.Create;
wrapper^ := THelperA.Create;
end.
Cheers,
Benito
Am 14.09.2018 um 10:50 schrieb Ryan Joseph:
How should this syntax wo
How should this syntax work? TWrapper needs to allow assignments of TWrapper
for constructors but it also should accept assignments of THelperA for the
default write property.
Is that a problem or should TWrapper be able to assign both? It looks strange
so I thought I would ask.
==
Is a + operator that returns something other than the record valid?
I tried doing that but I get an error.
type
TWrapper = record
class operator + (left: TWrapper; right: integer): integer;
end;
var
wrapper: TWrapper;
i: integer;
begin
i :=
> On Sep 10, 2018, at 6:34 AM, Michael Van Canneyt
> wrote:
>
> I know that, but I meant you cannot immediatly go to the second level. You
> must specify the 2 indexes as in:
>
>> Writeln(Test[21][2]);
The array property is a little different because it has the [] syntax which is
effecti
On Sun, 9 Sep 2018, Sven Barth via fpc-pascal wrote:
Am 09.09.2018 um 16:16 schrieb Michael Van Canneyt:
On Sun, 9 Sep 2018, Ryan Joseph wrote:
It seems syntacticly possible that default properties could be
recursive by having a default property reference a record/class with
another defa
Am 09.09.2018 um 16:16 schrieb Michael Van Canneyt:
On Sun, 9 Sep 2018, Ryan Joseph wrote:
It seems syntacticly possible that default properties could be
recursive by having a default property reference a record/class with
another default property. Should that be allowed?
I don't think so.
On Sun, 9 Sep 2018, Ryan Joseph wrote:
It seems syntacticly possible that default properties could be recursive by
having a default property reference a record/class with another default
property. Should that be allowed?
I don't think so. Let's start with 1 level.
For default arrays it's a
> On Sep 9, 2018, at 5:01 PM, Martin wrote:
>
> And how should the rules be for mixing with class helpers? (In case of
> conflicting names)
On the dev list Sven told me to use the tcallcandidates class to resolve
overloads and I believe this handles searching class helpers also. So I guess
On 09/09/2018 10:48, Ryan Joseph wrote:
It seems syntacticly possible that default properties could be recursive by
having a default property reference a record/class with another default
property. Should that be allowed?
And how should the rules be for mixing with class helpers? (In case of
It seems syntacticly possible that default properties could be recursive by
having a default property reference a record/class with another default
property. Should that be allowed?
type
THelperB = record
field: integer;
end;
type
THelperA = record
Ryan Joseph schrieb am Do., 6. Sep. 2018,
16:33:
>
>
> > On Sep 6, 2018, at 9:25 PM, Michael Van Canneyt
> wrote:
> >
> > No, the whole point of default is that they should be for any kind of
> field.
> > For example if you want a nullable boolean, you'll do something like
> >
> > Type
> >TN
> On Sep 6, 2018, at 9:25 PM, Michael Van Canneyt
> wrote:
>
> No, the whole point of default is that they should be for any kind of field.
> For example if you want a nullable boolean, you'll do something like
>
> Type
>TNullable= Record
>Private
> F : T;
> isAssigned : Boo
On Thu, 6 Sep 2018, Ryan Joseph wrote:
On Sep 5, 2018, at 11:22 AM, Ryan Joseph wrote:
I just realized that default shouldn’t be allowed on non-object fields right? I
think that’s what was decided and makes most sense to me too. Disregard my last
email. Sorry if I make a bunch of noise
On Wed, 5 Sep 2018, Ryan Joseph wrote:
On Sep 4, 2018, at 7:15 PM, Sven Barth via fpc-pascal
wrote:
The idea of the default property is that *all* operators (and methods) (except management operators) are hoisted from the type of the default property. The assignment of one record with de
> On Sep 5, 2018, at 11:22 AM, Ryan Joseph wrote:
>
> I just realized that default shouldn’t be allowed on non-object fields right?
> I think that’s what was decided and makes most sense to me too. Disregard my
> last email. Sorry if I make a bunch of noise while I’m working on this but
> I’
> On Sep 4, 2018, at 7:15 PM, Sven Barth via fpc-pascal
> wrote:
>
> Would you please stop thinking with the C operators? They are merely
> syntactic sugar and they don't exist by themselves. For this topic at least
> please stick to their full versions (in your example "rec := rec + 10") as
> On Sep 4, 2018, at 12:35 PM, Sven Barth via fpc-pascal
> wrote:
>
> I think you need to be clearer what you want to achieve in the end. The
> default property as intended by Maciej has the idea that it hoists the
> operators of the default property type to the record it is contained in.
Here
> On Sep 4, 2018, at 7:15 PM, Sven Barth via fpc-pascal
> wrote:
>
> The idea of the default property is that *all* operators (and methods)
> (except management operators) are hoisted from the type of the default
> property. The assignment of one record with default property to another of
>
Ryan Joseph schrieb am Di., 4. Sep. 2018,
11:27:
>
>
> > On Sep 4, 2018, at 2:06 PM, Ryan Joseph
> wrote:
> >
> > Sorry I didn’t think enough before I sent this.
> >
> > We *must* allow this assignment to make operator overloads work. +=
> operators are also basically assigning TWrapper to TWrap
> On Sep 4, 2018, at 2:06 PM, Ryan Joseph wrote:
>
> Sorry I didn’t think enough before I sent this.
>
> We *must* allow this assignment to make operator overloads work. +=
> operators are also basically assigning TWrapper to TWrapper, right? I guess
> we need to break the default property
> On Sep 4, 2018, at 1:57 PM, Ryan Joseph wrote:
>
> // what happens here? is this a wrong type error (TObject is expected but got
> TWrapper) or do we assign directly to the base record? I can see it both ways
> so I’m not sure what principle to fall back on. Allow it because we can or
> pr
> On Sep 3, 2018, at 4:39 PM, Maciej Izak wrote:
>
> You can always wait for my implementation because I am working on this (in
> free time, feature rather expected at the end of year) and you can extract
> patch and submit to FPC (or create your own earlier if you wish). "Default
> field wi
pon., 3 wrz 2018 o 09:15 Ryan Joseph
napisał(a):
> To summarize what I said last time was that I wanted a way to include
> “with” statement functionality in classes and records to aid in delegation
> patterns (in leu of multiple inheritance in Pascal). As it turns out the
> idea is relevant to ma
I started in on this already and here’s the first conflict I found when trying
operators.
What should happen if you assign a record to another record with a default
property?
var
wrapper: TWrapper;
other: TWrapper;
// this should assign to ‘obj’ via the default property
wrappe
> On Sep 4, 2018, at 12:35 PM, Sven Barth via fpc-pascal
> wrote:
>
> I think you need to be clearer what you want to achieve in the end. The
> default property as intended by Maciej has the idea that it hoists the
> operators of the default property type to the record it is contained in.
> E.
On 03.09.2018 09:15, Ryan Joseph wrote:
> Thank you for bearing with me, so finally here are my questions:
>
> 1) Given this is critical to make management operators work smoothly what
> does the compiler team think about this idea to have a default property or
> “with" in classes/records?
>
>
On Mon, 3 Sep 2018, Ryan Joseph wrote:
On Sep 3, 2018, at 9:17 PM, Martin wrote:
No it is not the same.
You.f.Free;
will always work, it is not ambiguous.
You.Free;
depends on no method Free being declared on the class of You, or any of its
base classes, or any other default class (if
On 03/09/2018 17:00, Ryan Joseph wrote:
On Sep 3, 2018, at 9:17 PM, Martin wrote:
You.f.Free;
will always work, it is not ambiguous.
You.Free;
depends on no method Free being declared on the class of You, or any of its
base classes, or any other default class (if more than one is allowed) t
> On Sep 3, 2018, at 9:17 PM, Martin wrote:
>
> No it is not the same.
>
> You.f.Free;
> will always work, it is not ambiguous.
>
> You.Free;
> depends on no method Free being declared on the class of You, or any of its
> base classes, or any other default class (if more than one is allowed)
> On Sep 3, 2018, at 9:17 PM, Martin wrote:
>
> You.f.Free;
> will always work, it is not ambiguous.
>
> You.Free;
> depends on no method Free being declared on the class of You, or any of its
> base classes, or any other default class (if more than one is allowed) that
> would be searched a
> On Sep 3, 2018, at 8:16 PM, Michael Van Canneyt
> wrote:
>
> The whole point of 'default' is to be able to make this assignment, for
> example to implement nullable types.
Just thought about this some more and realized that if you’re thinking more in
terms of nullable types (which rely to
On 03/09/2018 15:56, Ryan Joseph wrote:
In your example if the “a” property was default than:
You.Free;
would be the same as:
You.f.Free;
right? I just don’t see where the name of the property applies. The property
*removed* a name in fact. It’s like an anti-name. ;)
No it is not the sam
> On Sep 3, 2018, at 8:16 PM, Michael Van Canneyt
> wrote:
>
>> The
>> only reason we have the name is because we’re trying to add this feature
>> on top of properties syntax. Array properties had this oddity also and I
>> would prefer to just omit the name since it’s meaningless.
>
> It is
On Mon, 3 Sep 2018, Ryan Joseph wrote:
On Sep 3, 2018, at 4:14 PM, Michael Van Canneyt wrote:
On Sep 3, 2018, at 2:41 PM, Michael Van Canneyt wrote:
'with' is terribly awkward.
“with” came to mind because it’s basically a with statement but within a
class. Properties had another side
> On Sep 3, 2018, at 4:14 PM, Michael Van Canneyt
> wrote:
>
>>> On Sep 3, 2018, at 2:41 PM, Michael Van Canneyt
>>> wrote:
>>> 'with' is terribly awkward.
>>
>> “with” came to mind because it’s basically a with statement but within a
>> class. Properties had another side effect of requiri
On Mon, 3 Sep 2018, Ryan Joseph wrote:
On Sep 3, 2018, at 2:41 PM, Michael Van Canneyt wrote:
'with' is terribly awkward.
“with” came to mind because it’s basically a with statement but within a
class. Properties had another side effect of requiring naming which is
redundant (I’d proba
> On Sep 3, 2018, at 2:41 PM, Michael Van Canneyt
> wrote:
>
> 'with' is terribly awkward.
“with” came to mind because it’s basically a with statement but within a class.
Properties had another side effect of requiring naming which is redundant (I’d
probably just underscore the name always
On Mon, 3 Sep 2018, Ryan Joseph wrote:
I’m sorry to bring this one up again but it was touched upon in regards to
management operators and auto free objects. Please bear with me while I recap.
I’m writing this email today because I just had this exact same problem in
my code and I’m desperat
I’m sorry to bring this one up again but it was touched upon in regards to
management operators and auto free objects. Please bear with me while I recap.
To summarize what I said last time was that I wanted a way to include “with”
statement functionality in classes and records to aid in delegati
44 matches
Mail list logo
