Board index » delphi » Re: Interface / Implementation sections

Re: Interface / Implementation sections


2007-03-23 02:00:33 AM
delphi6
Chris Burrows schrieb:
[snip]
Quote

would then become something like:

ProcedureItem: public = POINTER TO RECORD (ListItem)
pos: public, exportMark: public: INTEGER;
receiver: public: Sys.String;
fullName: public: Sys.String
END;

The attributes tend to interrupt the reading flow for me.

Why not put the visibility after the type?
fullName: Sys.String; public;
or so...
Greetings
Markus
 
 

Re: Interface / Implementation sections

Hi Chris
I agree with Markus on this one, symbols are just not Delphi, there should
just be visibility declared as a word after the declaration/type; public,
private (optional as it would be the default), etc.
It might tape a few more taps of the keyboard but that is what templates were
invented for :-)
nafdb
 

Re: Interface / Implementation sections

"Markus.Humm" <XXXX@XXXXX.COM>writes
Quote
Chris Burrows schrieb:
[snip]
>
>would then become something like:
>
>ProcedureItem: public = POINTER TO RECORD (ListItem)
>pos: public, exportMark: public: INTEGER;
>receiver: public: Sys.String;
>fullName: public: Sys.String
>END;
>
>The attributes tend to interrupt the reading flow for me.
>

Why not put the visibility after the type?

fullName: Sys.String; public;

Because the visibility is an attribute of the variable not the type.
a*, b-, c: integer;
would become:
a: integer; public;
b: integer; readonly;
c: integer;
 

Re: Interface / Implementation sections

Quote
a: integer; public;
b: integer; readonly;
c: integer;
Personally I like that. It is infinitely more readable than:
Quote
a*, b-, c: integer;
nafdb
 

Re: Interface / Implementation sections

"nafdb" <XXXX@XXXXX.COM>writes
Quote
>a: integer; public;
>b: integer; readonly;
>c: integer;

Personally I like that. It is infinitely more readable than:

>a*, b-, c: integer;

It seems that 'You win some, you lose some' always applies unless you care
to design your own language.
If you like wordiness you will like Oberon / Component Pascal for other
reasons. e.g. Pascal's cryptic
p: ^integer;
has been replaced by
p: POINTER TO INTEGER;
Alternatively, the latest language in the Algol / Pascal / Modula-2 / Oberon
family, 'Zonnon' does use words for the visibility attributes: e.g.
var {public, immutable} refCount: integer;
However, they have chosen to reinstate the Modula-2 style separate
definition / implementation sections.
www.zonnon.ethz.ch/
 

Re: Interface / Implementation sections

"Bruce McGee" <XXXX@XXXXX.COM>writes
Quote

I hope I am not the only one who really likes the separate Interface
section.

I doubt it. However, have you had any hands-on experience of using a system
where the Interface section is automatically generated for you? I was quite
content for many years with separate semi-duplicated interface sections
until I encountered some very practical alternatives.
 

Re: Interface / Implementation sections

Hi Bruce
Quote

I consider any inconveniences to be minor, especially with the
refactoring support, but I haven't used anything that the
auto-generation for me. Who knows? I might really warm up to it.
I use the Modelmaker Code Explorer add in and now wouldn't be without
it. One of the features is a customisable/searchable treeview of the
class structure - at the end of the day I don't care that the code is
duplicated in the interface and impl sections because MMX handles the
synchronisation for me.
I think there is a 30 day trial version and it is not a bad price
either.
Cheers
D
David Moorhouse
Moorhouse Works ltd
www.moorhouse.co.nz
 

Re: Interface / Implementation sections

Chris Burrows writes:
Quote
I doubt it. However, have you had any hands-on experience of using a
system where the Interface section is automatically generated for
you? I was quite content for many years with separate semi-duplicated
interface sections until I encountered some very practical
alternatives.
Fair enough.
I consider any inconveniences to be minor, especially with the
refactoring support, but I haven't used anything that the
auto-generation for me. Who knows? I might really warm up to it.
--
Regards,
Bruce McGee
Glooscap Software
 

Re: Interface / Implementation sections

You are not. As many have said before, if we wanted to be programming in
C++ we wouldn't be programming in OP. I do however like the { } over
begin .. end and would love to see that become a project option. Using
C# begin end ({ }) or OP begin end.
Bruce McGee writes:
Quote
I hope I am not the only one who really likes the separate Interface
section.

--
Thomas Miller
Chrome Portal Project Manager
CPCUG Programmers SIG Chairperson (formally Delphi)
Delphi Client/Server Certified Developer
BSS Accounting & Distribution Software
BSS Enterprise Accounting FrameWork
www.bss-software.com
programmers.cpcug.org/
sourceforge.net/projects/chromeportal/
sourceforge.net/projects/uopl/
sourceforge.net/projects/dbexpressplus
 

Re: Interface / Implementation sections

Thomas Miller writes:
Quote
You are not. As many have said before, if we wanted to be programming in
C++ we wouldn't be programming in OP. I do however like the { } over
begin .. end and would love to see that become a project option. Using
C# begin end ({ }) or OP begin end.



Bruce McGee writes:
>I hope I am not the only one who really likes the separate Interface
>section.
>

I pretty much doubt you will see that happen! Would break compatibility
with most code that uses {} for comments, not to mention compiler
directives, defines, regions...
 

Re: Interface / Implementation sections

Thomas,
| I do however like the { } over begin .. end and would love to see
| that become a project option. Using C# begin end ({ }) or OP begin
| end.
Oh GAWD no! <g>
--
Q
03/26/2007 13:04:54
XanaNews Version 1.17.5.7 [Q's salutation mod]
 

Re: Interface / Implementation sections

"Thomas Miller" <XXXX@XXXXX.COM>writes
Quote
You are not. As many have said before, if we wanted to be programming in
C++ we wouldn't be programming in OP.
It's not necessary to resort to C++ just to avoid semi-redundant, manually
maintained, interface / implementation sections. There are other programming
languages apart from OP and C++.