Difference between revisions of "Modernised Pascal"

From Lazarus wiki
Jump to navigationJump to search
(Proposal has been rejected)
 
Line 19: Line 19:
 
   for i := 1 to 30 {+} step 5 {+.} do
 
   for i := 1 to 30 {+} step 5 {+.} do
 
   end {!}
 
   end {!}
 +
 +
''Remark: "step" keyword seems to be cloned from Basic. If this to be implemented, then it is better to be replaced with "by" from Component Pascal.''
  
 
'''4)'''
 
'''4)'''
Line 59: Line 61:
 
         ...
 
         ...
 
     end
 
     end
 +
 +
'''8) unified as and is,''' as made in Component Pascal (aka Oberon/F, last Wirth's language):
 +
 +
    //  usual code is like that
 +
    if MyVar is MyClass then
 +
      with MyVar as MyClass do begin
 +
          ...
 +
      end else begin
 +
          ...
 +
      end;
 +
''(* obvious, that as operator is not required here from practical point of view. Since both as and is operators seems to be procedures running over class'es RTTI, it is hard for compiler to remove call to as. It also places a rooks at the doorstep of programmer, since he might, when later renaming classes or variables, rename only one from the pair. In Component Pascal it was decided that IS operator, if met inside execution flow control statements (if, case, while) and evaluated to true, assures the corresponded execution path that MyVar really belongs to MyClass, in other words, acting like implicit AS but without extra work through classes inheritance tree. So the code, beeing simplified, looks like that: *)''
 +
    if MyVar is MyClass then begin
 +
          ... //here MyVar is MyClass, compiler knows that
 +
      end else begin
 +
          ... //here MyVar is '''not''' MyClass, compiler knows that
 +
      end;
 +
 
 +
''That is not to break any compatibility with existing code or coding habits.
 +
As well, this seems to be relatively simple change.''
 +
 +
'''9) merging of interface/implementation,''' like in Component Pascal:
 +
Borland's idea of interface/implementations perhaps was borned analyzing C's .h files. It seems pretty and rigorous, but has its disadvantages.
 +
Some persons hates when changing prototype of overloaded function in interface they need to search for it in implementation. Other raises question of encapsulation leaks. They argue that there easily can be a situation, when unit publishes Class A, in unit's interface section. Next, unit has some private Class B, which is not to be published. Next, Class И is the type on private member variable within Class A. With current syntax rules that enforces the programmer to move Class И to interfae section, thus publishing it, while he did not wanted too.
 +
In Component Pascal instead the visibility of procedure,etc is determined by presence of asterisk in it's declaration. Something like that:
 +
"Procedure* PublishedFunction(vars);" and the like for classes, vars, etc.
 +
That is a big change, i guess, it would require special switch, like Mac Mode, or automagical detection if it was interface met first, or declaration with asterisk. It also looks less rigorous than habit-blessed interface/implementation pair. However it seems that might be more rigouruos in terms of encapsulating indeed.
 +
  
 
----
 
----

Revision as of 14:06, 26 January 2006

more strongly syntax

1)

if ... then

 ...

elsif {!}

 ...

else

 ...

end; {!}

2)

if 1 > a < 3 then ... {!} end

3)

 for i := 1 to 30 {+} step 5 {+.} do
 end {!}

Remark: "step" keyword seems to be cloned from Basic. If this to be implemented, then it is better to be replaced with "by" from Component Pascal.

4)

 while ... do ...
 end; {!}

5) alias for long name:

 when a = other_long_name1, b = other_long_name2 {!} do
   a.method1;
 end; {!}

6) block variables & initialization in declaration section:

  declare // ?
    var
      a: integer := DataSet1.Field[1].AsInteger;
    const
      b: integer = 1;
  begin
    ...
  end;

7) (?) property information 'access' abstraction ( on code compilation phase ):

  TClass1 = class
  ...
  published
    property FieldInt: Integer read fFieldInt write fFieldInt default 100;
  end;
  constructor TClass1.Create(...   
  begin
    inherited;
    fFieldInt := TClass1.FieldInt.DefaultValue; {!} // for non object types
  end;
  procedure TClass1.Check(...
  begin
    if fFieldInt = TClass1.FieldInt.DefaultValue then
       ...
    end

8) unified as and is, as made in Component Pascal (aka Oberon/F, last Wirth's language):

   //   usual code is like that
   if MyVar is MyClass then
      with MyVar as MyClass do begin
         ...
      end else begin
         ...
      end;

(* obvious, that as operator is not required here from practical point of view. Since both as and is operators seems to be procedures running over class'es RTTI, it is hard for compiler to remove call to as. It also places a rooks at the doorstep of programmer, since he might, when later renaming classes or variables, rename only one from the pair. In Component Pascal it was decided that IS operator, if met inside execution flow control statements (if, case, while) and evaluated to true, assures the corresponded execution path that MyVar really belongs to MyClass, in other words, acting like implicit AS but without extra work through classes inheritance tree. So the code, beeing simplified, looks like that: *)

   if MyVar is MyClass then begin
         ... //here MyVar is MyClass, compiler knows that
      end else begin
         ... //here MyVar is not MyClass, compiler knows that
      end;
 

That is not to break any compatibility with existing code or coding habits. As well, this seems to be relatively simple change.

9) merging of interface/implementation, like in Component Pascal: Borland's idea of interface/implementations perhaps was borned analyzing C's .h files. It seems pretty and rigorous, but has its disadvantages. Some persons hates when changing prototype of overloaded function in interface they need to search for it in implementation. Other raises question of encapsulation leaks. They argue that there easily can be a situation, when unit publishes Class A, in unit's interface section. Next, unit has some private Class B, which is not to be published. Next, Class И is the type on private member variable within Class A. With current syntax rules that enforces the programmer to move Class И to interfae section, thus publishing it, while he did not wanted too. In Component Pascal instead the visibility of procedure,etc is determined by presence of asterisk in it's declaration. Something like that: "Procedure* PublishedFunction(vars);" and the like for classes, vars, etc. That is a big change, i guess, it would require special switch, like Mac Mode, or automagical detection if it was interface met first, or declaration with asterisk. It also looks less rigorous than habit-blessed interface/implementation pair. However it seems that might be more rigouruos in terms of encapsulating indeed.




  1. Rejected. A proposal like this show exactly why begin/end is elegant, you don't need elseif.
  2. Rejected. Only purpose is to save some typing.
  3. "step" proposal not rejected (but not accepted as well), removal of "begin" rejected
  4. Rejected ... for removal of "begin"
  5. Rejected; aliases makes code harder to read.
  6. Don't understand what you want here.
  7. const field_default=100 does the same. Rejected.

Daniel-fpc 11:02, 17 Dec 2005 (CET)