mORMot Open Source

Junior/RO

Member

Registered: 2011-05-13

Posts: 210

Re: Renaming TSQLRecord to TORM

What about a "helper" object/record with all string functions? Another one for Date/Time functions, and so on.

In my code, for years I use a class-with-class-methods-only without "T" prefix.

Like

type
  CoordinateReader = class
    class function ReadUtmCoordinates(const fn: TFileName): TUtmCoordinateDynArray;
    class function ReadGeoCoordinates(const fn: TFileName): TGeoCoordinateDynArray;
  end;

var Coordinates := CoordinateReader.ReadUtmCoordinates(fn);

It's a try to emulate Ruby modules. Works for me.

Last edited by Junior/RO (2020-11-10 07:06:21)

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

Website

Re: Renaming TSQLRecord to TORM

@Junior/RO

There is no `class var` in old Delphi versions to keep some fields that could be shared among functions in an object/record structure.

I prefer not using classes for simple routines that a function can do the job. However, I dont think procedures / functions should be in interface section for users of any framework—we have OOP—because they may not have a good semantic; we can get name collisions; functions can be overriden easily just adding an unit after another (see Trim), etc. Pascal has the perfect structure to do it, which is called plain "old" object or, nowadays, "record with methods".

Last edited by mdbs99 (2020-11-11 01:28:45)

Junior/RO

Member

Registered: 2011-05-13

Posts: 210

Re: Renaming TSQLRecord to TORM

@Junior/RO

There is no `class var` in old Delphi versions to keep some fields that could be shared among functions in an object/record structure.

Right, but this isn't the same use case. When a pure function would use a class var?

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

Website

Re: Renaming TSQLRecord to TORM

@Junior/RO

There is no `class var` in old Delphi versions to keep some fields that could be shared among functions in an object/record structure.

Right, but this isn't the same use case. When a pure function would use a class var?

I'm not talking about pure function, but a group of functions with the same context, which can use (or not) some local variables (object fields) per instance (like a class, but not).

For example, suppose we have a TSynDateTimeUtils—doesn't matter the name, which is the main subject on this thread—and it has a Format() method for convert to String. See, not a FormatDateTime() but only Format() because we already know the context!
Ok, the original FormatDateTime() has a overload with a TFormatSettings parameter. So, why not a code a field with this type to "setup" all functions of this context (object)?

Nowadays, TFormatSettings has its own functions... same ideia.

PS: I'm just used original naming that we know. But better names would be ToString(), ToRawUTF8(), etc instead Format().
PPS: the TFormatSettings name is wrong. "Format what?". A better name would be TDateTimeFormatSettings or just TDateTimeSettings.

Last edited by mdbs99 (2020-11-11 13:22:29)

macfly

Member

From: Brasil

Registered: 2016-08-20

Posts: 374

Re: Renaming TSQLRecord to TORM

If the goal is to avoid name collision, we don't need class vars. It is important to keep things simple.

If I need commonly used parameters, I can create a variable / object for this.

PT_BRFormatSettings = .... // Filled with the appropriate configuration

S: = TSynStr.Format (S, PT_BRFormatSettings);
// OR
S: = SynFormat (S, PT_BRFormatSettings);

NOTE: I'm not talking about proprietary code, but the framework code, which IMHO should be as simple and straightforward as possible.

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

Website

Re: Renaming TSQLRecord to TORM

@macfly

You're saying that "format settings" should be coded as a constant? Besides, it should be used always when call "TSynStr.Format()"?
Put the format in a constant is not a good idea, if your system should work with other format... but this is another history.
Look, what I'm saying is this:

var
  fs: TFormatSettings;
  du: TSynDateTimeUtils;
  s1, s2, s3: string;
begin
  fs... // initialized with some format
  s1 := du.ToString(Now, fs); // I can do this OR...
  du.FormatSettings := fs; // ...I can set just one time
  s2 := du.ToString(Now); // ...and it will use du.FormatSettings here (overloaded method)...
  s3 := du.ToString(Now); // ...and here
end;

macfly

Member

From: Brasil

Registered: 2016-08-20

Posts: 374

Re: Renaming TSQLRecord to TORM

@mdbs99

What I wanted to exemplify is that if I need to format  in a fixed format I can create a variable with the values already defined.

Eugene Ilyin

Member

From: milky_way/orion_arm/sun/earth

Registered: 2016-03-27

Posts: 132

Website

Re: Renaming TSQLRecord to TORM

@ab

What do you think of making a list of colliding types in mORMot?

We can find all collisions between units interface section identifiers in two different ways (please let me know if you find an easier way to do it):

API Reference collisions identification

Deep crawl Embarcadero site for all identifiers (not sure that every identifier is present in docs):
http://docwiki.embarcadero.com/Librarie … /Unit_List
http://docwiki.embarcadero.com/Librarie … /en/System
http://docwiki.embarcadero.com/Librarie … em.Actions
http://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl
http://docwiki.embarcadero.com/Librarie … /en/Winapi
http://docwiki.embarcadero.com/Libraries/Sydney/en/Xml (maybe)

Deep crawl Free Pascal site for all identifiers by the next paths (again not sure that every identifier is present in docs):
https://www.freepascal.org/docs-html/cu … index.html
https://www.freepascal.org/docs-html/cu … index.html
https://www.freepascal.org/docs-html/cu … index.html

Deep crawl mORMot API referense site (is this reference actual, auto-generated and equal recent fossil version?):
https://synopse.info/files/html/Synopse … _FRAMEWORK

Extract all identifiers in interface section of all listed units and build the collision list.

Source code collisions identification

Parse all *.pas files of Embarcadero / Free Pascal / mORMot sources with one of the next Delphi language AST builders:

• http://www.ssw.uni-linz.ac.at/Research/Projects/Coco/

• https://github.com/jacobthurman/Castalia-Delphi-Parser

• https://github.com/SkliarOleksandr/DelphiAST

• https://github.com/RoutineOp/TeeParser

• https://github.com/Turbo87/PasParse

• https://github.com/Kryuski/GOLD-Parsing … For-Delphi

• https://github.com/DaveBlakeman/DelphiUsesGraph

• https://github.com/wanderlan/llvm-pascal

Extract all identifiers from AST-interface-section-nodes and build the collision list.

P. S.
I agree with other developers that the SynTrim naming is short, elegant, colision free, and do not require conditional defines or other magic to use.
As for fully signature identical methods the replacement with more efficient code can be named equally.

Last edited by Eugene Ilyin (2020-11-19 19:06:08)

pvn0

Member

From: Slovenia

Registered: 2018-02-12

Posts: 211

Re: Renaming TSQLRecord to TORM

I agree with other developers that the SynTrim naming is short, elegant, colision free, and do not require conditional defines or other magic to use.
As for fully signature identical methods the replacement with more efficient code can be named equally.

normal functions should be named simple, I really like TrimU since mORMot is all about UTF8 and avoids collision with RTL.

I prefer what @ab said :

The TSyn* prefix is for classes only, which may conflict with Delphi or FPC RTL basic units.
Then direct functions would be fine. If there is some conflict potentiality, then some inlined function with an uniique name will be define, e.g. as TrimU() redirects to Trim().