mORMot Open Source

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

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.

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,655

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.

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

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.

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)

mdbs99

Member

From: Rio de Janeiro, Brazil

Registered: 2018-01-20

Posts: 139

Website

Re: mORMot2: questions

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

Exactly.

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...

Junior/RO

Member

Registered: 2011-05-13

Posts: 210

Re: mORMot2: questions

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)