[fpc-devel] Re: [fpc-l] type discussion
marc.weustink at cuperus.nl
Fri Jun 3 12:40:00 CEST 2005
>>>-- Class Contracts
>>>I like the 'require/ensure' aproach.
>>>It makes the code more robust and more debuggable, IMHO
>> I think the checks you can do there are to limited. I also wonder what
>> will happen if a require isn't met. Personally I don't want
>> exeption in my released app.
>No, these are assertions not as exceptions.
OK, what to do if an invalid input is met ? Continue ? Skip ? Abort ?
IMO you still need some code which takes proper action
>>>I am not sure if Generics could be done in FPC.
>> There were some discussions about it here and AFAIK some are trying to
>>>-- Virtual Properties and Events
>> The examples given there are not very different of what is
>> possible now.
>> Make SetWith virtual and you have almost the same.
>> What however would be nice is if you could override the getter
>> or setter.
>> Something like
>> property Width write MySetWidth
>I think you missed a few things here.
> TMyClass = class
> property Width: integer read write; virtual; abstract;
>As you can see, getters and setters are not in the picture
>at all. Which means, you have all the freedom you want in
>the derived class.
Which is allmost the same as a virtual abstract Getter and Setter (almost,
read/write from a field isn't covered)
>Plus, I like the idea that I could have a base class
>with read-only property that can not be overriden to be
> property Width: integer read; virtual; abstract;
That makes some sense (but it would be incompatible with existing code)
>OK, while I like the idea, I can not think of how I would
>use it though :-) Can someone help me out here <G>
>>>-- Enhanced Multicast Events
>> This is not really new. You can implement it yourself like
>> property OnChange: TNotifyList;
>> and then OnChange.Add(Notifyproc) or OnChange.Remove(Notifyproc)
>OK. Nice to be able to do that. Do I have to write my
>TNotifyList every time I need it?
Not if you have generics ;)
>>>Inline variable initializers, such as:
>>> Integer1: Integer = 15;
>>> Boolean1: Boolean = False;
>>> String1: String = 'SOME TEXT';
>> Hmm.. sometimes usefull. You can put it as first lines
> > in your constructor/codeblock, but keep it thogheter in
> > say large classes can be handy.
>Yes, and it improved the readability, IMHO. Plus, there is
>no reason for you to alter that in constructor/codeblock too.
Not too. It is still edited at one place.
More information about the fpc-devel