Micha Nelissen wrote:
Marco van de Voort wrote:
Changing type to something which is not a descendant (and thus
incompatible) seems useless and always dangerous to me, so should be
forbidden if possible.
I also considered it that way. But maybe the "absolute" keyword is then a
bit badly chosen,
peter green wrote:
>>> bypassing "protected" ;)
>> "protected" as in language (type) protection ?
> protected as in the protected modifier for stuff in a class which is hugely
> overused in the vcl.
>From memory, most fields in the VCL are private, not protected. I don't
think absolute will, or sh
Micha Nelissen wrote:
> Michalis Kamburelis wrote:
>> All you want is just to cover in class B identifier "Field" of class A.
>> So you should make "Field" a dummy function in class A (that just
>> returns a field value), and then you can redefine function name in
>> descendant classes. See the exa
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Micha
> Nelissen
> Sent: 01 October 2006 21:41
> To: FPC developers' list
> Subject: Re: [fpc-devel] Language extension: absolute for classes
>
>
> peter green wro
Op Sun, 1 Oct 2006, schreef Michael Van Canneyt:
>
>
> On Sun, 1 Oct 2006, Micha Nelissen wrote:
>
> > Michael Van Canneyt wrote:
> > > If you do it for fields of class type only, then I think this is OK.
> > > Declare the field as virtual, and require it to be 'overridden' in the
> > > desce
On Sun, 1 Oct 2006, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > If you do it for fields of class type only, then I think this is OK.
> > Declare the field as virtual, and require it to be 'overridden' in the
> > descendent class.
>
> Why is there a need to declare fields virtual ?
B
peter green wrote:
>> Changing type to something which is not a descendant (and thus
>> incompatible) seems useless and always dangerous to me, so should be
>> forbidden if possible.
> useless yes, dangerous if not carefull yes but its the number one way for
> bypassing "protected" ;)
"protected"
> Changing type to something which is not a descendant (and thus
> incompatible) seems useless and always dangerous to me, so should be
> forbidden if possible.
useless yes, dangerous if not carefull yes but its the number one way for
bypassing "protected" ;)
_
Michael Van Canneyt wrote:
> If you do it for fields of class type only, then I think this is OK.
> Declare the field as virtual, and require it to be 'overridden' in the
> descendent class.
Why is there a need to declare fields virtual ?
Micha
___
fpc-
On Sun, 1 Oct 2006, Micha Nelissen wrote:
> Marco van de Voort wrote:
> >> Changing type to something which is not a descendant (and thus
> >> incompatible) seems useless and always dangerous to me, so should be
> >> forbidden if possible.
> >
> > I also considered it that way. But maybe the "a
On Sun, 1 Oct 2006, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> >> is to be written in a certain format, so you tell the compiler that it
> >> is like that. Why is this a hack ?
> >
> > Because you do a typecast just as if you would override a property using a
> > read specifier and do
Marco van de Voort wrote:
>> Changing type to something which is not a descendant (and thus
>> incompatible) seems useless and always dangerous to me, so should be
>> forbidden if possible.
>
> I also considered it that way. But maybe the "absolute" keyword is then a
> bit badly chosen, since it i
> Marco van de Voort wrote:
> >> What new syntax are you referring to ? You mean the 'absolute' ?
> >> I don't think so...
> >
> > Depends on implementation. Do you really implement absolute as with same
> > memoryspace here too, or only allow type upgrading (which is the major
> > reason for suc
Marco van de Voort wrote:
>> What new syntax are you referring to ? You mean the 'absolute' ?
>> I don't think so...
>
> Depends on implementation. Do you really implement absolute as with same
> memoryspace here too, or only allow type upgrading (which is the major
> reason for such feature)?
C
> On Sun, 1 Oct 2006, Marco van de Voort wrote:
>
> > > On Sun, 1 Oct 2006, Dani?l Mantione wrote:
> >
> > >
> > > For clarity:
> > > I am not opposing it, but I do consider it a dirty trick in both cases...
> >
> > Hmm, I don't think neli's one is that dirty, more exotic syntactic sugar.
> > Y
Michael Van Canneyt wrote:
>> is to be written in a certain format, so you tell the compiler that it
>> is like that. Why is this a hack ?
>
> Because you do a typecast just as if you would override a property using a
> read specifier and do the typecast there. Just the typecast is disguised
> as
On Sun, 1 Oct 2006, Marco van de Voort wrote:
> > On Sun, 1 Oct 2006, Dani?l Mantione wrote:
>
> >
> > For clarity:
> > I am not opposing it, but I do consider it a dirty trick in both cases...
>
> Hmm, I don't think neli's one is that dirty, more exotic syntactic sugar.
> Yes it happens with
> On Sun, 1 Oct 2006, Dani?l Mantione wrote:
>
> For clarity:
> I am not opposing it, but I do consider it a dirty trick in both cases...
Hmm, I don't think neli's one is that dirty, more exotic syntactic sugar.
Yes it happens with the composition pattern, but is it really worth
inventing new sy
On Sun, 1 Oct 2006, Daniël Mantione wrote:
>
>
> Op Sun, 1 Oct 2006, schreef Michael Van Canneyt:
>
> >
> >
> > On Sun, 1 Oct 2006, Micha Nelissen wrote:
> >
> > > Michalis Kamburelis wrote:
> > > > All you want is just to cover in class B identifier "Field" of class A.
> > > > So you shou
On Sun, 1 Oct 2006, Micha Nelissen wrote:
> Michael Van Canneyt wrote:
> > I don't think your solution is any cleaner than what he suggests.
> > It's also a 'smart hack', after all. Just like in the old DOS days,
>
> Why?
>
> > when one would declare an array of bytes with 'absolute' at the
>
Op Sun, 1 Oct 2006, schreef Michael Van Canneyt:
>
>
> On Sun, 1 Oct 2006, Micha Nelissen wrote:
>
> > Michalis Kamburelis wrote:
> > > All you want is just to cover in class B identifier "Field" of class A.
> > > So you should make "Field" a dummy function in class A (that just
> > > returns
Michael Van Canneyt wrote:
> I don't think your solution is any cleaner than what he suggests.
> It's also a 'smart hack', after all. Just like in the old DOS days,
Why?
> when one would declare an array of bytes with 'absolute' at the
> location of the VGA or Hercules text screen card...
Hmm?
On Sun, 1 Oct 2006, Micha Nelissen wrote:
> Michalis Kamburelis wrote:
> > All you want is just to cover in class B identifier "Field" of class A.
> > So you should make "Field" a dummy function in class A (that just
> > returns a field value), and then you can redefine function name in
> > desc
Michalis Kamburelis wrote:
> All you want is just to cover in class B identifier "Field" of class A.
> So you should make "Field" a dummy function in class A (that just
> returns a field value), and then you can redefine function name in
> descendant classes. See the example below. Within the scope
Micah Milissent wrote:
> Hi,
>
> I want to bring up the following scenario: (need fixed font)
>
>B --> G
>| |
>A --> F
>
> All are classes, and usually A 'owns' F. So A has a field 'Field' of
> type F. Now, whenever A creates F, B overrides this (in virtual method
> or clas
Marco van de Voort wrote:
>> I realize that this is only a 'saving-typing' language extension, but it
>> does save significant amounts of typing and would make the code more
>> readable (IMHO).
>
> You can achieve the same with generics ? Specialize a class with =G ?
No, because A needs an F, so
On Saturday 30 September 2006 12:23, Marco van de Voort wrote:
> > I realize that this is only a 'saving-typing' language extension, but it
> > does save significant amounts of typing and would make the code more
> > readable (IMHO).
>
> You can achieve the same with generics ? Specialize a class
> I realize that this is only a 'saving-typing' language extension, but it
> does save significant amounts of typing and would make the code more
> readable (IMHO).
You can achieve the same with generics ? Specialize a class with =G ?
___
fpc-devel mail
Hi,
I want to bring up the following scenario: (need fixed font)
B --> G
| |
A --> F
All are classes, and usually A 'owns' F. So A has a field 'Field' of
type F. Now, whenever A creates F, B overrides this (in virtual method
or class type) to create a G.
The problem now is th
29 matches
Mail list logo
