Quick Modern Object Pascal Introduction, for Programmers

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Quick Modern Object Pascal Introduction, for Programmers

Michalis Kamburelis-3
> |I remember someone once asked whether we should override the method Assign
> or AssignTo.|
> |I am worried, choosing the wrong method to override will produce unexpected
> result.|

The AssignTo is only used by TPersistent.Assign, so it's a "fallback"
--- if class A cannot copy *from* B, then AssignTo is called on B to
let B assign *to* A. This allows to implement the copying on any end,
which is useful e.g. when you cannot change the source code of A.

This is documented on
http://www.freepascal.org/docs-html/rtl/classes/tpersistent.assign.html
.

The short advice is that you usually want to override Assign, and
forget about AssignTo. Overriding Assign is always enough if you think
about a typical cloning scenario, when you usually copy instance of
class A to another instance of class A, and not mix classes.

Regards,
Michalis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Quick Modern Object Pascal Introduction, for Programmers

Marco van de Voort
In reply to this post by Michalis Kamburelis-3
In our previous episode, Michalis Kamburelis said:
>
> - A section about TPersistent.Assign. This is the "basic approach to
> cloning" that should probably be shown first. See it here:
> http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_cloning_tpersistent_assign

See also
http://stackoverflow.com/questions/4041760/correct-way-to-duplicate-delphi-object/4041906#4041906

That is for an own root class and pre class helpers, but you could do it also in or TPersistent
helper:

type tpersisthelp = class helper for TPersistent
    function Clone(t: TPersistentClass = nil): TPersistent;
end;

function tpersisthelp.Clone(t: TPersistentClass = nil): TPersistent;
  begin
    if Assigned(t) then
      Result := t.Create
    else
      Result := TPersistentClass(Self.ClassType).Create;
    Result.Assign(Self);
  end;

Since TComponent declares a virtual destructor that might even be better.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Michalis Kamburelis-3
In reply to this post by Sven Barth-2
>> I even expect a bit further. These {$MODE OBJFPC}, {$H+}, and {$J-}
>> directives should be the *default* directives for every new FPC
>> programs/units. We're now using Free Pascal compiler on 2016. Why do we need
>> to explicitly declare Free Pascal mode in a Free Pascal program? In 21st
>> century, our string should not be limited to 255 chars anymore. And what the
>> hell is "writable constant"? It's contradictio in terminis. :)
>
> We have a strong focus on backwards compatibility, so the default mode stays
> "fpc" and changing a modes' default settings would also affect backwards
> compatibility.
>

Maintaining compatibility is usually a compromise. I feel that in this
case, maintaining such compatibility hurts more than it helps. It is
of course my opinion, biased by the kind of code I write, and by the
programmers I talk with (many of whom don't know Pascal, but know
Java, C# or other OOP languages).

Current FPC defaults:

- Help people who except the {$mode fpc} to be default (so they write
code without classes and a lot of other new features),
- Or people who expect that string is by default ShortString (limited
to 255 chars).

I think that the majority of people use now suitable command-line
options, or directives, to change FPC mode to something more modern
({$mode objfpc} or {$mode delphi}, and {$H+}). So changing the
defaults will not hurt them. Sure, I don't have any hard data to back
it up, I don't know how much is "majority". But this applies at least
to all Lazarus users that have these settings "by default".

Again, this is just my opinion, but I would say that breaking
compatibility in this case is warranted. Making objfpc the default
mode, and making $H+ the default in objfpc mode, before the fpc.cfg is
read (so it applies to everyone, and can be overridden by fpc.cfg or
command-line later) would be a nice thing.

(Making {$J-} would be a cool bonus, but I don't dream about it, as it
could admittedly break more recent code.)

In http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html
I decided to just write

  {$mode objfpc}{$H+}{$J-} // Just use this line in all modern sources

at the beginning of a first "hello world" example. And I never explain
the reason for this line, I just repeat it in all examples (that are
full programs/units). That's an ugly solution, but I just couldn't see
a better one. It doesn't sound nice to explain that:

- otherwise, they don't have classes ("why are classes disabled?"),
- otherwise their stings are limited to 255 ("are you sure this is a
modern language?"),
- and otherwise their constants are not necessarily constant ("what?") ...

It's not a good learning experience, if you have to learn about so
many historical things when you learn to write a first Pascal program.
And these things are already fixed -- just the defaults are old.

Regards,
Michalis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Quick Modern Object Pascal Introduction, for Programmers

Michalis Kamburelis-3
In reply to this post by Marco van de Voort
2016-06-21 12:14 GMT+02:00 Marco van de Voort <[hidden email]>:

> In our previous episode, Michalis Kamburelis said:
>>
>> - A section about TPersistent.Assign. This is the "basic approach to
>> cloning" that should probably be shown first. See it here:
>> http://michalis.ii.uni.wroc.pl/~michalis/modern_pascal_introduction/modern_pascal_introduction.html#_cloning_tpersistent_assign
>
> See also
> http://stackoverflow.com/questions/4041760/correct-way-to-duplicate-delphi-object/4041906#4041906
>
> That is for an own root class and pre class helpers, but you could do it also in or TPersistent
> helper:
>
> type tpersisthelp = class helper for TPersistent
>     function Clone(t: TPersistentClass = nil): TPersistent;
> end;
>
> function tpersisthelp.Clone(t: TPersistentClass = nil): TPersistent;
>   begin
>     if Assigned(t) then
>       Result := t.Create
>     else
>       Result := TPersistentClass(Self.ClassType).Create;
>     Result.Assign(Self);
>   end;
>
> Since TComponent declares a virtual destructor that might even be better.
I saw your post on stackoverflow before writing my article:)

But doing this on TPersistent means that you avoid calling the
constructor of the actual class. If you use this helper on a class
TMyClass, you will have an instance of TMyClass that "bypassed" the
constructor of TMyClass. Only "TPersistent.Create" was called. I
suspect that in real-world usage, a lot of classes will fail to work
correctly then, since code inside TMyClass often assumes that TMyClass
constructor was performed. I know that a lot of my own classes will
fail because of this...

That's why I would limit this usage only to the cases when you have a
virtual constructor on the base class. Only then the final class has a
chance to execute it's proper constructor.

Regards,
Michalis

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

test_clone.lpr (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bls: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Mr Bee
In reply to this post by Sven Barth-2
Adding to Michalis Kamburelis argument… 

Keeping backwards compatibility [BC] is great. However, thinking about forwards compatibility [FC] is also necessary. Keeping BC too tight will also hold back our forward thinking. We will be stucked in the past forever. No matter how hard we keep the BC, we eventually will break it anyway. If we want FPC to be known as modern programming language, just let go off the past. Unless, we are happy to be still associated with the old 70's Pascal.

So, we must plan the appropriate timing when we should break BC and let FC taking over. I think FPC v.3.2 would be appropriate enough. Besides, what's the release notes for? right? :)
 

–Mr Bee



Pada Selasa, 21 Juni 2016 16:30, Sven Barth <[hidden email]> menulis:


Am 21.06.2016 08:58 schrieb "Mr Bee" <[hidden email]>:
>
> > Maybe a little bit offtopic, but I have a question regarding the compiler directives: is there a way to tell Lazarus to use these directives in every new unit?
>  
> I even expect a bit further. These {$MODE OBJFPC}, {$H+}, and {$J-} directives should be the *default* directives for every new FPC programs/units. We're now using Free Pascal compiler on 2016. Why do we need to explicitly declare Free Pascal mode in a Free Pascal program? In 21st century, our string should not be limited to 255 chars anymore. And what the hell is "writable constant"? It's contradictio in terminis. :)
We have a strong focus on backwards compatibility, so the default mode stays "fpc" and changing a modes' default settings would also affect backwards compatibility.
Regards,

Sven

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal



_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Karoly Balogh (Charlie/SGR)
Hi,

On Tue, 21 Jun 2016, Mr Bee wrote:

> Keeping backwards compatibility [BC] is great. However, thinking about
> forwards compatibility [FC] is also necessary. Keeping BC too tight will
> also hold back our forward thinking. We will be stucked in the past
> forever. No matter how hard we keep the BC, we eventually will break it
> anyway. If we want FPC to be known as modern programming language, just
> let go off the past. Unless, we are happy to be still associated with
> the old 70's Pascal.

Well, actually, ObjFPC and other modes still have plenty of legacy...
Large chunks of the SysUtils unit are legacy. Not to mention the bunch of
Windowsism coming from Delphi all over the RTL and Packages. Heck, Lazarus
even reimplemented parts of the Windows API for better legacy Delphi code
compatibility...

Either we care about compatibility and FPC remains what it is, or if we
really want a *MODERN* language, just go the Oxygene path, and add a more
modern syntax as well. For example, I dislike the interface vs.
implementation separation, it's much better to mark the public stuff with
public, like in Java, etc... Also, some of the syntax limitations also
feel really archaic these days. Fix the dangling else. Add a better
for/foreach loop. Also, lets drop write(), which is an exception to any
Pascal language rule with its varargs syntax, etc... I could go on, and I
didn't even touch the RTL legacies topic... These would be the important
things IMO, not the name of the default stringtype (which is changed by
whoever owns Delphi every 3 years anyway), or a single option in the
config file, because that's so future...

My 2 c,
---
Charlie
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Sven Barth-2
In reply to this post by Michalis Kamburelis-3

Am 21.06.2016 12:31 schrieb "Michalis Kamburelis" <[hidden email]>:
> Current FPC defaults:
>
> - Help people who except the {$mode fpc} to be default (so they write
> code without classes and a lot of other new features),
> - Or people who expect that string is by default ShortString (limited
> to 255 chars).

One might argue about changing the default mode, but changing the default String type of mode ObjFPC will very likely result in compilation or runtime errors (probably even in the compiler itself) which is something we tend to avoid without good reasons. At the very least there will be performance differences which - depending on the code - might be noticeable as well.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Michalis Kamburelis-3
2016-06-21 15:03 GMT+02:00 Sven Barth <[hidden email]>:

> Am 21.06.2016 12:31 schrieb "Michalis Kamburelis"
> <[hidden email]>:
>> Current FPC defaults:
>>
>> - Help people who except the {$mode fpc} to be default (so they write
>> code without classes and a lot of other new features),
>> - Or people who expect that string is by default ShortString (limited
>> to 255 chars).
>
> One might argue about changing the default mode, but changing the default
> String type of mode ObjFPC will very likely result in compilation or runtime
> errors (probably even in the compiler itself) which is something we tend to
> avoid without good reasons. At the very least there will be performance
> differences which - depending on the code - might be noticeable as well.
>

These errors and differences will be only felt by projects that use
{$mode objfpc} but assume that string = ShortString (and they don't
use {$H-} explicitly). I don't think it would apply to too many
projects?

And if we do it in some major version, with proper release notes, like
Mr Bee proposes, these projects would have plenty of time to adjust
their compilation scripts / config files. They could just add "-Sh-"
or "{$H-}" and be OK, for both past and future FPC versions.

Regards,
Michalis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Sven Barth-2

Am 21.06.2016 15:21 schrieb "Michalis Kamburelis" <[hidden email]>:
>
> 2016-06-21 15:03 GMT+02:00 Sven Barth <[hidden email]>:
> > Am 21.06.2016 12:31 schrieb "Michalis Kamburelis"
> > <[hidden email]>:
> >> Current FPC defaults:
> >>
> >> - Help people who except the {$mode fpc} to be default (so they write
> >> code without classes and a lot of other new features),
> >> - Or people who expect that string is by default ShortString (limited
> >> to 255 chars).
> >
> > One might argue about changing the default mode, but changing the default
> > String type of mode ObjFPC will very likely result in compilation or runtime
> > errors (probably even in the compiler itself) which is something we tend to
> > avoid without good reasons. At the very least there will be performance
> > differences which - depending on the code - might be noticeable as well.
> >
>
> These errors and differences will be only felt by projects that use
> {$mode objfpc} but assume that string = ShortString (and they don't
> use {$H-} explicitly). I don't think it would apply to too many
> projects?

Compiler and RTL are two examples.

> And if we do it in some major version, with proper release notes, like
> Mr Bee proposes, these projects would have plenty of time to adjust
> their compilation scripts / config files. They could just add "-Sh-"
> or "{$H-}" and be OK, for both past and future FPC versions.

It was decided some time ago when mode Delphi was switched to H+ (due to Delphi compatibility) that mode ObjFPC won't be switched, cause for that mode we value backwards compatibility higher than the user not having to write a switch.

Regards,
Sven


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Jürgen Hestermann
Am 2016-06-21 um 17:16 schrieb Sven Barth:
 > It was decided some time ago when mode Delphi was switched to H+ (due to Delphi compatibility) that mode ObjFPC won't be switched, cause for that mode we value backwards compatibility higher than the user not having to write a switch.

This is quite short-sighted:

It's not only the work of writing a compiler switch.
You also have to *know* (think) about it.
There are so many compiler switches and if we end up
with the situation that all new users have to spend a
day to make their program work as the grandious feature
list of some FPC page told them then something is wrong.

Those who are already familiar with all the details have
much less work to just add a compiler switch to their
existing projects (if needed) and it would be necessary
only once on a certain FPC version when this default
changes.

Now we need to tell each new user that he has to change
the (default) settings to get a "modern" Pascal compiler
because "out of the box" it is a very old one.

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Dennis Poon
In reply to this post by Michalis Kamburelis-3
I saw your document on for x in ListX  loop and would like to reconfirm
that it is always iterated in ascending order, right?

can we do it in descending order without a user defined enumerator? i.e.
for simple enumerated type, is there a construct to iterate through it
in descending order?

Dennis
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Bls: Bls: Quick Modern Object Pascal Introduction, for Programmers

Graeme Geldenhuys-6
On 2016-06-22 18:18, Dennis Poon wrote:
> can we do it in descending order without a user defined enumerator?

Not as far as I know - I believe it is a one directional iterator (or so
the interface suggests). There are tons of limitations with the for..in
construct.

Years back I implemented an iterator interface (based on Java definition
of iterators) with multiple implementations for various container
classes I use often. I can iterate forward, backwards, use a regex to
filter (skip) what gets iterated etc. And using the factory method I can
request an iterator instance with ease, and even register more iterators
if needed. So much more flexible [personal opinion].

I've written an article about it some years back:
  http://geldenhuys.co.uk/articles/

Look for the “Iterator Pattern” article and sample code.

Regards,
  Graeme

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12