#1 2020-10-13 13:15:24

mdbs99
Member
From: Rio de Janeiro, Brazil
Registered: 2018-01-20
Posts: 127
Website

mORMot2: questions

mORMot2 is coming much better organized, congratulations.

I have 2 questions:
1. mORMot keeps using old-object types (which is good, of course) so why not group many functions inside them? For example

mormot.core.rtti.pas

has a lot of functions such

ClassFieldPropWithParents, ClassFieldInt64, ClassFieldInstance, ClassFieldPropWithParentsFromUTF8...

. Why not a TClassField* type to put all these functions there?

2. Because Delphi's bug using old-object, mORMot has code like this:

{$ifdef USERECORDWITHMETHODS}
  TSynMonitorUsageID = record
  {$else}
  TSynMonitorUsageID = object
  {$endif USERECORDWITHMETHODS}
  public

But I've found some "object" without this directive; sometimes using {$A-}, sometimes not. Why so?

Thanks.

Offline

#2 2020-10-13 15:13:08

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 13,167
Website

Re: mORMot2: questions

1. Direct ClassField() functions uses TClassType which is not a pointer.
I don't see any alternative.

2. If the object has no managed field (no string e.g.) then it is safe to use it.
And $A- is needed when we expect the fields to be not aligned.

Offline

#3 2020-10-13 16:28:36

mdbs99
Member
From: Rio de Janeiro, Brazil
Registered: 2018-01-20
Posts: 127
Website

Re: mORMot2: questions

1. I didn't mean that these functions need to work with the same type and/or same private attributes. I meant that it might be good to group similar functions into an "auxiliary" object, which contains everything about a subject. For example, in another topic, you told us about the `TrimControlChars ()` function, which we didn't know about. Whether this function exists within an object, e.g. "TSynStringHelper", it could be easier to find it instead search all functions inside an unit. Besides, the code completion will tell us about all related (string stuff) in this "help object".

2. Understood, thanks.

Offline

#4 2020-10-13 16:55:25

macfly
Member
From: Brasil
Registered: 2016-08-20
Posts: 374

Re: mORMot2: questions

I use a lot of statisc methods.

For example, my routines for handling strings are in a TStringUtils object.

An advantage, is that it forces you to specify the object avoiding ambiguities of functions with the same name in different units.

In the case of mORMot, I even always identify the unit in the code to avoid any ambiguity.

S := SynCommons.Trim (S);

Last edited by macfly (2020-10-13 19:38:42)

Offline

#5 2020-10-13 18:04:50

mdbs99
Member
From: Rio de Janeiro, Brazil
Registered: 2018-01-20
Posts: 127
Website

Re: mORMot2: questions

macfly wrote:

An advantage, is that it forces you to specify the object avoiding ambiguities of functions with the same name in different units.

Exactly.

macfly wrote:

In the case of mORMot, I even always identify the unit in the code to avoid any ambiguity.

S := SynCommons.Trim (S);

Which will be much more verbose in mORMot2, due to the new unit names...

Offline

#6 2020-10-14 16:04:07

Junior/RO
Member
Registered: 2011-05-13
Posts: 201

Re: mORMot2: questions

macfly wrote:

For example, my routines for handling strings are in a TStringUtils object.

An advantage, is that it forces you to specify the object avoiding ambiguities of functions with the same name in different units.


I do this a lot, too.

Almost all new code that I wrote is inside of a class, with class methods. Since that Delphi syntax don't have modules (in the ruby way), class methods help me with this abstraction.

Last edited by Junior/RO (2020-10-14 16:04:52)

Offline

Board footer

Powered by FluxBB